[9fans] snoopy oddity - Plan9

This is a discussion on [9fans] snoopy oddity - Plan9 ; has anyone seen snoopy miss packets like this? i see the ack for a packet that snoopy never sees. these hosts are connected back-to-back. Δt between the two snoopies is ~45000 ms. target host: [... lots of packets deleted, none ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [9fans] snoopy oddity

  1. [9fans] snoopy oddity

    has anyone seen snoopy miss packets like this? i see the ack for a packet
    that snoopy never sees. these hosts are connected back-to-back.

    Δt between the two snoopies is ~45000 ms.

    target host:

    [... lots of packets deleted, none with a sequence of 3276011294 ...]
    046689 ms
    ether(s=0060dd4785fb d=0060dd47b40c pr=0800 ln=60)
    ip(s=192.168.0.3 d=192.168.0.1 id=5751 frag=0000 ttl=255 pr=6 ln=40)
    tcp(s=6666 d=5123 seq=2082542180 ack=3276011294 fl=AP win=36700 ck=2826)
    [... no packet with seq=3276011294 from 192.168.0.1 follows]

    but the source host did actually send the packet:

    001112 ms
    ether(s=0060dd47b40c d=0060dd4785fb pr=0800 ln=854)
    ip(s=192.168.0.1 d=192.168.0.3 id=646c frag=0000 ttl=255 pr=6 ln=840)
    tcp(s=5123 d=6666 seq=3276011294 ack=2082542180 fl=A win=65535 ck=b46a)
    dump(000000000000000000000000000000000000000000000 0000000000000000000)

    - erik

  2. Re: [9fans] snoopy oddity

    > has anyone seen snoopy miss packets like this? i see the ack for a packet
    > that snoopy never sees. these hosts are connected back-to-back.


    sure. if snoopy isn't reading packets out of the kernel fast enough,
    it will miss some. the kernel can't buffer them up indefinitely.

    for the size of the buffer:

    if you are reading from a snoop file then see
    /sys/src/9/ip/ipifc.c:319 (arg to qopen).

    if you are reading from an ether device then see
    /sys/src/9/pc/devether.c:428,440 (arg to netifinit)

    russ

  3. Re: [9fans] snoopy oddity

    so i would assume that this isn't going to work very well for
    high bandwidth, scaled tcp connections?

    - erik

    On Mon Jan 22 11:56:17 EST 2007, rsc@swtch.com wrote:
    > > has anyone seen snoopy miss packets like this? i see the ack for a packet
    > > that snoopy never sees. these hosts are connected back-to-back.

    >
    > sure. if snoopy isn't reading packets out of the kernel fast enough,
    > it will miss some. the kernel can't buffer them up indefinitely.
    >
    > for the size of the buffer:
    >
    > if you are reading from a snoop file then see
    > /sys/src/9/ip/ipifc.c:319 (arg to qopen).
    >
    > if you are reading from an ether device then see
    > /sys/src/9/pc/devether.c:428,440 (arg to netifinit)
    >
    > russ


  4. Re: [9fans] snoopy oddity

    > so i would assume that this isn't going to work very well for
    > high bandwidth, scaled tcp connections?


    like i said before, it all depends on how fast you can run snoopy.

    if you are maxing out the machine doing tcp, there is not going
    to be much left for snoopy. other ways to avoid losing packets
    include running snoopy redirected into a file (don't get stuck waiting
    for the window system to scroll the window) or running with the -d
    flag (avoid the overhead of formatting the packets for display).

    russ

  5. Re: [9fans] snoopy oddity

    doesn't the size of the snoopy queue need to be somewhat
    proportional to the speed of the connection? a gigabit connection, for eaxmple, could overrun
    QMAX in 520µs.

    - erik

    On Mon Jan 22 16:30:52 EST 2007, rsc@swtch.com wrote:
    > > so i would assume that this isn't going to work very well for
    > > high bandwidth, scaled tcp connections?

    >
    > like i said before, it all depends on how fast you can run snoopy.
    >
    > if you are maxing out the machine doing tcp, there is not going
    > to be much left for snoopy. other ways to avoid losing packets
    > include running snoopy redirected into a file (don't get stuck waiting
    > for the window system to scroll the window) or running with the -d
    > flag (avoid the overhead of formatting the packets for display).
    >
    > russ


  6. Re: [9fans] snoopy oddity

    On 1/22/07, erik quanstrom wrote:
    > doesn't the size of the snoopy queue need to be somewhat
    > proportional to the speed of the connection? a gigabit connection, for eaxmple, could overrun
    > QMAX in 520s.


    yes, but, in the end, if you can't keep up, you can't keep up. You can
    redirect into a file, but, if the file system is slow (which is it on
    Plan 9), then you sooner or later can't keep up. Tuning the queue will
    only let you hold off the day of reckoning, in the hopes that your
    traffic is bursty.

    If you could grab a raw disk partition, and have a way to just dump
    the raw packets on it, that might be your best shot.

    ron

+ Reply to Thread