Messages in this thread | | | Date | Sun, 15 Nov 1998 16:14:17 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] delayed acks decrease performances in congestioned networks |
| |
On Sat, 14 Nov 1998, Kaz Kylheku wrote:
>I'm not sure what you mean, but it sound wrong. How do you know that the >packet is lost? The only way you know that a packet is lost is if you get
Because I would use as sk->ato timeout a smoothed value in function of previous contiguous received packets (and not 0.5 sec as default). But as David said this behavior was buggy and I expect to see it fixed soon.
>one that is out of sequence---and even then, it's possible that packets >have been reordered.
Infact the smoothed value of ato will take care of that (as RTO does for retransmission timeout).
>> suggest people to fix broken networks... But since I can' t fix the >> network I think that delayed acks should be at least removable via >> sysctl. > >You will then be contributing to congestion. Delayed acks are a good idea.
Your one is the straighforward thought. But my network tend to lose acks too and is practically always in slow start so delayed acks happens not very frequently even if enabled. So using delayed acks in the receiver, the sender risks to not get one of the delayed acks and so the sender risks to have to retransmit _two_ _big_ _data_ packets due a timeout even if the receiver has just received such data without gaps. This because here the TCP has to do slow start many times (due timeout) and so it happens very very frequently that the sender has cwnd very low and so if the receiver' s ack got lost the sender has no enough cwnd to send the next two packets and to see with the next delayed ack (supposing it will be not lost btw) that the receiver has received also the previous two not yet acked packets.
>Without delayed acks, you could be reducing the opportunity for an >implementation to piggy back acks. Look at some examples in the Stevens >book.
I don' t have Stevens books, if you would send it to me for free I' ll probably read it (even if it would be wasted time to take the degree here and I like to pass my _totally_wasted_ spare time in programming and not reading ;-). Such reading would be good for the hour and half every day I waste in train without a PC though...
>I don't see how a network that loses 20-25% packets will perform better if you >remove delayed acks. Could you explain the rationale?
I don' t need to do the math since I see the numbers. Doing the math for the congestion issue would be reasonable though.
>If the ack is lost, does it matter whether or not it had been delayed?
This is the wrong example because without delayed acks the receiver has the double probability to send acking info to the sender.
>It sounds like you are trying to garner more performance for yourself at the >expense of the congested network. Imagine if *every* user of that network >implemented similar hacks; the overall condition would worsen!
Even if this would be true the point is that AFIK delayed acks are a SHOULD and _not_ a MUST for RFCs and tcpimpl draft. Since disabling them improve things here, my tree has the tcp_delayed_acks ioctl. If 2.1.129 will make no performance differences with tcp_delayed_acks == 0 I' ll be glad to remove my new sysctl from my tree.
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |