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
:...
: 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
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
...
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
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)
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.
How
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) {
: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
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
: 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 the
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
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 http://www.backplane.com/diablo/hard.html and
scroll
: clueful person bitten by this:
:
:hard-wire your duplex setting on your machine and also on the switch
:
: If you check http://www.backplane.com/diablo/hard.html and
:scroll down to the "Network:" section (from the looks of things,
:written sometime back in 1997 or perhaps 1998),
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
able
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
:
: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.
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
:
: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
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 packets
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
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
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
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!
All
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 lander
In message [EMAIL PROTECTED], Garrett Wollman write
s:
On Tue, 21 Dec 1999 12:50:50 -0800 (PST), Matthew Dillon
[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
On Tue, 21 Dec 1999 22:13:51 +0100, Poul-Henning Kamp [EMAIL PROTECTED] 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
:
: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
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
28 matches
Mail list logo
