Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Better Bandwidth Utilization

michael posted more than 11 years ago | from the neat-hack dept.

The Internet 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?"

Sorry! There are no comments related to the filter you selected.

frosty (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440324)

Enjoy my post plz.

first post (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440326)

frost piss! 1234

IDAWTP (-1)

handybundler (232934) | more than 11 years ago | (#5440490)

in the past, the numbers have clearly been 5678.

Hmmm (0, Flamebait)

Gortbusters.org (637314) | more than 11 years ago | (#5440333)

can I better utilize bandwith by downloading OpenBSD too? :P

Re:Hmmm (0)

Anonymous Coward | more than 11 years ago | (#5440428)

If all you care about is bandwidth, yeah. If you don't like the idea of having to switch distros, then don't bother and wait for other systems to implement this kind of solution.

Re:Hmmm (0)

Anonymous Coward | more than 11 years ago | (#5440888)

The BSDs aren't distros. They are forked from each other, and don't share a common kernel.

Developer lashes out: What Killed FreeBSD (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440346)

The End of FreeBSD

[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

--

To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt

Re:Developer lashes out: What Killed FreeBSD (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5440362)

Sod off will you.

Re:Developer lashes out: What Killed FreeBSD (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440557)


An Elegy For *BSD


I am a *BSD user
and I try hard to be brave
That is a tall order
*BSD's foot is in the grave.

I tap at my toy keyboard
and whistle a happy tune
but keeping happy's so hard,
*BSD died so soon.

Each day I wake and softly sob
Nightfall finds me crying
Not only am I a zit faced slob
but *BSD is dying.

How ironic (4, Funny)

JPDeckers (559434) | more than 11 years ago | (#5440347)

How ironic, an article about better utilizing available bandwidth, and already /.-ed with 0 comments. Guess bandwidth is utilized now.

Re:How ironic (4, Funny)

TopShelf (92521) | more than 11 years ago | (#5440360)

Guess we better implement this idea without any delay, then!

Re:How ironic (2, Funny)

Xformer (595973) | more than 11 years ago | (#5440627)

What do you expect? It's on an island [www.nic.cx] , after all... :-)

How to better utilize bandwidth (4, Funny)

gmuslera (3436) | more than 11 years ago | (#5440351)

rule 1: don't put an article in slashdot pointing to your site

Slashdotting and DOS (2, Insightful)

Anonymous Coward | more than 11 years ago | (#5440699)

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.

Oh, that's where OpenBSD is... (4, Funny)

dereklam (621517) | more than 11 years ago | (#5440354)

Thanks for linking to OpenBSD... I was wondering what that whole BSD thing was!

Now if only I could find that Linux thing...

Re:Oh, that's where OpenBSD is... (0, Funny)

Loki_1929 (550940) | more than 11 years ago | (#5440617)

"Now if only I could find that Linux thing..."

Oh, it's right here [microsoft.com] , I think.

like wondershaper does for months now? (5, Informative)

Anonymous Coward | more than 11 years ago | (#5440355)

Re:like wondershaper does for months now? (0)

Anonymous Coward | more than 11 years ago | (#5440385)

Years probably.

This did seem to be one of those "No shit, Sherlock" articles, but then most slashdotters are morons.

Re:like wondershaper does for months now? (4, Informative)

gmuslera (3436) | more than 11 years ago | (#5440429)

Wondershaper uses other approach, like having a scheduler and (de)prioritize certain ports and hosts . I think that right now it not specially prioritize TCP ack, and, well, that could improve the good job what do wondershaper right now if it works.

Re:like wondershaper does for months now? (4, Informative)

gmuslera (3436) | more than 11 years ago | (#5440459)

Second revisions are always better. It prioritizes small packets (of less of 64 bytes), and I suppose that this include ACKs :)

Re:like wondershaper does for months now? (5, Interesting)

Captain Pedantic (531610) | more than 11 years ago | (#5440483)

From the Wondershaper [lartc.org] script:

# 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

Re:like wondershaper does for months now? (4, Informative)

stratjakt (596332) | more than 11 years ago | (#5440582)

And from the explanation in the readme:

"To make sure that uploads don't hurt downloads,
we also move ACK packets to the front of the queue."

It's pretty cool, it throttles your speeds to just under what the maximum should be, so that queueing will only happen on your linux box, and then you can prioritize what you want.

Re:like wondershaper does for months now? (1)

spydir31 (312329) | more than 11 years ago | (#5440543)

You can add this to wondershaper to prioritise acks,
tc filter add dev $DEV parent 1:0 prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x10 0xff at nexthdr+13 \
flowid 1:10
not tested, but should work (I think)

Re:like wondershaper does for months now? (4, Informative)

spydir31 (312329) | more than 11 years ago | (#5440583)

better version, I think
tc filter add dev $DEV parent 1:0 prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x10 0x10 at nexthdr+13 \
flowid 1:10

Re:like wondershaper does for months now? (0)

Anonymous Coward | more than 11 years ago | (#5440660)

ahh, you are quite correct.

2 things.

1. Wondershaper is covered by a non-free license
2. altq has been doing this for a few years

Re:like wondershaper does for months now? (0)

Anonymous Coward | more than 11 years ago | (#5440733)

Hm, together with firewall rules ?

Elegy for *BSD (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5440367)


Elegy For *BSD


I am a *BSD user
and I try hard to be brave
That is a tall order
*BSD's foot is in the grave.

I tap at my toy keyboard
and whistle a happy tune
but keeping happy's so hard,
*BSD died so soon.

Each day I wake and softly sob
Nightfall finds me crying
Not only am I a zit faced slob
but *BSD is dying.

This will be of most use to ... (4, Insightful)

adzoox (615327) | more than 11 years ago | (#5440376)

I think this may be of most use to two way satellite connections and maybe to service providers - however; I don't see how one can get much faster than a cable modem or DSL connection - the internet comes through at the same bandwidth and speed whether I am wireless or T1 or cable modem/DSL - this is the majority of network traffic nowadays

Corporate networks are already optimized under 100 or gigabit ethernet with Cisco routers which automatically handle collisions and error corrections.

Re:This will be of most use to ... (4, Informative)

arkanes (521690) | more than 11 years ago | (#5440398)

If you have a non-shaped asynchronous connection, like most forms of DSL and cable, it's pretty easy to cap out your upstream. When you do that, your downstream goes through the floor because your ACKs don't get through. This just says that if your routers prioritize ACKs, your downstream will still be fine even if your upstream is saturated. This isn't exactly new, my cable ISP already does this.

Re:This will be of most use to ... (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440512)

So why now? Why did *BSD fail? Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

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.

Re:This will be of most use to ... (-1)

Anonymous Coward | more than 11 years ago | (#5440447)

You are a fucking moron.

Try using your cable upstream at full capacity, and then tell me your downstream is as fast ever.

Now try limiting your upstream so that it uses 90-95% of its capacity, and compare your downstream.

This benefits everybody whether they use a modem or some fuck off big pipe straight to the backbone. If your upstream is full, your downstream suffers.

Remember, YOU are a fucking moron.

Uh, no, I don't think so (4, Informative)

somethingwicked (260651) | more than 11 years ago | (#5440463)

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

Re:Uh, no, I don't think so (1)

aminorex (141494) | more than 11 years ago | (#5440739)

If you *really* want to speed things up, send
pre-emptive ACKs before you get the data, right
about when they would be expected.

What, you lost a packet? Go back and fetch it
later using the application-layer protocol.

Voila, hyper-http.

Re:Uh, no, I don't think so (1)

addaon (41825) | more than 11 years ago | (#5440818)

If you're using an application-layer protocol anyway, just use UDP and save the bandwidth on ACK entirely.

Re: Kinda been done with TFTP (2, Informative)

somethingwicked (260651) | more than 11 years ago | (#5440851)

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

TCP Daytona (3, Informative)

Patrick (530) | more than 11 years ago | (#5440911)

send pre-emptive ACKs before you get the data, right about when they would be expected.

The technique you suggest is one of several proposed by Stefan Savage in TCP Congestion Control with a Misbehaving Receiver [washington.edu] . He called it TCP Daytona. :)

same bandwidth in relation to what ? (0, Flamebait)

johnjones (14274) | more than 11 years ago | (#5440501)

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

Re:same bandwidth in relation to what ? (1)

adzoox (615327) | more than 11 years ago | (#5440594)

Same bandwidth on my laptop whether optimized with this solution or any connection that I can connect to.

A T1 to T1 connection usually gets me no better gameplay or internet page render speed than a cable modem connection or DSL connection or WiFi connection.

Re:This will be of most use to ... (0)

Anonymous Coward | more than 11 years ago | (#5440614)

don't confuse the internet with the WWW. websites may not see a great deal of performance boost with direct connections, but direct connections and WANs can always be improved upon.

Re:This will be of most use to ... (1)

adzoox (615327) | more than 11 years ago | (#5440656)

I agree about the generalization, but aren't large corporate networks already optimized (in theory)?

From one of the links - Script for linux (-1)

Anonymous Coward | more than 11 years ago | (#5440382)

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:

Re:From one of the links - Script for linux (1)

REBloomfield (550182) | more than 11 years ago | (#5440396)

lol, some tags wouldn't go amiss ;)

Re:From one of the links - Script for linux (0, Redundant)

spydir31 (312329) | more than 11 years ago | (#5440492)

looks like Wondershaper [lartc.org] to me.

Optimized ACKs (0)

somethingwicked (260651) | more than 11 years ago | (#5440386)

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!

*BSD is dying (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440388)

It is official; Netcraft now confirms: *BSD is dying

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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] 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

We figured this before (5, Interesting)

Thijssss (655388) | more than 11 years ago | (#5440389)

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?

Re:We figured this before (0)

Anonymous Coward | more than 11 years ago | (#5440623)

Write your own software for the windows platform or run everything thru a wmware linux-router..

Re:We figured this before (0)

Anonymous Coward | more than 11 years ago | (#5440711)

Decrease his MTU from 1500 to 128. The small window will make certain that his upload won't be a problem.

The problem is (2, Interesting)

anthony_dipierro (543308) | more than 11 years ago | (#5440392)

some P2P software will start distributing a "P2P accelerator" which marks all packets as ACKs.

Re:The problem is (4, Informative)

The Evil Couch (621105) | more than 11 years ago | (#5440565)

it's a possible way to game the system, however they can also ignore what the packets are marked as and just boost the priority of the smaller packets, which are almost always system messages. if the bump up everything under 64 bytes, then they'd get the same effect, but without the possibility of someone cheating the system like that. though I'm pretty sure someone else has already done that.

Re:The problem is (0)

Anonymous Coward | more than 11 years ago | (#5440631)

We only priorize TCP ACKS which have no data payload. thus, this will not work.

henning@cv.openbsd.org

Interesting (3, Interesting)

Ec|ipse (52) | more than 11 years ago | (#5440397)

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.

Very nice solution! (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5440399)

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.

Re:Very nice solution! (1)

Oculus Habent (562837) | more than 11 years ago | (#5440470)

Not completely. If you have a severe up/downstream difference, providing priority to packets on your end will improve the availability of your bandwidth, even when you are maxing it out.

Linux solution (3, Informative)

eddy (18759) | more than 11 years ago | (#5440400)

The Linux Advanced Routing & Traffic Control HOWTO [lartc.org] discuss how to achieve the same thing on linux using QoS. See section 9.2.2.2 [lartc.org] (Sample configuration)

Re:Linux solution (5, Informative)

pe1rxq (141710) | more than 11 years ago | (#5440499)

No it doesn't....
It is a differend solution to a different problem caused by the same thing....

The cause is the big cache in the modem, it results in a delay on outgoing traffic.
One problem is that interactive traffic gets, well, less interactive (e.g. the echo characters in a remote shell have a delay). This is solved in the HOWTO you refered to.
Another problem is that the downstream acks get delayed resulting in less downstream data. This is solved in the mentioned article.

A combination of the two would be really great and could probably be done in both linux and openbsd.

Jeroen

Re:Linux solution (0)

Anonymous Coward | more than 11 years ago | (#5440534)

See here. [slashdot.org]

Note how Wondershaper does it all? Who needs BSD?

Re:Linux solution (1)

eddy (18759) | more than 11 years ago | (#5440560)

Yes it dows. It's not a different problem. I can only read the description; "how to better utilize available bandwidth", which is exactly what the FAQ describes how to do (that is, making sure the ACKs get through so that uploading doesn't kill your downloads, which gives better utilization).

If the article _IS NOT_ about "how to better utilize available bandwidth" then I guess you have a point, but then I can only suggest you address the submitter and ask him to properly describe his submissions in the future.

My solution: (5, Funny)

Black Parrot (19622) | more than 11 years ago | (#5440401)


Put lower priorities on p0rn, MP3s, Windows viruses, and Slashdot referrals. That should speed everything else up by about two orders of magnitude.

Re:My solution: (1, Funny)

beowulfcluster (603942) | more than 11 years ago | (#5440451)

But... what else is there than p0rn, mp3s, Windows viruses and Slashdot referrals that could fill the void...?

Michael Jackson specials (-1, Offtopic)

200_success (623160) | more than 11 years ago | (#5440666)

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.

Re:My solution: (5, Funny)

radish (98371) | more than 11 years ago | (#5440912)

What is this "everything else" of which you speak?

Note the article is all about low bandwidth setups (4, Insightful)

jj_johny (626460) | more than 11 years ago | (#5440402)

Daniel has done some good work in micromanaging the available bandwidth to make sure that ACKs get through to minimize retransmits due to drops as well as other causes. When you look at low bandwidth links the time in queue and to transmit can be much bigger than the near instananious transmission times that you expect on high capacity lines.

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.

What the hell? (-1)

Anonymous Coward | more than 11 years ago | (#5440626)

some moron claiming he read the article.
people just don't read articles on slashdot.

Re:Note the article is all about low bandwidth set (1)

Jennifer Ever (523473) | more than 11 years ago | (#5440915)

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.

Very Usefull (2, Interesting)

volts (515080) | more than 11 years ago | (#5440404)

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.

erm... (0, Offtopic)

lingqi (577227) | more than 11 years ago | (#5440411)

Be sure to check ot the nice graphs!

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?

Daniels original email (5, Informative)

blkwolf (18520) | more than 11 years ago | (#5440412)

You can find Daniels original email on the subject at:
http://marc.theaimsgroup.com/?l=openbsd-pf&m= 10463 0260218727

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 /.'d graphs

./ed (1)

solcity (652067) | more than 11 years ago | (#5440420)

hmm.. ./ed already Looks like ./ proved him wrong on this one!

Re:./ed (0)

Anonymous Coward | more than 11 years ago | (#5440580)

what's dot-slash?

Article title should read: reduce latency (1, Informative)

Anonymous Coward | more than 11 years ago | (#5440421)

Bandwidth is fixed. Any number of crappy operating systems can max out bandwidth. What they meant to say is how to reduce latency.

Title is correct! (5, Interesting)

DarkMan (32280) | more than 11 years ago | (#5440715)

Your correct, bandwidth is fixed. This is about better bandwidth utilisation.

The article is /.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 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.

*BSD is dead (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440436)

It is now official. Netcraft has confirmed: *BSD is dying

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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] 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

Trip down memory lane... (3, Interesting)

eldimo (140734) | more than 11 years ago | (#5440458)

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.

Re:Trip down memory lane... (1)

heh2k (84254) | more than 11 years ago | (#5440693)

there's nothing "infamous" about zmodem. it was widely used and not just on warez boards.

Re:Trip down memory lane... (3, Informative)

Surak (18578) | more than 11 years ago | (#5440748)

Ummm...

A) Zmodem is still around, at least in the *nix world. You can get lrzsz from here [www.ohse.de] .
Some telnet clients still support Zmodem, and you can use lrzsz to transfer files via telnet. Personally, I'd rather use ssh as it's a lot more secure, but in cases where either you can only use telnet or when you are on network you can trust (i.e., not the Internet), you can still use Zmodem.

b) Zmodem is not, nor has it ever been a bidirectional protocol -- you can't upload and download at the same time unless you have two different connections. There *were* protocols that would let you do this (Puma comes to mind), but you most decidedly could NOT do this with Zmodem.

Re:Trip down memory lane... (1)

syle (638903) | more than 11 years ago | (#5440806)

No, zmodem was one-way, though it was the most widely used (everywhere, not just BBS or warez). It was usually slightly faster than ymodem and leaps and bounds above xmodem. I'm fairly sure the bidirectional protocol was just called 'bimodem.'

Re:Trip down memory lane... (1)

rayvd (155635) | more than 11 years ago | (#5440899)

The bidirectional protocol I recall using was HS/Link. Heck, the protocol even had a chat interface so you could talk with the sysop or user on the other end as you transferred!

Re:Trip down memory lane... (1)

emf (68407) | more than 11 years ago | (#5440906)

I think the protocol that let you upload & download at the same time was bimodem. It also let you chat with the sysop while the file transfers where going.

It was released on December 7, 1988.

Here's a link to textfiles.com timeline [textfiles.com]

*BSD is DYING (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#5440460)

It is official; Netcraft confirms: *BSD is dying

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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] 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

The price of failure -- Hard times for *BSD (-1)

Anonymous Coward | more than 11 years ago | (#5440491)

So why now? Why did *BSD fail? Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

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.

.CX Domain (4, Funny)

goldspider (445116) | more than 11 years ago | (#5440509)

Was I the only one who was a little apprehensive about clicking on a link from the .cx domain?

Better Bandwidth Utilization (0, Redundant)

beredon (454896) | more than 11 years ago | (#5440517)

Perhaps they should use it for their site... Shashdotted already.

Security hole (3, Funny)

sn0rt (218268) | more than 11 years ago | (#5440551)

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.

Re:Security hole (5, Interesting)

Arethan (223197) | more than 11 years ago | (#5440889)

It's called SYN flooding. The idea is that a system only has so much memory to work with. Each established TCP session has memory overhead for packet ordering and split packet reassembly. Generally, when a system recienves a SYN packet, it assumes that the session is going to be valid, and it begins the process of completing the TCP session building, which happens to include setting aside some memory for session management.

For each SYN packet you send, you eat up a little bit more memory and CPU time on the victim. Do it enough times, and the system runs out of memory or processor time, and the system becomes unable to perform its regular operations. Effectively causing a Denial of Service.

If you're smart, you'll form the SYN packets to have source addresses that differ from your real IP, otherwise a) you're traceable; and b) your machine will be flooded with SYN/ACKS. If you are even smarter, you'll use an IP that, while valid and routable, belongs to a host that either doesn't exist, or is currently off. Otherwise the 2nd level victim recieving the SYN/ACKs from your initial target will send RSETs for every SYN/ACK, since it never requested to initial the connection. When your target gets the RSET for the SYN/ACK, it will close the session, freeing up the memory and CPU time that you are desparately trying to fill. Essentially, a non-existant host will never respond to a SYN/ACK, so the target system has to wait for a timeout duration before closing the session, which makes it easier for you to eat up CPU and memory. Unfortunately though, the fake spirce IP on your SYN packets will likely have to be within your ISP's network range, as all smart ISP network administrators perform egress packet filtering to prevent such attacks from originating within their network.

Better tactics include sending the SYNs from multiple machines that have different providers. Thus preventing load from the SYN/ACKs from filling your ISPs pipe. This effectively makes the attack a DDoS, rather than a DoS.

Either way, you can't really perform these attacks in much safety, as competent network administrators will have sniffers in place to detect these attacks as they cross their network. So #1) if your ISP admin is smart, you're busted by them regardless; and #2) if the chain of smart admins follows you all the way back to your sources, you're busted by the authorities (which if you cross state lines means the Feds, which will suck quite adamently).

So, that is how it works, but I wouldn't recommend trying it.

You're not fooling me (0, Offtopic)

mao che minh (611166) | more than 11 years ago | (#5440579)

I don't click on any .cx domains!

Bandwidth Throttle Control (0)

Anonymous Coward | more than 11 years ago | (#5440590)

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.

It looks like..... (1)

whazzy (620752) | more than 11 years ago | (#5440639)

...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:-)

Slashdotted - Mirror (5, Informative)

SILIZIUMM (241333) | more than 11 years ago | (#5440641)

Since the website seems slashdotted now I've set up a mirror. You can see it there [infinit.net] .

Re:Slashdotted - Mirror (-1)

Anonymous Coward | more than 11 years ago | (#5440697)

jesus christ.. .

don't click, it's a goatse.cx link.

Better Bandwidth Utilization... (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5440652)

Less pr0n and warez?

Try it (4, Funny)

genka (148122) | more than 11 years ago | (#5440683)


"OpenBSD 3.3 beta is now stable enough for daily use, so why not download a snapshot [openbsd.org] from one of the mirrors [openbsd.org] and try it out?"


Windows XP is now stable enough for daily use, so why not download a snapshot [kazaalite.tk] from one of the mirrors [sharereactor.com] and try it out?"

(intended as a joke)

Broadband implications (2, Insightful)

Arethan (223197) | more than 11 years ago | (#5440687)

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...

Remove HTML cruft (0)

Anonymous Coward | more than 11 years ago | (#5440756)

Removing M$ and dreamweaver specific cruft in HTML and forbiding sending of html email would do a lot to help conserve bandwidth.

*BSD is dying (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5440786)

It is official; Netcraft now confirms: *BSD is dying

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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] 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

this may break TCP flow control! (5, Interesting)

mekkab (133181) | more than 11 years ago | (#5440843)

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 [dieoff.com] )

Yes, I agree that this is a big-O style worse case scenario, but its something to consider.

W. Richard Stevens TCP/IP Illustrated, Volume 1 (5, Informative)

puzzled (12525) | more than 11 years ago | (#5440880)



It seems to me that a great many /. readers have a cursory knowledge of how TCP/IP works. This is true of almost every other topic and I don't have a generalized solution for ignorance, but in this case a quick read of the first volume of Stevens' excellent TCP/IP Illustrated Series should do the trick.

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 /. reader's hearts - the god given right to steal music by treating a retail DSL/Cable connection like a dedicated wholesale circuit being the prime example - that are more easily understood after a read of these two books.

If you're impatient you can look at my journal - I've covered some of the issues there.

Yeah ok (0)

Anonymous Coward | more than 11 years ago | (#5440881)

Hi

hum i have been doing this for a long time now
in 2.4.x linux kernel

is this not yesterdays news ?

OpenBSD and why I don't use it... (1)

LoneRanger (81227) | more than 11 years ago | (#5440887)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?