long delays in sending packets

I recently got a SmartLinc home controller (see
http://www.smarthome.com/2412N/Smart...troller/p.aspx).
This is just a little INSTEON interface with a built in web server.

Unfortunately, while it responds very nicely when I talk to it with a
Windows box or my daughter's IPod Touch, taking to it from Linux is
very, very slow. Tracing with wireshark, it turns out that after the
tcp connection is established (so after the three-way handshake), it
takes the linux box several seconds to get around to sending the actual
GET request.

I've spent some time performing some experiments and taking wireshark
traces, which I've put up at
http://mvlug.org/JoePfeiffer/SlowGetWithSmartLinc

If anybody would like to read the long version of this plea for help,
and/or has any ideas as to what might be going on, I'd very much
appreciate it if you could take a look at that page and the traces, and
let me know -- I've been tearing what little hair I have left out over
this one...

Also, if you'd like more information, just ask.

Maxwell Lol <(E-Mail Removed)> writes:

> Joe Pfeiffer <(E-Mail Removed)> writes:
>>
>> Unfortunately, while it responds very nicely when I talk to it with a
>> Windows box or my daughter's IPod Touch, taking to it from Linux is
>> very, very slow. Tracing with wireshark, it turns out that after the
>> tcp connection is established (so after the three-way handshake), it
>> takes the linux box several seconds to get around to sending the actual
>> GET request.
>
> Perhaps the imbedded device doesn;t know how to handle the TCP options.
> Or else it's the small window size.

Yep, that's it -- if I break up the first message so the first packet I
try to send only has one byte of data, it works correctly. Looks like
there may be a bug in Linux's congestion control...

Maxwell Lol <(E-Mail Removed)> wrote:
> Well, one difference is that 192.158.0.64 sets the window size to
> 5840, instead of 16384. That's smaller than what I would expect from
> a Linux client doing HTTO requests. It also has window scaling,
> SACK and the timestamp options.

5840 is a common value in the classic window field in TCP segments
sent at the beginning of a TCP connection with Linux and window
scaling - Linux will "auto tune" the advertised window to what it
perceives to be the senders congestion window.

s7:~# tcpdump -i eth0 host raj-8510w.americas.hpqcorp.net
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:25:40.932478 IP raj-8510w.51144 > s7.12865: S 3838042231:3838042231(0) win 5840 <mss 1460,sackOK,timestamp 128962593 0,nop,wscale 6>
17:25:40.932518 IP s7.12865 > raj-8510w.net.51144: S 1635387128:1635387128(0) ack 3838042232 win 5792 <mss 1460,sackOK,timestamp 253451027 128962593,nop,wscale 7>
17:25:40.932726 IP raj-8510w.51144 > s7.cup.hp.com.12865: . ack 1 win 92 <nop,nop,timestamp 128962593 253451027>

Initial window of 92 scaled 6 times is what the client is advertising
at this point, which should be several full-MSS segments worth of
data.

If I disable window scaling on both sides the handshake looks like:

s7:~# tcpdump -c 10 -N -i eth0 host raj-8510w.americas.hpqcorp.nettcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:38:51.471031 IP raj-8510w.35870 > s7.12865: S 3369255512:3369255512(0) win 5840 <mss 1460,sackOK,timestamp 129160227 0>
17:38:51.471066 IP s7.12865 > raj-8510w.35870: S 1138261154:1138261154(0) ack 3369255513 win 5792 <mss 1460,sackOK,timestamp 253648660 129160227>
17:38:51.471327 IP raj-8510w.35870 > s7.12865: . ack 1 win 5840 <nop,nop,timestamp 129160227 253648660>

my understanding is that net.ipv4.tcp_moderate_rcvbuf is supposed to
factor-in here as well but I'm not getting that to have a difference
as yet.

> Perhaps the imbedded device doesn;t know how to handle the TCP
> options. Or else it's the small window size.

If the imbedded device echoed-back any of the options in its SYN|ACK
segment, it had better know how to handle them... I have heard
reports of some "intermediate devices" doing bad things with window
scaling options leaving various sides thinking that scaling was
actually going-on when it wasn't. At that point the "tiny window"
sizes become a problem.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Maxwell Lol <(E-Mail Removed)> wrote:
> Ah. Thanks Rick. I should have thought of that. And when the other
> side does not respond to the window scale option, Linux sends a new
> window whose value is not scaled. Gotit.

Yes. However if the other side (say thanks to a busted intermediate
device that thinks saying "wscale 0" equals disabling window scaling)
reports wscale 0 in the SYN or SYN|ACK then linux will presume the
remote is happy with window scaling and will not fall-back on classic
window advertisements.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...