I've got a very strange puzzle I'm trying to sort out and thought I'd
ask the list and see what everyone has to say about it.

I wrote a few days ago about how a server system I set up was sending
traffic out in "bursty" patterns. First, a recap:

Celeron, 256 MB, RAIDFrame root, fxp0 (built-in Asus w/ i82557)
is hooked up directly next to a Linux machine. They both have been
allocated IP addresses within the same class C. (216.86.100.x)

However, serving the same files, to the same destination, with the
same routes, and the same return routes, the NetBSD machine is serving
up "bursts" while the Linux 2.2.x machine is a constant. Linux lives
on a Pentium II.

Now before I mentioned there was no packet loss..  I lied. There is a
single packet or two going missing every.. five to ten seconds or so.
The time it takes to re-sync the tcp stream actually slows the serving
data down to about 10% that of the Linux box. (Takes about a second to
re-sync).

Also, it appears that the Linux box isn't losing any traffic.

My questions:

.Are there any driver difficulties with fxp0 and the built-in i82557?

.Is there a way to force NetBSD to lower whatever timeout is making my
data stream pause for such a long period?

.Are there any issues with NetBSD-1.5_ALPHA2 that maybe are living in
developer space right now that I should make myself aware of and CVS
update a little more often?

I've done a tcpdump of a transfer from both machines. It appears as
though there are very similar de-sync's happening--two packets go
missing and my local machine sits there and ack's the same packet
again and again until the remote end catches on and re-sends the
missing bits..

Situation: The NetBSD stream misses a packet.. my client machine
sends an ack for the last known good packet.. the netbsd server plows
on..  16060 bytes ahead before realizing my client is still acking the
old packet. It starts sending from the old packet.. and my client
floods with a huge number of acks for the most recent
packets--catching up..  there is no traffic from the NetBSD machine
during this period.. almost like it's choking on the effort?

Hrm..  perhaps there's a larger TCP window size I can enable..? Is
this part of my solution? I've tried anywhere from 16k to 65k tcp
(with sysctl -w) recv/send buffers--same pauses the whole time.

The Linux machine OTOH sends continuously--it appears to re-send the
missing packets, then my client machine ack's the most recent good
packet (same as before) and the stream continues from there--skipping
all the redundant data (same as before) and not halting data
transmission for a moment. (not the same as before.) The de-sync
covers approx 4000 bytes and there is almost no redundant data--the
response of the Linux server is almost instantaneous when my client
acks the most recent packet.

I vaguely remember reading about the TCP algorithm that behaves like
this but I can't seem to remember what it was called.. perhaps there
is a simple answer and I can just do some (undocumented?) sysctl -w to
enable it for my NetBSD box?

I'd like to showcase the fact that my NetBSD machine is the driving OS
behind a multi-million dollar domain name but I want to make sure it's
perfect before I start trumpeting. (The business people paid for it. I
just built the system and installed the daemons.)

thanks for any help, pointers, flames.
i can't describe how much of a pleasure it is to work with NetBSD.. =]

i'm probably just missing something simple..  but help?

Marc
marc@sudog.com