Re: Dropped packets on SUN GEM

[Beezly <beezly@beezly.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 4462 bytes --]

Hi David,

On Tue, 2002-03-12 at 23:14, David S. Miller wrote:
> What I believe happens is that when the RX overflow condition occurs,
> there will be some packets that will be corrupted as a result.

Yep, I expected that, but wouldn't this only be packets which had
*already* entered the RX buffer? These packets are being transmitted at
a rate of one every .1/.2 seconds, so I guess it's unlikely that all
these packets have entered the RX buffer and been zapped. OTOH - I'm
just stabbing away wildly in the dark so I most likely wrong ;)

> I find it really odd that you can reproduce this condition so readily.
> Does it happen under normal usage or do you have to issue a ping flood
> or some other packet intensive job to trigger the problem?  Also, are
> you getting Pause enabled on the link consistently?

I'm not getting the Pause enabled message *at all*. The other host is
100Mbit (I've not got another gigabit host to test against yet).

If I stop doing the ping I notice that I loose TCP/IP connectivity for a
while, but it usually comes back after a period of time (sorry to be so
vague, but I haven't been able to tell how long it takes to come back
exactly).

Interestingly, whilst writing this e-mail, I've been running a ping with
a 1 second interval and no options (so we end up with 84 bytes in the
packet). It did the same thing, but took a lot longer than 14 packets to
recover... (FYI: 195.195.14.1 is across an ADSL link from me -
explaining the high rtt :) )

64 bytes from 195.195.14.1: icmp_seq=258 ttl=239 time=33.0 ms
64 bytes from 195.195.14.1: icmp_seq=259 ttl=239 time=32.4 ms
64 bytes from 195.195.14.1: icmp_seq=260 ttl=239 time=63.1 ms
64 bytes from 195.195.14.1: icmp_seq=261 ttl=239 time=32.3 ms
64 bytes from 195.195.14.1: icmp_seq=262 ttl=239 time=33.2 ms
64 bytes from 195.195.14.1: icmp_seq=263 ttl=239 time=33.8 ms
64 bytes from 195.195.14.1: icmp_seq=264 ttl=239 time=33.4 ms
>From 10.0.0.12 icmp_seq=309 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=310 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=311 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=313 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=314 Destination Host Unreachable
<snip>
>From 10.0.0.12 icmp_seq=370 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=371 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=373 Destination Host Unreachable
>From 10.0.0.12 icmp_seq=374 Destination Host Unreachable
64 bytes from 195.195.14.1: icmp_seq=375 ttl=239 time=1036 ms
64 bytes from 195.195.14.1: icmp_seq=376 ttl=239 time=38.2 ms
64 bytes from 195.195.14.1: icmp_seq=377 ttl=239 time=29.4 ms
64 bytes from 195.195.14.1: icmp_seq=378 ttl=239 time=32.1 ms

So I had another brainstorm, perhaps this is related to the amount of
data transfer /rather/ than packets.

If I do ping -i .1 10.0.0.15 (i.e. an 84 byte packet), I get the
following very interesting results.

64 bytes from 10.0.0.15: icmp_seq=298 ttl=255 time=0.223 ms
64 bytes from 10.0.0.15: icmp_seq=299 ttl=255 time=0.209 ms
64 bytes from 10.0.0.15: icmp_seq=300 ttl=255 time=0.233 ms
64 bytes from 10.0.0.15: icmp_seq=301 ttl=255 time=0.210 ms
64 bytes from 10.0.0.15: icmp_seq=302 ttl=255 time=0.220 ms
64 bytes from 10.0.0.15: icmp_seq=303 ttl=255 time=0.208 ms
64 bytes from 10.0.0.15: icmp_seq=304 ttl=255 time=0.213 ms
64 bytes from 10.0.0.15: icmp_seq=630 ttl=255 time=0.214 ms
64 bytes from 10.0.0.15: icmp_seq=631 ttl=255 time=0.212 ms
64 bytes from 10.0.0.15: icmp_seq=632 ttl=255 time=0.202 ms
64 bytes from 10.0.0.15: icmp_seq=633 ttl=255 time=0.201 ms


i.e. it takes the card 325 packets to recover, yet with 1500 byte
packets... I get, 

1480 bytes from 10.0.0.15: icmp_seq=499 ttl=255 time=0.558 ms
1480 bytes from 10.0.0.15: icmp_seq=500 ttl=255 time=0.561 ms
1480 bytes from 10.0.0.15: icmp_seq=501 ttl=255 time=0.550 ms
1480 bytes from 10.0.0.15: icmp_seq=502 ttl=255 time=0.557 ms
1480 bytes from 10.0.0.15: icmp_seq=503 ttl=255 time=0.547 ms
1480 bytes from 10.0.0.15: icmp_seq=518 ttl=255 time=0.566 ms
1480 bytes from 10.0.0.15: icmp_seq=519 ttl=255 time=0.551 ms
1480 bytes from 10.0.0.15: icmp_seq=520 ttl=255 time=0.552 ms
1480 bytes from 10.0.0.15: icmp_seq=521 ttl=255 time=0.552 ms
1480 bytes from 10.0.0.15: icmp_seq=522 ttl=255 time=0.548 ms

14 packets missing.

325*84  = 27300
14*1500 = 21000

Are these number relevant?

Beezly


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]