Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:What part of this is hard to understand? (Score 1) 181

Paying $20/m for 150/150 dedicated fiber, $50 after 6 months. I have my own personal fiber from my home to the CO and the ISP says I will get my bandwidth 24/7. 6ms-12ms to Chicago, depending on which trunk to Level 3 they're using. Zero peering, no CDNs, just pure bandwidth, 100+ years old, been a customer for 10+ years and my bill has never gone up a single penny but recently is has gone down 50%. They got rid of their 20/20 for $30, 70/70 for $70, 100/100 for $90 and replaced them all with 150/150 for $50. People with the lowest tier were grandfathered in, but if they ever want to change speeds, I guess their bill is going to go up. That being said, they only recently created the lowest tier a few years ago. The decade prior, they only had a $70 and $90 tier. If only I could afford their $300 1gb/1gb.

You've got to love their marketing

It’s dedicated symmetrical fiber so speeds never change.
150 Mbps Dedicated Symmetrical $49.99/m
Recommended for
Web hosting
Online gaming
Heavy data transfer
Cloud computing
Webinar hosting
Extremely large online backups

Their network policy is nice to

The Company does not favor or inhibit lawful applications or classes of applications.
The Company does not knowingly and intentionally block, impair, degrade or delay the traffic on its network
The Company does not use or demand “pay-for-priority” or similar arrangements that directly or indirectly favor some traffic over other traffic.
The Company does not prioritize its own content, application, services, or devices, or those of its affiliates.
The Company does not charge edge service providers of content, applications, services and/or devices a fee simply for transporting traffic between the edge service provider and its customers.

Comment Re:What part of this is hard to understand? (Score 1) 181

Forgot to add why anti-bufferbloat AQMs help with link utilization. They help reduce the "thundering herd" caused by dumb tail-drop FIFO buffers that cause global TCP synchronization. If you look at a normal FIFO based link with lots of flows, the typically max out a little over 80% utilization as latency, jitter, and loss skyrocket. Constant TCP streams swinging up and down cause bursts of backoffs, causing the link to violently change from over-utilized to under-utilized very quickly. AQMs tend to have an elastic queue that works more like a head-drop, biased toward dropping packets of the heaviest flows in that instant.

This allows links to reclaim a lot of that left over 20% while stabilizing packet quality at the same time.

Comment Re:What part of this is hard to understand? (Score 1) 181

Using modern stateless configureless buffer management algorithms, you can have low latency, low loss, low jitter, and a mostly even distribution of bandwidth. High latency is caused by bufferbloat. Fix the bloat, fix all of the issues you mentioned, but with out of the box simplicity near-zero-configuration(set your bandwidth).

Some interesting statistics that I read about research on bufferbloat is that a very small percentage of flows are "hogs" are any given instant. They tested link rates from 133Mb/s all the way up to 10Gb/s, and they all had the same numbers. Even though they all had hundreds of thousands of active flows, at any given instant, only 100 flows had at least one packet in the link's buffer, and only 10 flows had 2 or more packets in the buffer. This means that you only need to track about 100 "states" of data, regardless the link rate or saturation.

Many fair queuing algorithms have taken advantage of this and just create hash buckets. There are only about 100 states in the buffer at any given time, meaning if you have something like 1024 buckets, the chance of any two network flows colliding is relatively low, but not zero. Another algorithm extended this to include "ways", where each bucket can have up to 8 flows in it, but round robins them. Turns out that adding these few "ways" resulted in zero collisions going into millions of states over a relatively slow congested link.

This all means a link can 100% isolate an infinite number of flows over a link while only using a small amount of fixed memory. Next advancement. Most of the time when a packet enters the buffer, it quickly leaves it. When a packet comes into the buffer, it gets shoved into a bucket+way. If this bucket+way was empty, this packet gets prioritized over all other non-new packets. Because 99.9999% of the time there are zero packets in the buffer for a given flow, this allows the non-hog traffic to get immediately scheduled.

If a data flow suddenly starts to become a hog, that means when the next packet arrives, there will already be an existing packet in the bucket+way, meaning that packet does not get prioritized and instead back-logs. But remember, this situation only applies to about 10 flows at any given instant. All of this means that 99.9999% of all packets immediately dequeue with near zero latency. The "hogs" get their additional packets delayed as they start to backlog, and if the link is too saturated, eventfully the packet is dropped. When this happens, the sender backs off and they are no longer a hog.

Turns out that doing it this way actually results in better link utilization. You can run the link to something like 99% utilization while still maintaining fractional millisecond latencies, and average utilization is higher. win-win-win. Zero downsides other than increased CPU usage. Right now they are able to run these algorithms on standard x86 routers/firewalls almost into the 40Gb range, but are hoping future optimizations to network stacks will allow higher. Assuming these algorithms get well tested, they will started to get implemented in hardware. DOCSIS 3.1 actually makes use of RED by default, which is a non-fair queue FIFO anti-bufferbloat AQM. RED is Codel-like but is friendly to Cisco ASICS.

Comment Re:What part of this is hard to understand? (Score 1) 181

Not mine. ToS I signed says they're net neutral and do absolutely no shaping or QoS. Not only does it say they do not do this, but promise not to. Enterprise and residential users all get the same "priority". They tried QoS in the past, but it has too many coner cases, making customer unhappy, which increased support costs. It was cheaper just to purchase more bandwidth to guarantee no congestion than to mess with shaping or QoS.

Comment Re:What part of this is hard to understand? (Score 1) 181

I don't do any QoS and I don't have any issues with latency during link saturation. You're complicating the problem because you now need to define all of the rules needed to match your classes of traffic. Using a modern Fair Queuing AQM, you can maintain low latency, jitter, and loss for VoIP while allowing Torrent to saturate your connection with virtually zero configuration. Look up Codel, fqCodel, RED, fqRED, or Cake.

