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