Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

:... :> I'm pretty sure that the box was getiting receive interrupts because :> every time I sent a packet to it from the outside systat -vm showed :> a PCI interrupt for the network device. However 'netstat -in 1' did :> not show the statistics for the received packets until 64 h

Re: Odd TCP glitches in new currents

We aren't doing mcast at this time. If there's anyone from Nortel lurking behind this list, UCLA CS is pretty close to throwing out the Accelars due to a lack of tech support response. No, UCLA CS is not capable of doing department-wide mcast because of a set of peculiar bugs in the Accelar's cod

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

... > I'm pretty sure that the box was getiting receive interrupts because > every time I sent a packet to it from the outside systat -vm showed > a PCI interrupt for the network device. However 'netstat -in 1' did > not show the statistics for the received packets until 64 had >

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

On Wed, Dec 22, 1999 at 10:18:56PM -0800, Matthew Dillon wrote: > I'm adding Bill Paul to the list specifically. > > Hmm. Now this is odd! I think I may have found something! > > All of my 'rl' driver cards fail this test: > > apollo# linktest -m 0.1:0.2 -s 16 -f16 lander >

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: > I'm trying to narrow down the area enough that I can mess with the > driver myself and hopefully locate the problem, since it can't be > reproduced easily. I was hoping the ma

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

:> It appears that the 'dc' driver continues to take receive interrupts :> (see the systat -vm snapshot at the end), but winds up not processing :> any of the packets. Except when 64 packets accumulate then suddenly all :> 64 get processed all at once! Then nothing again until t

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: > Heh heh. Sorry about this, I believe I have further information on > another older problem. Bill, remember those ethernet lockups I was > having with the 'xl' driver all those

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Heh heh. Sorry about this, I believe I have further information on another older problem. Bill, remember those ethernet lockups I was having with the 'xl' driver all those months ago that we could never track down? Well, they happen with the 'dc' driver too. But this time

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

:Okay, I patched if_rl.c in -current to fixe the problem demonstrated by :Matt's linktest program. The bug was actually on the receive side of the :rl driver, not the transmit side. A packet can wrap from the end of the :RX buffer back to the beginning, and in some cases these packets would :g

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Okay, I patched if_rl.c in -current to fixe the problem demonstrated by Matt's linktest program. The bug was actually on the receive side of the rl driver, not the transmit side. A packet can wrap from the end of the RX buffer back to the beginning, and in some cases these packets would get lo

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Just a quick note, not entirely on-topic: Bill Paul wrote: [...] >Yes, I know there's a minimum frame length of 60 bytes. And the rl_encap() >routine has the following code: >/* Pad frames to at least 60 bytes. */ >if (m_head->m_pkthdr.len < RL_MIN_FRAMELEN) { >

Re: Odd TCP glitches in new currents

In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >: >:make sure you test odd packet lengths. (as in "not even") >:there are occasional bugs that turn up with that sort of thing. > >Yup. Way ahead of you. > >Hmm. usleep() seems to have a high granularity - only about 150 Hz. >H

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Ok, here's the current status: The RealTek boards ('rl' driver, D-Link brand, RealTek chip vendor) appear to have serious packet loss problems with small packets. The cause is currently unknown. I had two different machines (an older PPro 200 and a somewhat newer K6-2/233) wit

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: > (taking this off -current) > > apollo# linktest -s 51 -f1 lander 1-51 byte payload -> errors > lander# linktest -s 51 -f1 apollo > > apollo# linktest -s 52 -f1 land

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

On Dec 12, 1999 at 01:41:04AM -0500, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Matthew Dillon > had to walk into mine and say: > > > I'm adding Bill Paul to the list specifically. > > > > Hmm. Now this is odd! I think I may have found something! > >

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: > I'm adding Bill Paul to the list specifically. > > Hmm. Now this is odd! I think I may have found something! > > All of my 'rl' driver cards fail this test: Oh sure. Bet the

Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

I'm adding Bill Paul to the list specifically. Hmm. Now this is odd! I think I may have found something! All of my 'rl' driver cards fail this test: apollo# linktest -m 0.1:0.2 -s 16 -f16 lander lander# linktest -m 0.1:0.2 -s 16 -f16 apollo They get about

new linktest program avail (was Re: Odd TCP glitches in new currents)

A new version of linktest is up, much enhanced: * fixes cpu use problems due to calling random() too much * fixes usleep (we now use a pipe and select()) This version can really stuff the network. http://www.backplane.com/FreeSrc/linktest-1.1.c Running the

Re: Odd TCP glitches in new currents

