TCP issue

[Martin Kocian]

Hi Wesley,

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?

Thanks,

Martin

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:
>> 
>> Hi,
>> 
>> 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.
>> 
>> Thanks,
>> 
>> Martin
>> 
>
>
>
> -- 
> Wes Eddy
> MTI Systems
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>

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