Better Bandwidth Utilization 196
jtorin writes "Daniel Hartmeier (of OpenBSD fame) has written a short but interesting article which explains how to better utilize available bandwidth. In short it gives priority to TCP ACKs over other types of traffic, thereby making it possible to max both upload and download bandwidth simultaenously. Be sure to check ot the nice graphs! Also note the article on OpenBSD Journal. OpenBSD 3.3 beta is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"
This will be of most use to ... (Score:4, Insightful)
Corporate networks are already optimized under 100 or gigabit ethernet with Cisco routers which automatically handle collisions and error corrections.
Very nice solution! (Score:1, Insightful)
Still, a very simple and effective solution to an age-old problem. I like.
Note the article is all about low bandwidth setups (Score:5, Insightful)
A little off topic but I always find it interesting that people with hicap gear (Foundry, Cisco, etc.) are always talking about QOS when it really only makes sense most times on low bandwidth lines. So his work is really important when you look at where it is in scheme of things - out at the end users line.
Better Bandwidth Utilization... (Score:1, Insightful)
Broadband implications (Score:3, Insightful)
Then again, since when have most broadband providers really ever cared about supplying good speeds when the user maxes out the outrageously capped upstream...
Slashdotting and DOS (Score:2, Insightful)
rule 2: Have a backup plan in case someone sends you a bunch of ACK ACK ACK ACK ACK ACK to cause a denial of service.
Re:Linux solution (Score:2, Insightful)
Who needs BSD?
People that love UNIX. The Finnish hack is for people that hate Microsoft.
Re:We figured this before (Score:1, Insightful)
run openbsd inside vmware on the windows machine, have it queue your packets as described in the article.
Working Link (Score:3, Insightful)
link [theaimsgroup.com]
Re:Uh, no, I don't think so (Score:2, Insightful)
If you're only sending a single UDP packet, sure. But if you're exceeding the end to end bandwidth of the network, then clearly packets need to either be queued or dropped. If you're exceeding the maximum bandwidth by more than just a little, then you're going to fill up the buffers, and packets will get dropped.
Without seeing the quote I'd only be speculating on what the textbook was talking about. Could be LANs, but it could be that they were talking about single UDP packets, rather than pounding a few megs of HTML and images all at once. Or maybe the quote was that UDP packets rarely get dropped for reasons other than congestion. Perhaps they could have been talking about packets that are mangled en route? That is something which could happen in theory but in reality rarely (if ever) happens.
Of course, maybe I'm just wrong. It does happen from time to time :).