On 1999-Dec-23 15:12:53 +1100, Matthew Dillon <[EMAIL PROTECTED]> wrote: > In fact, while its >running in the background I am *still* getting TCP stutters and tcpdump >still shows one machine sending a packet that the other machine never >gets! I have no friggin clue as to why TCP pa

Re: Odd TCP glitches in new currents

: :make sure you test odd packet lengths. (as in "not even") :there are occasional bugs that turn up with that sort of thing. Yup. Way ahead of you. Hmm. usleep() seems to have a high granularity - only about 150 Hz. How annoying! I've put the linktest program up on my web si

Re: Odd TCP glitches in new currents

make sure you test odd packet lengths. (as in "not even") there are occasional bugs that turn up with that sort of thing. On Wed, 22 Dec 1999, Matthew Dillon wrote: > I am clueless as to what is going on. It seems to only happen with TCP > connections. I wrote a UDP-based packet loss

Re: Odd TCP glitches in new currents

: :There's some oddities in the 3.3 and 3.4 kernels as well -- I've actually :nailed down the plexicity and speed on both the Accellar and my humble PC, :and yet, I'm looking at weird TCP lockups from time to time. : :Mostly seems to be related to NFSv3, but will also happen when doing :cvsup. The

Re: Odd TCP glitches in new currents

On Wed, 22 Dec 1999, Jonathan Lemon wrote: > On Dec 12, 1999 at 11:37:42AM -0800, Matthew Dillon wrote: > I had a Netgear FS509 switch here that would eat packets transmitted > through the GigE port under certain conditions. Netgear shipped me > a new one, and I've been happy with it, until the

Re: Odd TCP glitches in new currents

On Dec 12, 1999 at 11:37:42AM -0800, Matthew Dillon wrote: > I finally tracked it down. The loss is occuring in the link between > two of my switches. The link goes across my apartment - about 60 feet of > Cat-5 cable. That should be well within spec (you are supposed to be > ab

Re: Odd TCP glitches in new currents

:> clueful person bitten by this: :> :>hard-wire your duplex setting on your machine and also on the switch : : If you check and :scroll down to the "Network:" section (from the looks of things, :written sometime back in 1997 or perhaps 1998

Re: Odd TCP glitches in new currents

At 8:00 PM +1300 1999/12/22, Joe Abley wrote: > Sorry if this is stating the obvious, but I've seen more than one > clueful person bitten by this: > >hard-wire your duplex setting on your machine and also on the switch If you check and s

Re: Odd TCP glitches in new currents

On Tue, Dec 21, 1999 at 01:23:05PM -0800, Matthew Dillon wrote: > I just rebooted both machines and it didn't fix the problem. I did a > packet trace on both boxes and there does indeed appear to be packet loss. Sorry if this is stating the obvious, but I've seen more than one clueful pe

Re: Odd TCP glitches in new currents

On Dec 12, 1999 at 04:00:00PM -0500, Garrett Wollman wrote: > <<[EMAIL PROTECTED]> said: > > > I have NOT tested this fix yet, so I don't know if it works, but I > > believe the problem is that on high speed networks the milliscond round > > trip delay is short enough that you can get

Re: Odd TCP glitches in new currents

:> :>Hmmm. I thought we agreed that 200 msec was the minimum reasonable :>RTO. That code doesn't seem to have made it in. : :I assume you mean 20 msec (= 2 tick @ 100 Hz ) ? 200 msec is enough :to get halfway around the globe... : :-- :Poul-Henning Kamp FreeBSD coreteam member I

Re: Odd TCP glitches in new currents

< said: >> Hmmm. I thought we agreed that 200 msec was the minimum reasonable >> RTO. That code doesn't seem to have made it in. > I assume you mean 20 msec (= 2 tick @ 100 Hz ) ? 200 msec is enough > to get halfway around the globe... No, I mean 200 msec. If you make the RTO be any shorter

Re: Odd TCP glitches in new currents

In message <[EMAIL PROTECTED]>, Garrett Wollman write s: ><<[EMAIL PROTECTED]> said: > >> I have NOT tested this fix yet, so I don't know if it works, but I >> believe the problem is that on high speed networks the milliscond round >> trip delay is short enough that you can get 1-tick

Odd TCP glitches in new currents

< said: > I have NOT tested this fix yet, so I don't know if it works, but I > believe the problem is that on high speed networks the milliscond round > trip delay is short enough that you can get 1-tick timeouts. Hmmm. I thought we agreed that 200 msec was the minimum reasonable RT

Odd TCP glitches in new currents

I think this may be due to the timing changes. While typing over a TCP connection, running a remote X client (such as netscape), and so forth I sometimes see momentary 1/10 second hangs, even on a clean, empty network. For a while I thought it was packet loss, but then I real