> 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

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

> 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

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

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 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