[theseum]

Hey,
With an asynchronous connection, download speeds can be affected by heavy upstream activity. This occurs because after you recieve a TCP packet, you are supposed to send an ACK back to verify that you have recieved it. If your upstream is saturated, the ACK gets queued and if it taked to long to get it out, it screws up the download.

The document: http://www.benzedrine.cx/ackpri.html describes a method for fixing this problem in OpenBSD. Basically, he sets the computer to prioritixe the ACK instructions in the TCP queue. My question is, is this possible in OS X? How?

Thanks!

PS: I cross-posted this is OS X, Unix, and Networking. Feel free to lock/delete if this is a breach of etiquette.

[pat++]

You can use Carrafix.

[eno]

Originally posted by theseum:
My question is, is this possible in OS X? How?

No, nor will it be for some time, I expect.

FreeBSD will get it first, then we'll get it later...

Cheers

[pat++]

Originally posted by eno:
No, nor will it be for some time, I expect.

FreeBSD will get it first, then we'll get it later...

Cheers

Carrafix and Throttle have been able to do this for a long time...
And you can do it on FreeBSD too thanks to dummynet (which is not yet implemented in Mac OS X, but will hopefully be part of Panther)...

[theseum]

thanks for the help! amazing how google fails to turn these things up...

[kennethmac2000]

This is all very well if you are Joe Schmoe with his one computer directly connected to his cable/DSL modem.

However, if you are using a hardware NAT router - as every single person I know with cable or DSL is - the solutions presented here are pretty worthless.

[JB72]

How 'bout that "Turn off delayed acks" option in Cocktail? Is that similar?

- I wish Carrafix was a front-end for Throttle -

[eno]

Originally posted by pat++:
Carrafix and Throttle have been able to do this for a long time...
And you can do it on FreeBSD too thanks to dummynet (which is not yet implemented in Mac OS X, but will hopefully be part of Panther)...

That's incorrect. Carrafix for Mac OS X, and dummynet on FreeBSD do completely different things from the "ACK prioritization" mentioned by the original poster.

Only "Throttled" claims to prioritize empty ACK packets, and I haven't tested it yet, but at least it's open source so I can look at how it's doing it.

[Edit]
Ok. I've had a look at the source and I can can see that throttled may well provide a similar performance increase to the ACK prioritization possible in OpenBSD, but the method used is distinctly different.

The OpenBSD version operates at the level of the kernel, providing system-wide prioritization of outgoing empty ACK packets.

Throttled works by diverting outgoing traffic from common ports (eg. hotline server ports, Carracho, KDX etc) using ipfw to a separate daemon which runs as root with a "nice" value of -20. As such, it is not really working at the level of the kernel, and it will only work for those ports for which you explicitly divert traffic and so it is not system wide.

I stand by my original comments that you won't see this feature (ACK prioritization) on Mac OS X for a long time; although in the meantime, this throttled package clearly provides a viable alternative.
[/Edit]

Now everybody, RTFM and stop spreading disinformation. A good starting point would be to read the article linked to by the original poster.

[theseum]

carrafix uses the same method as throttle (diverting traffic and reordering the packets.)

there is no reason that this method wouldn't work for you if you are using a NAT firewall. it wouldn't compensate for traffic created by other machines in your network, but that doesn't mean that it's "pretty much worthless." Unless you are running bandwidth-intensive applications on multiple machines simultaneously, it wouldn't be a problem. Even if you were running multiple bandwidth-hungry apps, running one of these programs on each of the machines could provide a performence boost. So if you have several machines on your network, but the only one using a lot of bandwidth is your main machine running a P2P app and an online game and a file download(probably a common scenario) then carrafix or throttle would work great for you. if on the other hand you are downloading a file on one machine and running an FTP server on another it won't help as much, but it might be better than nothing...

[pat++]

Originally posted by eno:
I stand by my original comments that you won't see this feature (ACK prioritization) on Mac OS X for a long time; although in the meantime, this throttled package clearly provides a viable alternative.

Thank you for your very helpful comment.

