On Fri, Sep 08, 2000 at 03:49:27PM -0700, marc@sudog.com wrote:
> 
> 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?

Not that I'm aware off.

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

I'm not sure. Did you try playing with the net.inet.tcp.* sysctls ?

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

Not that I'm aware off.

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

No, I think it's just because it's waiting for all packets to be ACK'd before
starting again. I also think that a missing packet causes the window size
to drop, which lowers the transfer rate.

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

I don't think. The window size will drop anyway whith a missing packet.

> 
> 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'm not sure this behavior is conform to the RFC. But this is really a question
for a TCP people :)
I you don't get anserws here try to post to tech-net@netbsd.org, with the
tcpdump traces.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--