Re: TCP delayed acks not being delayed?
On Saturday 25 March 2006 21:25, Bill Moran wrote: > Are you sure you're not exceeding the capability of the system to delay > acks? I would have thought not, it maxes-out with a receive space of 15k, and increasing the setting from 20k to 32k had no effect. > Besides, when you're transferring data in one > direction only, it doesn't make sense to delay empty acks. only on a > full-duplex transmissions do you get a benefit by taking measures to > ensure that all packets have data. When you're downloading, _all_ your > acks are empty, so who cares? I though I might be seeing a bug. I was only measuring it because I was thinking of switching to pf/altq and I wanted to know how much to allow for empty-acks. However, I hadn't done the arithmetic before, and I was surprized to see that 13% of my upload was being used. On a 4MB connection, that would be over half the bandwidth. Delayed acks don't affect the download speed on one tcp connection, but they could improve the performance of other traffic, when a download is taking place over a very asymmetric link. > Additionally, if the client application turns nagle off, this will > disable the use of delayed acks. For things like file transfer, it's > pretty much typical practice to disable nagle, I guess that explains it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP delayed acks not being delayed?
RW <[EMAIL PROTECTED]> wrote: > On Saturday 25 March 2006 02:09, RW wrote: > > I have a 1MB/0.25Mb ADSL connection and have an IPFW rule to prioritize > > outgoing empty acks. If I download a single file with kget at 100 kbytes/s, > > I see that the rule gets hit at a rate of 50/s: ie a little under 1 > > empty-ack per incoming packet. > > > > I have: > > > > net.inet.tcp.delacktime: 100 > > net.inet.tcp.delayed_ack: 1 > > > > which I thought should limit each TCP connection to <=10 empty acks per > > second Are you sure you're not exceeding the capability of the system to delay acks? If the receive window drops to 0, the receiving machine _has_ to send an ack, or the data transfer will stall and your performance will suck. It's not terribly difficult to imagine receive buffer vs. transmissions speed combinations that would force it to send empty acks. You might want to use ethereal or tcpdump to analyze the window sizes on your data transmission. I'm guessing that zero sized windows are forcing the acks to be sent. Besides, when you're transferring data in one direction only, it doesn't make sense to delay empty acks. only on a full-duplex transmissions do you get a benefit by taking measures to ensure that all packets have data. When you're downloading, _all_ your acks are empty, so who cares? Additionally, if the client application turns nagle off, this will disable the use of delayed acks. For things like file transfer, it's pretty much typical practice to disable nagle, as it generally doesn't help performance, and occasionally hurts it. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP delayed acks not being delayed?
On Saturday 25 March 2006 02:09, RW wrote: > I have a 1MB/0.25Mb ADSL connection and have an IPFW rule to prioritize > outgoing empty acks. If I download a single file with kget at 100 kbytes/s, > I see that the rule gets hit at a rate of 50/s: ie a little under 1 > empty-ack per incoming packet. > > I have: > > net.inet.tcp.delacktime: 100 > net.inet.tcp.delayed_ack: 1 > > which I thought should limit each TCP connection to <=10 empty acks per > second Sorry, I should have mentioned it's 6.0-RELEASE-p4. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
