any chance the cards are losing out between half and full duplex? Some
cards are not auto select, and some hubs are and some aren't full duplex
capable, though most of the full duplex card specs I've read say they will
autoselect
brian
*
At
>Sorry, I wasn't
Not quite. The idea behind switches is to collapse collision domains. If
you have N machines on shared media (hubs) you have 1 collision
domain of size N. If you replace the hubs with switches, each collision
domain size two and you have N*(N-1) collision domains (i.e., every
combination of t
Interesting.. my pretty hub never gets any collisions tho ;)
I thought the whole idea behind switches was to handle NICs that run at
different speeds.
On Fri, 24 Nov 2000, Rick Warner wrote:
>
>
> Better pull out the Ethernet book. Hubs cannot do full duplex. If they
> tried to transmit and
Do you get collisions like that from the other hub? hubs aren't supposed
to have any collisions ideally. The hub does sound borked tho.
On Fri, 24 Nov 2000, Jack Bowling wrote:
> ** Reply to message from Statux <[EMAIL PROTECTED]> on Sat, 25 Nov
> 2000 00:47:02 -0500 (EST)
>
>
> > What's the ou
** Reply to message from Statux <[EMAIL PROTECTED]> on Sat, 25 Nov
2000 00:47:02 -0500 (EST)
> What's the output of ifconfig look like (while we're at it)? :P
Sorry, should have included that in the last post. Not sure how to
flush the stats from ifconfig to start at ground zero (reboot?). They
Better pull out the Ethernet book. Hubs cannot do full duplex. If they
tried to transmit and receive simultaneously on the same port (full
duplex) a collision would occur and they would have to step
back. Switches can do full duplex, hubs are half duplex only. Always
have been, always will
Um.. hubs do full duplex. Cat5 (and the like) cabling uses two wires for 1
connection (one for TX and one for RX). Coax cable is only half.
On Fri, 24 Nov 2000, Rick Warner wrote:
>
> This one seems to have a big problem. Not only is it flipping on speed,
> but it has negotiated full duplex. S
This one seems to have a big problem. Not only is it flipping on speed,
but it has negotiated full duplex. Since a hub cannot do full-dup
- rick warner
On Fri, 24 Nov 2000, Jack Bowling wrote:
> Hub that works is a 3Com HomeConnect 10Mbps 5-Port Hub model 3C19260.
>
> Nowstick the
What's the output of ifconfig look like (while we're at it)? :P
-Statux
___
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
** Reply to message from [EMAIL PROTECTED] (Luke C Gavel) on Fri,
24 Nov 2000 20:42:15 -0400 (AST)
> Hi,
>
> I've read the thread so far, and here is what I think:
>
> - At least one of your NICs is operating at 100baseT, but not
> all, correct?
Negative. Both NICs are at 10BaseT. Here is the
Hi,
I've read the thread so far, and here is what I think:
- At least one of your NICs is operating at 100baseT, but not
all, correct?
- the new two hubs which are 10/100baseT-capable are trying to
auto-sense the band rate and are getting confused between the
different speed-based NICs.
Correc
>OK, first things first. txqueuelen sets the size of the transmit queue,
>not the speed of the interface. Hardcoding the speed of the interface is
>a bit tricky. If you are using modules for the NIC drivers, some drivers
>take an option which sets speed of the interface. Is there a speed statu
Something you have not mentioned yet...brand and type of hub, and types of
cards being used. Also, if the cards are 10/100, have they been
configured to not autodetect?
On Fri, 24 Nov 2000, Jack Bowling wrote:
> ** Reply to message from Vidiot <[EMAIL PROTECTED]> on Fri, 24
> Nov 2000 03:56:57
OK, first things first. txqueuelen sets the size of the transmit queue,
not the speed of the interface. Hardcoding the speed of the interface is
a bit tricky. If you are using modules for the NIC drivers, some drivers
take an option which sets speed of the interface. Is there a speed status
** Reply to message from Rick Warner <[EMAIL PROTECTED]> on Fri, 24
Nov 2000 09:52:26 -0800 (Pacific Standard Time)
> > Sorry, I wasn't clear. I pinged from all 3 boxes with the same result.
> > The salient fact is that it works with one hub perfectly and not TWO
> > others (I just tried another
> Sorry, I wasn't clear. I pinged from all 3 boxes with the same result.
> The salient fact is that it works with one hub perfectly and not TWO
> others (I just tried another brand of hub this morning) with the same
> settings. And none of the cables are attached to the uplink port of the
> hubs
** Reply to message from Vidiot <[EMAIL PROTECTED]> on Fri, 24
Nov 2000 03:56:57 -0600 (CST)
> >Yes, Vidiot's theory makes sense. However, there is a slim
> >possibility that some switches on the hub are set wrong? Perhaps
> >the 'cascade' button or something similar to that effect is set
> >w
>Yes, Vidiot's theory makes sense. However, there is a slim
>possibility that some switches on the hub are set wrong? Perhaps
>the 'cascade' button or something similar to that effect is set
>wrong on the hub itself. Bear in mind, a crossover cable IIRC is
>necessary between two hubs, and the '
Yes, Vidiot's theory makes sense. However, there is a slim
possibility that some switches on the hub are set wrong? Perhaps
the 'cascade' button or something similar to that effect is set
wrong on the hub itself. Bear in mind, a crossover cable IIRC is
necessary between two hubs, and the 'casca
>Here is one for the gurus. Have a 3-box linux LAN at home. It works
>with one hub perfectly but not with another with the same network
>settings. A big clue that it must have something to do with the cabling
>or internal wiring of the hub is that when monitoring a ping from one
>machine to anothe
Pardon the obvious hardware slant of this post but it IS using two
versions of RH!!
Here is one for the gurus. Have a 3-box linux LAN at home. It works
with one hub perfectly but not with another with the same network
settings. A big clue that it must have something to do with the cabling
or int
21 matches
Mail list logo
