TCP packet delay

[Michael Peacock]

I am trying to send a message from a server to a client. The message size is variable but in this case it is around 55k. Occassionly, the message is taking much longer than expected. When looking at the data thru a network analyzer, we are seeing the message broken up to 4k packets of data as expected. The majority of the packets are received quickly. But, some packets are taking a long time (somewhere around 700ms). Anyone have any ideas of what may be causing the packet delay?

[Jeff Schussele]

Hi Michael,

Take a look at the NIC speed/duplex settings.
Say it's lan1 - run

lanadmin -x 1

If you're running half-duplex you'll have inherent collisions and the resultant retransmissions. If the card & switch port are capable of 100 full duplex, then by all means hard set the card & switch port to those values & don't even let them negotiate.

HTH,
Jeff

[Sathish C]

Hi
As the previous responce indicates , I would first check the full duplex/half duples settings ,/etc/nsswitch.conf file hosts and ipnodes entries , and give your mac address to the network person and ask them to check if all the clusters are runnig via the same CAT .

[T G Manikandan]

Just do a

#lanadmin

>lan
>dis

check for any collisions.

Differ with speed/duplex options.

[Steve Lewis]

4k packets?
Sounds like FDDI, not ethernet, unless you have gone jumbo.
If I remember correctly, the FDDI tools to use are fddimon7, ping and pong (linkloop for fddi).
Then you need to try more of a clinical test, perhaps run netstat -s before and after a transfer to see where the error may lie.
Another thing to check is patches. You didn't give your o/s version or patch level, but its always a good thing to check with network issues.

[rick jones]

Where are you taking the trace? On the sending end, or the recieving end?

700ms is a bit longer than the default minimum TCP retransmission timout of 500 ms (tcp_rexmit_interval_min) but if the RTT were long enough I could see 700 ms.

I'm not sure why being broken-up into 4K packets is expected unless you are using FDDI as previously suggested. I suppose if the application is only sending 4096 bytes in each send() call (which is a shame if it has more than that) then you would see the PSH flag set every 4096 bytes.

55K is larger than the default socket buffer size in HP-UX, and is probably larger than the default window size for most client TCP stacks. If there were issues getting a window-update that might show-up - although you might see window probes in the packet trace.

Please post some of the trace (one line format hopefully) from around the time you see a 700 ms delay.

Also, the suggestion to check netstat -s is good - if you are indeed using TCP as I suspect, you can shorten the output by simply doing netstat -p tcp. You want to look for data packets retransmitted and retransmission timeouts. Those suggest lost packets, at which point you look to see why, and at that point you may want to check lanadmin statistics. Also as previously mentioned.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt

[Thomas Bianco]

Some of the older (and possibly newer) HPUX workstations have onboard network cards that are not completely auto detect compliant. This has caused me much grief on many occasions.
If at all possible, hardcode both the client and server to some duplex and speed, then check the switch ports and ensure they are set the same way.