kocian at slac.stanford.edu
Wed Sep 14 16:09:09 UTC 2011
Yes, using quickack mode on Linux would bypass the problem at a minor
expense of network performance.
But shouldn't RTEMS be able to communicate smoothly with a machine that's
using delayed acks which is pretty much standard, i.e. shouldn't this
problem be fixed in RTEMS somehow?
On Wed, 14 Sep 2011, Wesley Eddy wrote:
> That would appear to be implementing part 2 of Nagle's sender SWS
> avoidance that checks whether all queued data can be sent now. It
> appears to be correctly implementing RFC 1122.
> Your other option for optimizing performance is to disabled delayed
> ACKs on the receiver (I believe Linux calls this quickack mode).
> On 9/13/2011 10:24 PM, Martin Kocian wrote:
>> I actually had Nagle disabled but I think it should not really matter in
>> this case because Nagle only applies to buffers that are small enough to
>> send in one packet:
>> if ((idle || tp->t_flags & TF_NODELAY) &&
>> (tp->t_flags & TF_NOPUSH) == 0 &&
>> len + off >= so->so_snd.sb_cc)
>> goto send;
>> I was trying to send a large buffer so len + off >= so->so_snd.sb_cc
>> was false in any case.
> Wes Eddy
> MTI Systems
> rtems-users mailing list
> rtems-users at rtems.org
| Martin Kocian |
| kocian at slac.stanford.edu |
| Stanford Linear Accelerator Center |
| M.S. 95, P.O. Box 20450 |
| Stanford, CA 94309 |
| Tel. (650)926-2887 Fax (650)926-2923 |
More information about the users