Implementation differences of the algorithms can cause differences in the results, but I am currently maintaining a sub 1ms jitter 24/7. 1.2ms ping with 0.2ms std-dev to be more precise. Even during a 1Gb/s DOS against my prior 100Mb connection, my ping never went above 30ms because my ISP also uses an AQM.

Comment Re:Some good points. (Score 1) 269

that taught you is the experience of trying to program your actual device

Some people don't need to physically try to gain experience. There is actually a small subset of the population that learns by thinking about a situation. They are good at creating accurate mental models, allowing them to not until gain deep understanding of programming, but to learn from mistakes they have only made in their head, where they can make mistakes as fast as they can think, allowing them to progress much faster.

Comment Re:Synergy! Connectivization! Linkativity! (Score 1) 269

Just make up numbers like everyone else does. Statistically, a single interruption like email notification or IM popping up, regardless if you read it, can set you back 15-30 minutes. With such common interruptions being several factors greater than the resolution of time trying to be recorded, and for something as subjective as "how much time will it take to get back on track", you may as well make up numbers.

If I've spent 1 hour thinking about a hard issue, and some other project comes a long as is all like "zomg, this needs to be fixed NOAW!", even if it takes me 5 minutes, they're getting charged that hour I just spent on the other project. Why should the other project have to pay for interruptions making their code more inefficient to create?

Comment Re:Well... he has a point on all fronts. (Score 2) 150

2) ARM is, or rather, was, not afraid to put efficiency above complete and total backward compatibility

They were only "highly efficient" because they were not high performance. They've tried to make CPUs as powerful as x86 cores, but they consumed much more power and still quite weaker. This has been their weakness in the datacenter. All of the power savings is lost to needing more cores and systems. Great embedded type systems, or possibly low end desktops, but horrible for most workloads for high-end servers.

Comment Re:Some good points. (Score 1) 269

2/3rds of knowledge is not factual, it is context sensitive, it is nuanced in a way that human language cannot communicate. Many in psychology actually use apprenticeships as an example of the best way to transfer knowledge this knowledge, lots of hands-on experience watching a master at work.

One of the most highly acclaimed books on Software Architecture started the book saying, if you have to read this or any other book to become the required master at software design to be an Architect, you will never be a good architect. His recommendation was to get your money back for the book.

I don't read books to gain knowledge, that is stupid when you can google almost all knowledge, I read them to learn to think differently. One book so eloquently put it, you will never be a master as programming if you listen to others, even them. They went on to say that even if another master at programming tells you to NEVER do something, if you listen, you will never become a master. You need to be able to make your own decisions. Masters follow their intuition, which supersedes all forms of knowledge. You can't learn intuition from a book.

I've started to use the phrase "wrong for the right reasons" more. The kinds of issues I work on are in their nature unable to be empirically measured or reproducible, yet I can fix them. Most of these issues I trivially know where to look, and I can spend hours trying to explain my logic to another person that I consider very very smart. Why is your software running slow when you try to use every form of profiling and unable to find a hot path? Or an issue that only occurs once in a great while and does not happen when you have trace or debug code enabled? This is the kind of stuff I live for.

Numerous times I have had people show me how their code runs fast, they have micro and macro benchmarked the code, but I tell them it will run slowly. All goes well in production for a while until a tipping point is hit, then suddenly it comes crashing down. I make my changes and everything is running well again. Even when they look at my changes and I try to tell them why I made each change, they still cannot fully grasp why my version works so much better. And these are very knowledgeable smart people.

I do not consider myself very knowledgeable or very smart, in the normal sense of the word at least, but I seem to have a very strong intuition about designing, debugging, and optimizing. Never ever in my life have I ever had to try at programming. It's always been a natural extension of the way I think.

Comment Re:Tere is only 1 reason - and it's bogus. (Score 1) 269

Performance metrics have their limits. They can tell you if someone was done, but not done well. I have hugely complex projects that have been handling feature creep for years, the number of bugs can be counted on one hand. Other people have simple project littered with bugs. Their metrics look better because they're "getting more done", lots of bugs to fix.

One of my managers, in his 20+ years of being in engineering, told me by all metrics, I am the slowest, but by results, I am the fastest.

Comment Re:Some good points. (Score 1) 269

66% of knowledge is not transferable via communications of any form, which is why hiring to 3rd parties rarely works, because domain knowledge and requirements cannot be properly conveyed via humans, not matter how hard they try.. 90% of what can be communicated is tonal or body language. 10% of 33% is 3.3%. Your mentoring is only 3.3% transferable. Grats.

Comment Re:I want to be reincarnated as Linus Torvalds (Score 1) 294

A moron in a hurry makes mistakes. We've all been there, and it will happen again. Where we should not make mistakes is when doing something of high importance where you have time and you need to research to make sure you do it correctly. When I have an issue that requires more time thinking than coding, I almost never make mistakes, and especially not obvious mistakes.

My last potential bug was when I was assigning values in a struct. While I made sure the order of the memory locations being assigned were thread-safe, I only realized later that because the struct was larger than 8 bytes(on a 64bit system), the values in the struct would require two writes to fully copy the data. This could have caused a torn read. None of the other programmers reviewing my code noticed this glaring issue.

In this situation I to was a moron in a hurry. Luckily, when I read code, I think about what it compiles down into. Something about this code was making a voice in my mind say something was wrong. I seem to have a strong intuition, I always have, even when I first started coding. If I wasn't told to completely write an 8 week project in 1 week, I probably would not have submitted my code for review prior to noticing such a horrible bug.

Slashdot Top Deals

It is not best to swap horses while crossing the river. -- Abraham Lincoln