On Dec 6, 2006, at 6:46 AM, Dieter wrote:
I found a couple more things that don't look right.

000017 IP bsd.63743 > src.65001: . ack 52 win 65535
000107 IP bsd.63743 > src.65001: . ack 52 win 65535
000012 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535
000005 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535
000172 IP src.65001 > bsd.63743: . ack 53 win 4096
000004 IP src.65001 > bsd.63743: F 52:52(0) ack 53 win 4096
000003 IP src.65001 > bsd.63743: . ack 53 win 4096
000016 IP bsd.63743 > src.65001: . ack 52 win 65535
000011 IP bsd.63743 > src.65001: . ack 53 win 112 <------ why does the window suddenly shrink?

I'd guess because both sides have requested that the connection close...it's a bit hard to say because you're not including complete data over the life of a connection, or even the sequence numbers.

("tcpdump -nttt" or "tcpdump -ntttv" would be more informative.)

002366 IP src.rfe > bsd.12340: P 1:1317(1316) ack 1 win 4096
099554 IP bsd.12340 > src.rfe: . ack 1317 win 65535 <------ why does it take 99.5 millisec to ack?

The ack time is normally 12 or 13 microseconds, which seems to be okay.
But 99.5 milliseconds is *way* too slow, data will be lost.

Is TCP sitting around waiting for a second packet, so that
it can be "efficient" and ack two packets at once?

Yup.  Coalescing data before sending it results in less overhead.

What can I do to fix this?  Is there a knob I can turn to say
"ack every packet", or "only wait xxx microseconds for a 2nd packet" ?

You can turn on TCP_NODELAY via setsockopt() to disable the Nagle algorithm. There are probably sysctl's you can tweak, also...

--
-Chuck

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to