[9fans] snoopy oddity

[9fans] snoopy oddity

[erik quanstrom]

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(0000000000000000000000000000000000000000000000000000000000000000)

- erik

Re: [9fans] snoopy oddity

[Russ Cox]

> 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

Re: [9fans] snoopy oddity

[erik quanstrom]

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

Re: [9fans] snoopy oddity

[Russ Cox]

> 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

Re: [9fans] snoopy oddity

[erik quanstrom]

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

Re: [9fans] snoopy oddity

[ron minnich]

On 1/22/07, erik quanstrom <quanstro@coraid.com> 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 520µs.

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