It could be that pingpong is biting you because of the occasional
write from blue to xed:
1. 1012942315.229586 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
P 2:3(1) ack 1534 win 8931 <nop,nop,timestamp 85699266 877445890> (DF)
blue -> xed: ack 1534 TIME=0
2. 1012942315.230563 eth0 > xed.acl.lanl.gov.2709 >
blue.acl.lanl.gov.32790:
P 1534:1618(84) ack 3 win 5792 <nop,nop,timestamp 877445891 85699266> (DF)
xed -> blue: send 84 bytes upto 1618 TIME=0.9ms
3. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
. 3:3(0) ack 1618 win 8931 <nop,nop,timestamp 85699270 877445891> (DF)
blue -> xed: ack 1618 TIME=38ms
dont have the previous context, but if the ack in 1. caused pingpong
to flip, then the next ack should be delayed, which it is. since this
ack maxes out the delay, and no data is sent in the opposite
direction,
pingping state will reverse to sending acks immediately again.
4. 1012942315.268651 eth0 > xed.acl.lanl.gov.2709 >
blue.acl.lanl.gov.32790:
P 1618:2295(677) ack 3 win 5792 <nop,nop,timestamp 877445930 85699270>
(DF)
xed -> blue: send 772 bytes upto 2295 TIME=0
5. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
. 3:3(0) ack 2295 win 10305 <nop,nop,timestamp 85699270 877445930> (DF)
blue -> xed: ack 2295 TIME=0
the ack is not delayed, i'm presuming because pingpong will have
reversed again.
6. 1012942315.268651 eth0 > xed.acl.lanl.gov.2709 >
blue.acl.lanl.gov.32790:
P 2295:3067(772) ack 3 win 5792 <nop,nop,timestamp 877445930 85699270>
(DF)
xed -> blue: send 772 bytes upto 3067 TIME=0
7. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
. 3:3(0) ack 3067 win 11580 <nop,nop,timestamp 85699270 877445930> (DF)
blue -> xed: ack 3067 TIME=0
the ack is not delayed because we are back in quickack mode.
8. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
P 3:4(1) ack 3067 win 11580 <nop,nop,timestamp 85699270 877445930> (DF)
blue -> xed: send 1 byte upto 4 TIME=0
this hurts - because the ack wasnt piggybacked and data went in the
other direction, so delaying the ack would have helped here. pingpong
gets reversed again, so the next time, we should try delaying the ack
again.
9. 1012942315.269628 eth0 > xed.acl.lanl.gov.2709 >
blue.acl.lanl.gov.32790:
P 3067:3151(84) ack 4 win 5792 <nop,nop,timestamp 877445931 85699270> (DF)
xed -> blue: send 84 bytes upto 3151 TIME=0
10. 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
. 4:4(0) ack 3151 win 11580 <nop,nop,timestamp 85699274 877445931> (DF)
blue -> xed: ack 3151 TIME=39ms
so this time, we delay the ack again. no data going back, however, so
its useless again. since the delayed ack timer had to go off, we will
reverse pingpong and go back to acking immediately.
11. 1012942315.308693 eth0 > xed.acl.lanl.gov.2709 >
blue.acl.lanl.gov.32790:
P 3151:3828(677) ack 4 win 5792 <nop,nop,timestamp 877445971 85699274>
(DF)
xed -> blue: send 677 bytes upto 3828 TIME=0
12. 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 >
xed.acl.lanl.gov.2709:
. 4:4(0) ack 3828 win 13124 <nop,nop,timestamp 85699274 877445971> (DF)
blue -> xed: ack 3828 TIME=0
we dont delay the ack therefore.
[ snip ]
So because the sender side writes are sending only a partial frame at a
time, and the receiver never has several frames to be acked which might
avoid a delayed ack. The rcvr never sends out data frequently enough
for the delayed acks to be effective. This is a worst case toggle of
pingpong whenever the receiver does do a write - the next ack will be
unnecessarily delayed...
If the sender accumulated the writes (sending more than a frame at a time)
(or the receiver doesnt delay its acks...
thanks,
Nivedita
|