netdev
[Top] [All Lists]

Re: your mail

To: Ronald G Minnich <rminnich@xxxxxxxx>
Subject: Re: your mail
From: "Nivedita Singhvi" <nivedita@xxxxxxxxxx>
Date: Tue, 5 Feb 2002 15:46:01 -0800
Cc: <netdev@xxxxxxxxxxx>, <hendriks@xxxxxxxx>, <matt@xxxxxxxx>
Importance: Normal
Sender: owner-netdev@xxxxxxxxxxx
Sensitivity:

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








<Prev in Thread] Current Thread [Next in Thread>
  • Re: your mail, Nivedita Singhvi <=