Now everybody, RTFM and stop spreading disinformation. A good starting point would be to read the article linked to by the original poster.

So, we are all assuming that YOU know how to read

[altimac]

That's incorrect. Carrafix for Mac OS X, and dummynet on FreeBSD do completely different things from the "ACK prioritization" mentioned by the original poster.

Only "Throttled" claims to prioritize empty ACK packets, and I haven't tested it yet, but at least it's open source so I can look at how it's doing it.

You are totally wrong on this point : carrafix *does* perform "ACK prioritization" of selected ports since v1.0 It even respects some details of RFCs concerning the TCP PUSH flag to reduce latency...
OK, all is done is userspace contrary to dummynet and it's a performance hit, but it allows MUCH more gui-ness (i think that if you want to make clearly professional, high bandwidth QoS, you don't use OS X as a router anyway ) with ip detection, real time log parsing (for Carraho, Hotline, KDX and much more if i implement it)

there is no reason that this method wouldn't work for you if you are using a NAT firewall. it wouldn't compensate for traffic created by other machines in your network, but that doesn't mean that it's "pretty much worthless."

exactly, you can still use CarraFix to limit each computer throughput to make the sum of both streams equal to your maximum bandwidth... ok this is not perfectly optimal since bandwidth usage may vary, but still better than nothing. ;-)
It would be possible to make CarraFix recognizes other CarraFix program on the network (thanks to rendez vous) and make them communicate between each other to optimize throughput on *ALL* the local network.

[kennethmac2000]

Originally posted by altimac:
It would be possible to make CarraFix recognizes other CarraFix program on the network (thanks to rendez vous) and make them communicate between each other to optimize throughput on *ALL* the local network.

Yes, assuming they were all Macs.

Plenty households these days are made up of several single people (students or young professionals) of whom only one will probably own a Mac.

[pat++]

Originally posted by kennethmac2000:
Yes, assuming they were all Macs.

... or Linux Mandrake 9.1 is supposed to support zeroconf too

[altimac]

quote:
Originally posted by altimac:
It would be possible to make CarraFix recognizes other CarraFix program on the network (thanks to rendez vous) and make them communicate between each other to optimize throughput on *ALL* the local network.


Yes, assuming they were all Macs.

Plenty households these days are made up of several single people (students or young professionals) of whom only one will probably own a Mac.

note that, for the moment, no other platform support this type of distributed throttling
It's just an idea for a next CarraFix revision, but i think it is quite possible to do that, thanks to the user-space domain of Cfx...
If something like that is implemented, it would make os x unique LOL
I imagine using zero conf for Distributed throttling from a kernel task is far more difficult

[Brazuca]

I tried to follow the discussion, but i think I failed:
I'm assuming that turning on Acks and prioritizing Acks are different things.

Is there a noticeable improvement to turning on Acks (mine is reportedly off)? If so, is there a noticeable improvement to prioritizing Acks? Should a regular user do it?

thanks.

[altimac]

Brazuca, the 2 things are really different ;-)

turning *OFF* (not ON) delayed ACKs (option offered by cocktail for example) is not a bad thing for fast connections (DSL and more). But it won't really increase your Download rate on most "file transfer" servers (ftp, Carracho etc...).
Delayed ACK was designed for slow connections : it reduces the number of ACK sent by the receiver to limit BW usage (only 1 ack is sent back, a little bit later, for several packets).
It is particularly useful to turn it *OFF* when you are using "real-time" client server apps on a LOCAL network. Turning it OFF reduces the delay of the answer and you have faster responses (useful for telnet etc... where you want the server to answer immediatly to your keystroke) but it has almost no interest with big file (more than a KB !) transfers.

Prioritizing ACK is a different process which helps your connection to effectively download as fast as it can ! it is a technique particularly useful when you are uploading AND downloading at the same time. like this, ACK packets needed for download will always be sent before the DATA packets you send for upload. This ensure a steady download rate

try carrafix in this case ;-)

[Brazuca]

Thanks Altimac,

This explains a lot. I did a test on DSLreports and it suggested that I turn ON Acks. I won't.