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