Slashdot Mirror
Better Bandwidth Utilization
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?"
Enjoy my post plz.
frost piss! 1234
can I better utilize bandwith by downloading OpenBSD too? :P
--------
Free your mind.
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.
To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.
To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.
To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.
Future
I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.
However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.
You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.
= Mike
--
How ironic, an article about better utilizing available bandwidth, and already /.-ed with 0 comments.
Guess bandwidth is utilized now.
rule 1: don't put an article in slashdot pointing to your site
Now if only I could find that Linux thing...
http://lartc.org/wondershaper/
Corporate networks are already optimized under 100 or gigabit ethernet with Cisco routers which automatically handle collisions and error corrections.
Yell & scream & rant & rave... it's no use... you need a shaaaave ~ Bugs Bunny
For educational purpose i'll post the script. Author unknown. Here it is: #!/usr/local/bin/bash # The Ultimate Setup For Your Internet Connection At Home # # # Set the following values to somewhat less than your actual download # and uplink speed. In kilobits # (EDIT THESE) DOWNLINK=1024 UPLINK=256 DEV=random # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root CBQ
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
# main class
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit
allot 1500 prio 5 bounded isolated
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit
allot 1600 prio 1 avpkt 1000
# bulk and default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit
allot 1600 prio 2 avpkt 1000
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# start filters
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32
match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 12 u32
match ip protocol 6 0xff
match u8 0x05 0x0f at 0
match u16 0x0000 0xffc0 at 2
match u8 0x10 0xff at 33
flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
tc filter add dev $DEV parent 1: protocol ip prio 13 u32
match ip dst 0.0.0.0/0 flowid 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
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
It appears that server ACKs have been optimized as well.
SERVER-ACK*wheez*ouch*ACK*sizzle*Damnit*
I am sure, however, that the bandwidth is being optimized as it came back almost immediately unreachable
Joking aside, this is the ultimate hack if it works as breezed through in the summary-just tweaking the priorities, more bandwidth!
---"What did I say that sounded like 'Tell me about your day?'"---
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
Actually ever since my isp changed from A2000 to Chello we had the same problem as this guy has with his download being killed by his upload, a few months ago me and some friends figured the same solution but we had no idea how to actually do it on a windows based machine, anyone with a idea?
some P2P software will start distributing a "P2P accelerator" which marks all packets as ACKs.
I was able to read up to the results section due to being /.'d but what I have read was quite interesting. I like the idea of prioritizing which packets go out first by what their intent is rather then everything goes out and fights for the bandwidth.
Of course, the effectiveness of this technology depends on both networks which handle the ACK to have the service implemented.
Still, a very simple and effective solution to an age-old problem. I like.
The Linux Advanced Routing & Traffic Control HOWTO discuss how to achieve the same thing on linux using QoS. See section 9.2.2.2(Sample configuration)
Belief is the currency of delusion.
Put lower priorities on p0rn, MP3s, Windows viruses, and Slashdot referrals. That should speed everything else up by about two orders of magnitude.
Sheesh, evil *and* a jerk. -- Jade
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.
This is a really useful pointer to a very simple optimization. We've recently replaced our SonicWall firewalls with OpenBSD, so using ALTQ will be really straightforward. I wonder how easy it is to accomplish on Linux.
Ask Slashdot: What percentage of internet traffic is pr0n?
so exactly how many people is this comment directed to? I mean, might we get as much as 1% of the readership checking out the graphs before certain unfortunate server suffers a horrible death / temporary trauma?
My life in the land of the rising sun.
You can find Daniels original email on the subject at:= 10463 0260218727
/.'d graphs
http://marc.theaimsgroup.com/?l=openbsd-pf&m
It contains a little more of the pf rules than the article does, and has all the relevant information you need except for the nice
hmm.. ./ed already
Looks like ./ proved him wrong on this one!
Bandwidth is fixed. Any number of crappy operating systems can max out bandwidth. What they meant to say is how to reduce latency.
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
Ahhh... That bring down memories of the infamous ZModem protocol that was widely used in warez BBSs. There was a rule that said "you need to upload if you want to download". Therefore, the fastest way to get a software would be to upload at the same time as the download. The funny thing is that the synchronization was done by hand. Meaning that you needed to see the download caracter at the screen, to start uploading. If you miss by a couple of seconds, you could not get the synchronization right, and had to start over.
Yet another crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 96% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. And most recently, due to problems with his professional behavior and conflicts with other developers, Matt Dillon, "the guy most responsible for making FreeBSD 4.x the most rugged and stress-proof free operating system in existence," was unceremoniously banned from developing FreeBSD and now spends his days tinkering with XBox modchips. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users, or 36399 with Dillon's departure. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
That "Intro to the Internet" class from college is a little hazy now, but I don't recall it being as simple as the "internet" coming out of the pipe like water.
Someone far more knowledgable than myself will get to correct me, but I seem to recall there was a process of-
Send some stuff-wait for ACK.
When you get the ACK, send some more.
By turbocharging the ACKs, you are reducing that lag time
---"What did I say that sounded like 'Tell me about your day?'"---
in the past, the numbers have clearly been 5678.
a/s/l here. Sorry, adding domain tags to your s
The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.
ok statments like that tick me off its a silly thing to say
if your route is long then the chances are that along the way you will have a bottleneck and when you go across water it gets worse as all the repeaters get in on the act
saying things like " internet comes through at the same bandwidth" is plain silly
regards
John Jones
Was I the only one who was a little apprehensive about clicking on a link from the .cx domain?
"Ask not what your country can do for you." --John F. Kennedy
Perhaps they should use it for their site... Shashdotted already.
Isn't there an attack that essentially floods a server with ACK's? Just wondering what effect that would have if ACK had priority over other traffic.
Or maybe it was flooded with SYN's? Damn. I can't remember.
I don't click on any .cx domains!
I would like to see a program that allows me to specify certain percentages of bandwidth for different programs. One feature could be, if a program is not in the throttled section it has up to 100%, but throttled have to there max only.
some moron claiming he read the article.
people just don't read articles on slashdot.
...my packets are being acknowledged extremely well by the author.
...
Trace Routing to the author's link
<a href ="http://www.benzedrine.cx">Insomnia Site</a> yields the following path:
....
6 pop1-hou-P7-2.atdn.net [66.185.136.77]
7 bb2-hou-P0-2.atdn.net [66.185.150.146]
8 bb2-tby-P7-0.atdn.net [66.185.152.247]
9 bb1-tby-P1-0.atdn.net [66.185.152.242]
10 bb2-atm-P7-0.atdn.net [66.185.152.245]
11 bb2-cha-P6-0.atdn.net [66.185.152.31]
12 bb2-ash-P13-0.atdn.net [66.185.152.50]
13 pop1-ash-P1-0.atdn.net [66.185.139.195]
14 BritishTelecom.atdn.net [66.185.151.110]
15 t2c1-ge6-2.us-ash.concert.net [166.49.208.221]
16 t2c1-p8-0.nl-ams2.concert.net [166.49.208.133]
17 t2c1-p8-0.uk-lon2.concert.net [166.49.208.90]
18 t2c1-p2-1.ch-zur.concert.net [166.49.164.46]
19 t2a1-ge5-0-0.ch-zur.concert.net [166.49.186.17]
20 ixp1-p0-0-0.ch-zur.concert.net [166.49.223.10]
21 gw.dl.zhl-zhh-00.netstream.ch [62.65.130.1]
22 gw.fiber.dd-zh-00.netstream.ch [62.65.128.133]
23 gw.fiber.dd-dd-01.netstream.ch [62.65.128.146]
24
.................
I think he was expecting 'nightmares' anywayz,that'z why he chose to name his machine INSOMNIA:-)
Since the website seems slashdotted now I've set up a mirror. You can see it there.
Less pr0n and warez?
Why did my TV suddenly decide that I wanted to see three specials about Michael Jackson every week?
Because your TiVo thinks you want to watch them.
"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?"
Windows XP is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"
(intended as a joke)
Seems to me that this could really help broadband providers supply a better service if this was implemented in the firmware of the modems and the headend equipment.
Then again, since when have most broadband providers really ever cared about supplying good speeds when the user maxes out the outrageously capped upstream...
True enough.
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.
Your correct, bandwidth is fixed. This is about better bandwidth utilisation.
/.ed but the gist is that if you consider a full duplex conection, and you max out one side of that, say uploads, then the ACK packets get swamped, so your downstrem bandwidth is spent re-transmitting, or empty whilst the other end is waiting for ACKs.
The article is
The bandwidth is there, it;s just under utilised. By prioritisng the ACK's, so that they get boosted through, it becomes possible to saturate both upstream and downstream pipes at once, at peak efficency, rather than one of the coasting along, waithing for the other.
Note that this only applies for TCP/IP and similar, reliable, protocols. If you had a UDP app (e.g. media streaming done properly), then this trick won't affect it at all, as it doesn't wait for an ACK.
Removing M$ and dreamweaver specific cruft in HTML and forbiding sending of html email would do a lot to help conserve bandwidth.
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a mere fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
If the acks are sped up, this interferes with TCP keeping track of the statistical average Round Trip Time.
So if the network is congested and an ACK SHOULD time out but doesn't, TCP will keep on flooding the network, ruining the pool for everyone.(see: Tragedy of the commons)
Yes, I agree that this is a big-O style worse case scenario, but its something to consider.
In the future, I would want to not be isolated from my friends in the Space Station.
Again, to the best of my recollection, what you are suggesting is similar to the TFTP and many streaming techniques approach:
Take FTP and strip the overhead error checking and if something doesn't come out right, refresh and download it again.
For streaming, you get more throughput, and every now and them you might miss a frame in exchange for the higher quality you can obtain with the lower overhead
---"What did I say that sounded like 'Tell me about your day?'"---
It seems to me that a great many
Reading that book will give you a foundation to understanding how a single endpoint behaves in an IP network. If you want some understanding of the guts of a large scale internetwork I'd suggest the Cisco Press IP Quality of Service book.
There are a great many things near and dear to
If you're impatient you can look at my journal - I've covered some of the issues there.
I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
Hi
hum i have been doing this for a long time now
in 2.4.x linux kernel
is this not yesterdays news ?
This is cool and all, but what I don't get is why OpenBSD still doesn't have SMP support. Is it because they focus so much on security that other things fall by the wayside or is SMP insecure? :)
I won't use OpenBSD until SMP gets in. Until then, I'll stick with FreeBSD.
The technique you suggest is one of several proposed by Stefan Savage in TCP Congestion Control with a Misbehaving Receiver. He called it TCP Daytona. :)
Not necessarily. Even organizations with extremely high-bandwidth connections have budgets. If you can up throughput by 10% using a QoS solution when a corresponding bandwidth increase would cost twice as much, which would you choose? Obviously this particular project is more geared toward end users and small shops with limited bandwidth, but QoS as a whole does have benefits for everyone.
looking to replace my hddless router with package that utilizes the same concept or is there any hardware cable routers that do bandwidth shaping?
http://www.benzedrine.cx/ackpri-norm.jpg
http://www.benzedrine.cx/ackpri-priq.jpg
benzedrine.cx - Prioritizing empty TCP ACKs with pf and ALTQ Prioritizing empty TCP ACKs with pf and ALTQ
Introduction ALTQ is a framework to manage queueing disciplines on network interfaces. It manipulates output queues to enforce bandwidth limits and priorize traffic based on classification.
While ALTQ was part of OpenBSD and has been enabled by default since several releases, the next release will merge the ALTQ and pf configuration into a single file and let pf assign packets to queues. This both simplifies the configuration and greatly reduces the cost of queue assignment.
This article presents a simple yet effective example of what the pf/ALTQ combination can be used for. It's meant to illustrate the new configuration syntax and queue assignment. The code used in this example is already available in the -current OpenBSD source branch.
Problem I'm using an asymmetric DSL with 512 kbps downstream and 128 kbps upstream capacity (minus PPPoE overhead). When I download, I get transfer rates of about 50 kB/s. But as soon as I start a concurrent upload, the download rate drops significantly, to about 7 kB/s.
Explanation Even when a TCP connection is used to send data only in one direction (like when downloading a file through ftp), TCP acknowledgements (ACKs) must be sent in the opposite direction, or the peer will assume that its packets got lost and retransmit them. To keep the peer sending data at the maximum rate, it's important to promptly send the ACKs back.
When the uplink is saturated by other connections (like a concurrent upload), all outgoing packets get delayed equally by default. Hence, a concurrent upload saturating the uplink causes the outgoing ACKs for the download to get delayed, which causes the drop in the download throughput.
Solution The outgoing ACKs related to the download are small, as they don't contain any data payload. Even a fast download saturating the 512 kbps downstream does not require more than a fraction of upstream bandwidth for the related outgoing ACKS.
Hence, the idea is to priorize TCP ACKs that have no payload. The following pf.conf fragment illustrates how to set up the queue definitions and assign packets to the defined queues:
ext_if="kue0"
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)
pass out on $ext_if proto tcp from $ext_if to any flags S/SA \
keep state queue (q_def, q_pri)
pass in on $ext_if proto tcp from any to $ext_if flags S/SA \
keep state queue (q_def, q_pri)
First, a macro is defined for the external interface. This makes it easier to adjust the ruleset when the interface changes.
Next, altq is enabled on the interface using the priq scheduler, and the upstream bandwidth is specified.
I'm using 100 kbps instead of 128 kbps as this is the real maximum I can reach (due to PPPoE encapsulation overhead). Some experimentation might be needed to find the best value. If it's set too high, the priority queue is not effective, and if it's set too low, the available bandwidth is not fully used.
Then, two queues are defined with (arbitrary) names q_pri and q_def. The queue with the lower priority is made the default.
Finally, the rules passing the relevant connections (statefully) are extended to specify what queues to assign the matching packets to. The first queue specified in the parentheses is used for all packets by default, while the second (and optional) queue is used for packets with ToS (type of service) 'lowdelay' (for instance interactive ssh sessions) and TCP ACKs without payload.
Both incoming and outgoing TCP connections will pass by those two rules, create state, and all packets related to the connections will be assigned to either the q_def or q_pri queues. Packets assigned to the q_pri queue will have priority and will get sent before any pending packets in the q_def queue.
Result The following test was performed first without and then with the ALTQ rules explained above:
The first graphs shows the results of the test without ALTQ, and the second one with ALTQ:
Image 1, ACK PRI Normal
Image 2, ACK PRI PRIq
The improvement is quite significant, the saturated uplink no longer delays the outgoing empty ACKs, and the download rate doesn't drop anymore.
This effect is not limited to asymmetric links, it occurs whenever one direction of the link is saturated. With an asymmetric link this occurs more often, obviously.
Related links
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
Go away, troll.
Though you might see more effects of this on a low bandwidth link, it is not just for low bandwidth.
A fair number of protocols do transmit windows of a certain size. They'll send a certain amount of data, and not send more data until the oldest packest in the window gets an ACK back. You therefore only have so much data "in-flight" at any one time. Strongly asynchronous link (like aDSL and cablemodems) can require strikingly different window sizes than synchronous links.
The right amount of in-flight data is dependent on the speed of your pipe, obviously, but a lot of applications still use defaults set for low-bandwidth pipes. You can argue that the proper solution for this is to change the defaults, but if you just give ACKs priority, you don't need to worry about it, and the less you force users to change, the better. (The transmit window size has to be a user setting, directly or indirectly, either by asking a window size, or by asking "what kind of pipe do you have?" and guessing a window size from that.)
This is dependent on the protocol, true, but giving ACKs priority is actually a decent generic solution to what many consider an application-specific problem.
QOS is also often about bandwidth guarantees, not necessarily throughput. You have a 155mbit link shared among several applications, and an application that *requires* 45mbit. So you use QOS to guarantee that application gets 45mbit if it wants it, and everything else shares the remainder. If the app isn't going, then that 45mbit it requires can be made available to other apps until it is required.
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?
"so why not download a snapshot from one of the mirrors and try it out?" "
Yeah, see, I would, but I'm a bit concerned about security on my network, so I think I'm going to stay with Windows 2000 for now.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
Would I be able to put this inline between our AP's and our bandwidth manager - http://www.etinc.com ? Or is this only useful on the client side? It would be very nice to be able to prioritize like this and reduce latency for everyone involved...
Karma: Chameleon (mostly due to the fact that you come and go).
Is there anyway to prioritize UDP packets so I can have low latency in online games using UDP and still download / surf the net?
-pug (too lazy to make an account)
Is it possible to control packets this way in Winodws?
Isn't there any research going on, on auto-tuning a link? Maybe recording over a period of time a links characteristics, and the nature of the traffic. Then setting appropriate settings throught the networking system.
For example, I have the equivilent of a T1 (1.544mb CIR Frame) going to Qwest. From Qwest, I have a 256k CIR Frame link going to a remote office.
When the office sends data to me, it's fine. When I send back, there are massive amounts of Red Frames. Dropped packets means re-transmits which means delay. Delay is bad when you are running an interactive application over these links. Think of a garden hose connected to a fire hydrant. The garden hose could dump water into the fire hydrant fine (assuming the water for the hydrant is turned off elsewhere...). When the fire hydrant turns on, however...
Now I have QoS maps based off of the DLCI for each office, so it throttles back our link to Qwest to match the remote connection, so everyone talks happily, instead of blasting the little link into oblivion. Now, Red Frames aren't seen very often, unless the Qwest circuit is saturated, and we get chopped back to our base CIR. It makes a difference. Not a huge one, but a noticeable difference.
Traffic Shaping is your friend. It's all about making the mose efficient use of what you have. (Or making sure that you still have bandwidth when your roommate is leeching gigs of pr0n...) M
Anyone got any idea about how to do this on freebsd? Can ipfw be configured to do this?
Slashdot needs a new moderation option, the "First Post" moderation, something that all of us who browse at 0 and -1 can use to send these posts to -9 or something.
Windows XP uses a DDR Fairness technique to solve the same problem, I wonder how the two techniques compare?
See "QoS for Modems and Remote Access" at this KB article.
I've heard that this guys have implemented the same idea as one of the trick they use in their traffic shaping/QoS products. They're for WAN links IIRC so that any client (in the remote sites) can take advanatge of it.
DRR - Distributed Round Robin..
There are too many acroynms in this industry.
Honest, I'm not Karma-whoring, it just ticks me off.
link
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
This is what is known today as "ACK traffic shaping". First on the market, I believe, was packeteer (www.packeteer.com) with their PacketShaper.
Unlike most conventional traffic shapers which queue and control the data rate on the outgoing channel, PacketShaper controls the rate of acknowledgements on the reverse channel.
This is usually used to *slow* traffic. I.e., instead of having the router drop packets (thereby wasting resources until the source TCP understands that the net is congested and reduces load) it just slows the ACKs and the sender automatically reduces its sending rate.
Anyway, the real nice thing about the OpenBSD implementation is that they merge their packet filter (pf) with the ALTQ queuing code. Now this is really powerful.
Sounds like a good time for all BSDs to adopt this new combination instead of relying on less-capable mechanisms. E.g. FreeBSD has ipfw for filtering and dummynet for queue management. I don't know how pf compares with ipfw but ALTQ is definitely better than dummynet.
Nimrod.
Just in case you don't run openbsd or linux (wondershaper) and are looking for ack packet priority, you can get throttled from http://www.intrarts.com/throttled.html and have the same functionality for Mac OS X and freebsd. It is great to see this information finally getting out to the public, as it does offer significant improvements in network performance.
Wasn't that a movie? ;)
Magic. Got it.
This guy is way out there
the graphs on the page show the download finishing at the same time.
one just appears to send way less data.
am i reading the graphs wrong?
http://www.kay0909.com/ackpri/
In case anyone missed it or something.
-Kay0909
so why not download a snapshot from one of the mirrors and try it out?
I play 3D games. Thats why I use Linux instead.
They seem to have learned the habit of cowering before authority even when
not actually threatened. How very nice for authority. I decided not to
learn this particular lesson.
-- Richard Stallman
- this post brought to you by the Automated Last Post Generator...