2001-02-16 08:59:10

by Rogier Wolff

[permalink] [raw]
Subject: 8139 full duplex?


Hi All,

I have a bunch of computers with 8139 cards. When I moved the cables
over from my hub to my new switch all the "full duplex" lights came on
immediately.

Would this mean that the driver/card already were in full-duplex? That
would explain me seeing way too many collisions on that old hub (which
obviously doesn't support full-duplex).

(Some machines run 2.2 kernels, others run 2.4 kernels some run the
old driver, others run the 8139too driver).

Roger.

--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.


2001-02-16 09:32:59

by James A Sutherland

[permalink] [raw]
Subject: Re: 8139 full duplex?

On Fri, 16 Feb 2001, Rogier Wolff wrote:

>
> Hi All,
>
> I have a bunch of computers with 8139 cards. When I moved the cables
> over from my hub to my new switch all the "full duplex" lights came on
> immediately.

That's what you would expect: they will auto-negotiate full duplex, in the
same way they would negotiate 10 or 100 Mbit/sec.

> Would this mean that the driver/card already were in full-duplex?

No, that's not possible. They just automatically configured for the
best performance available - in this case, full duplex.

> That would explain me seeing way too many collisions on that old hub
> (which obviously doesn't support full-duplex).

No, it would just prevent your card working. Large numbers of collisions
are normal during fast transfers across a hub.


James.

2001-02-16 09:41:19

by Rogier Wolff

[permalink] [raw]
Subject: Re: 8139 full duplex?

James Sutherland wrote:
> > That would explain me seeing way too many collisions on that old hub
> > (which obviously doesn't support full-duplex).
>
> No, it would just prevent your card working. Large numbers of collisions
> are normal during fast transfers across a hub.

Why would it completely "not work"?

As long as the host doesn't have something to send while a recieve is
in progress, everything should work. A friend reports that he spent
lots of time trying to debug a network where "too many" collisions
were happening. Turns out one card was in full-duplex, while the other
side wasn't.

I benchmarked my old network at 10-12 seconds for a 100Mb
transfer. That sounds indeed as if there isn't a whole lot of
collisions happening. And I can immagine that the acks run into the
next data-packet all the time, so that performance would indeed be
very bad if the card was misconfigured. On the other hand I had one
machine that was taking 180 seconds for the 100Mb transfer.

Anyway, I remember fiddling with the eexpress 100 driver, and there
the driver was involved in switching the speeds, and doing some
management of the switchover of full-duplex/half-duplex. I'd expect
some message from the driver if it saw such a change.

But you're saying that the 8139 chip does it internally, and fully
automatically? Ok. Good.

Roger.

--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.

2001-02-16 09:47:09

by Jeff Garzik

[permalink] [raw]
Subject: Re: 8139 full duplex?

On Fri, 16 Feb 2001, Rogier Wolff wrote:
> I have a bunch of computers with 8139 cards. When I moved the cables
> over from my hub to my new switch all the "full duplex" lights came on
> immediately.
>
> Would this mean that the driver/card already were in full-duplex? That
> would explain me seeing way too many collisions on that old hub (which
> obviously doesn't support full-duplex).
>
> (Some machines run 2.2 kernels, others run 2.4 kernels some run the
> old driver, others run the 8139too driver).

Some versions of the driver bork the LED register, which may lead to
false assumptions.

Grab 2.4.1-ac, which includes the latest 8139too, and see what 'dmesg'
say about its autonegotiation...

Jeff




2001-02-16 10:03:45

by Rogier Wolff

[permalink] [raw]
Subject: Re: 8139 full duplex?

Jeff Garzik wrote:
> On Fri, 16 Feb 2001, Rogier Wolff wrote:
> > I have a bunch of computers with 8139 cards. When I moved the cables
> > over from my hub to my new switch all the "full duplex" lights came on
> > immediately.
> >
> > Would this mean that the driver/card already were in full-duplex? That
> > would explain me seeing way too many collisions on that old hub (which
> > obviously doesn't support full-duplex).
> >
> > (Some machines run 2.2 kernels, others run 2.4 kernels some run the
> > old driver, others run the 8139too driver).
>
> Some versions of the driver bork the LED register, which may lead to
> false assumptions.

Does the driver control the led on my switch?????

(My cards just have a "link" led, and a "100Mbps" led)

I'm not going back to the hub after upgrading just to see the
changeover messages. I'm confident that we're running full-duplex now
on the switch and that that's OK with the switch. I was just wondering
wether this confirmed my suspicion that there was something wrong with
the /duplexicity/.

Roger.

--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.

2001-02-16 10:10:18

by Alan

[permalink] [raw]
Subject: Re: 8139 full duplex?

> Would this mean that the driver/card already were in full-duplex? That
> would explain me seeing way too many collisions on that old hub (which
> obviously doesn't support full-duplex).

Most likely it means they were set to autonegotiate

2001-02-16 10:52:54

by Roeland Th. Jansen

[permalink] [raw]
Subject: Re: 8139 full duplex?

On Fri, Feb 16, 2001 at 10:40:53AM +0100, Rogier Wolff wrote:
> Why would it completely "not work"?


experience maybe. telnet works just fine. a copy would end in a _very_
slow transfer. and if I say slow, I mean a few kbytes/sec. depends on
the number of colls as well.

besides, what gains are expected with full duplex... aproximately none ?

--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 2x466MHz / 256 MB | on Usenet. _\_v

2001-02-16 11:20:14

by James A Sutherland

[permalink] [raw]
Subject: Re: 8139 full duplex?

On Fri, 16 Feb 2001, Rogier Wolff wrote:

> James Sutherland wrote:
> > > That would explain me seeing way too many collisions on that old hub
> > > (which obviously doesn't support full-duplex).
> >
> > No, it would just prevent your card working. Large numbers of collisions
> > are normal during fast transfers across a hub.
>
> Why would it completely "not work"?

It wouldn't be able to detect collisions, I suspect; you might be able to
get data through, though. Not something I've ever wanted to try :-)

> As long as the host doesn't have something to send while a recieve is
> in progress, everything should work. A friend reports that he spent
> lots of time trying to debug a network where "too many" collisions
> were happening. Turns out one card was in full-duplex, while the other
> side wasn't.

On a crossover cable direct between two machines, that would make sense:
you would WANT both cards full duplex, but if one ran half duplex instead,
it would think it was getting a huge number of collisions when it
wasn't...

> I benchmarked my old network at 10-12 seconds for a 100Mb
> transfer. That sounds indeed as if there isn't a whole lot of
> collisions happening. And I can immagine that the acks run into the
> next data-packet all the time, so that performance would indeed be
> very bad if the card was misconfigured. On the other hand I had one
> machine that was taking 180 seconds for the 100Mb transfer.

Ouch! Remember each collision only knocks out a few hundred bytes -
perhaps 1.5K - so even hundreds of collisions per second only knock a few
hundred K/sec off a transfer rate of ten Mbyte/sec or so.

> Anyway, I remember fiddling with the eexpress 100 driver, and there
> the driver was involved in switching the speeds, and doing some
> management of the switchover of full-duplex/half-duplex. I'd expect
> some message from the driver if it saw such a change.
>
> But you're saying that the 8139 chip does it internally, and fully
> automatically? Ok. Good.

Well, mine do anyway :-)

(Except under the Win2k bug, where I needed to force the link to 100
Mbit/sec full duplex...)


James.

2001-02-16 11:24:44

by James A Sutherland

[permalink] [raw]
Subject: Re: 8139 full duplex?

On Fri, 16 Feb 2001, Rogier Wolff wrote:
> Jeff Garzik wrote:
> > On Fri, 16 Feb 2001, Rogier Wolff wrote:
> > > I have a bunch of computers with 8139 cards. When I moved the cables
> > > over from my hub to my new switch all the "full duplex" lights came on
> > > immediately.
> > >
> > > Would this mean that the driver/card already were in full-duplex? That
> > > would explain me seeing way too many collisions on that old hub (which
> > > obviously doesn't support full-duplex).
> > >
> > > (Some machines run 2.2 kernels, others run 2.4 kernels some run the
> > > old driver, others run the 8139too driver).
> >
> > Some versions of the driver bork the LED register, which may lead to
> > false assumptions.
>
> Does the driver control the led on my switch?????

No, the switch does that.

> (My cards just have a "link" led, and a "100Mbps" led)

Ah... Mine have an FD indicator. I think - it's a while since I last
looked closely enough at the back of the machine to tell :)

> I'm not going back to the hub after upgrading just to see the
> changeover messages. I'm confident that we're running full-duplex now
> on the switch and that that's OK with the switch. I was just wondering
> wether this confirmed my suspicion that there was something wrong with
> the /duplexicity/.

I suppose one machine could have auto-negotiated wrongly - was it a Linux
box? I've seen Win2k fail to negotiate the best settings - running HD on a
switch - but I haven't seen FD on a hub...


James.