Agreed. Indeed I didn't look good enough at packet 1.
Sorry for the waste-of-bandwidth.
Fact remains that with 20% packetloss, (I have a cable that seems to
generate that kind of packetloss), many, many TCP/ip sessions
hang. Even if they generate only about 2 or 4k of datatransfer. I
thought I had cought a "baddie" here, but you set me right on that.
I'll see if I can catch the reason why things seem to hang that
often....
> 12 16:58:20.329548 14dyn184.61101 > bwww.ssh: . 856:856(0) ack 924
> 13 16:58:40.477658 14dyn184.61101 > bwww.ssh: P 856:876(20) ack 924
> 14 16:58:40.744978 bwww.ssh > 14dyn184.61101: . 1696:1696(0) ack 876
Some packet got lost.
> 15 16:59:19.536500 14dyn184.61101 > bwww.ssh: P 876:896(20) ack 924
14dyn acks immediately, but piggy backs some data in the ack.
Isn't it kind of odd, that in the 20 seconds between :20 and :40 the
original packet and something like 3 retransmits were lost? Would
TCP/IP allow bwww to reset the retransmit timer one notch down if it
receives the ack 924 ?
(TCP/IP algorithms are based on the "fact" that packetloss is caused
by overloaded routers. In my case that often isn't the case. I now
found a cable that I could use that generates 20% packetloss, but my
cable-company seems to find 5-10% packetloss in their network
acceptable, and it isn't related to congestion or anything.
Retransmitting every 3 seconds (no exponential backoff) would be the
best strategy to get "things done" under these circumstances).
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- 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/