lkml.org 
[lkml]   [2002]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Dropped packets on SUN GEM
    From
    Date
    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

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:2.476 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site