> But if you provide more dumps to help me debug this problem could
> you please rebuild tcpdump with the patch I have appended at the end?
> The stock tcpdump does not output SACK information from TCP packets
> properly without the patch. The stock tcpdump uses the pre-RFC format
> of the SACKS which is nothing like real modern SACKs in use today :-)
Did you forget to append the patch, or is there somewhere I can get it?
> Are you sure the tcpdump was run from 207.75.226.50's side? The
The output was cut&pasted from my console (226.50), and at no time was I
logged into the other box.
> see which ones were received at each ACK. So since it never made it,
> we eat a full retransmit timeout, which is several seconds at this
Ok, I didn't completely understand the SACK protocol. TCP retransmit
timeouts just seem so excessively long...
> True, it sounds really bad.
> But note that from the logs I am seeing here, this connection is
> shotty enough to obtain a 2 minute retransmit timeout from time to
> time due to exponential backoff and the large amounts of loss.
Sounds really bad? No really, it is bad, try transferring with it. :)
A 2 minute delay is HUGE to send only ONE packet SUCCESSFULLY. If the
packets are successful why doesn't it speed up soon? Why does it even
lose speed if the resends were successful? Half an hour is an extremely
long time to take to return to a reasonable transfer speed. I could have
made binary punch-cards by hand, delivered them, and decoded the same
amount of data there before this thing returned to normal. 231.233 is
only 3 hops away from 226.50 and its fairly uncongested in between.
Pretty much the only packets lost are from error correction/modem
renegotiations taking too long.
> Once again, the transfer won't try to get back to full speed until the
> sender gets the data frame with sequence number 239469 acknowledged.
> Your trace cuts off before that point so I can't tell if it exited
> loss recover correctly or not.
>
> I honestly can't see TCP doing anything wrong in these dumps, they are
> all explainable. Really, you can't expect much with 6 second or
> longer round trip delays and such small windows.
It's not the less-than-full speed that bothers me, it's the
absence-of-any speed. If things are retransmitting successfully, why
doesn't it just transmit another packet every time it receives the ack for
the last, like it does when it first happens? I don't see why the
round-trip delays should affect a single-packet transfer mode (and make
the delays 1min 54sec worse). With the current behavior I might as well
write 32bit numbers on rocks and catapult them over to my friend's house,
though the neighbors might not appreciate any "packet loss". :)
> One thing you can try to alleviate this situation is to up the default
> window sizes a bit using the knobs in:
They're already set to 65535, but I don't understand how increasing a
window which seems to be showing 30k free affects the retransmit delays.
Am I reading it wrong or am I just too uneducated on the inner-workings of
TCP?
-- Jeff DeFouw <mrj@i2k.com> I2K Staff - http://www.i2k.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html