Full Duplex and Hub

Greetings all, I've searched the archive but did not find the answer to this question: if I have exactly 2 stations on a hub, is there any reason they cannot use full duplex? If I understand logically how the hub works for exactly 2 stations it should be the same as a cross over cable, right?

This is not for some real issue, more an intellectual curiosity that came to me.

Thanks,

Ben

Reply to
Benjamin M. Stocks
Loading thread data ...

While 'hub' is often used in place of 'repeater', in the more general sense, and often as found for sale, it includes switches.

In normal operation a repeater will detect collisions on any port and properly signal that collision on all ports. There is usually only one datapath in the internal logic, and only enough buffer for a small number of bits.

A repeater will always run half duplex, even when only two stations are active.

A switch will normally negotiate half or full and operate in that mode the whole time.

-- glen

Reply to
glen herrmannsfeldt

Regardless of the confusion that often occurs between hub and switch, I think I see the point your making.

If you assuming that 2 stations connected as if they were on a swap over cable, will not experience collisions, then you would be wrong.

Stuart.

Reply to
Stuart Robinson

Benjamin M. Stocks wrote in part:

No. A hub has only one channel, like coax. So cannot do full duplex. A crossover cable has two channels.

-- Robert

Reply to
Robert Redelmeier

Intellectual?

If you only have two stations, why not just use a cross cable? Hubs are hal-duplex by definition.

Reply to
Frank

I don't think the answers you got addressed your specific question. At least, not as I understand your question.

If you introduce a hub between two PCs, then you will have to use half duplex. The hub is a single-channel device that puts the frames arriving from the Tx pair of any station on a network on the Rx pair of all ports of the hub, in essence. So even if only two PCs are connected via the hub, there would be no way for both PCs to be transmitting simultaneously to each other. Therefore, full duplex can't work with a hub in the way.

If two PCs are interconnected via a crossover cable, they should be able to communicate either in half or in full duplex mode. They would operate differently in the two modes, but both should be feasible.

Let's say the two PCs are set up for half duplex, with crossover cable only between them. In this mode, if PC A wants to transmit a frame, but notices that PC B is already transmitting something (carrier sense), PC A will hold off that transmission. Similarly, if PC A, after sensing no traffic from PC B, begins to transmit a frame, but simultaneously notices a signal coming back from PC B, PC A and PC B will detect a collision, jam, stop, back off, and try again.

It's true that the two PCs *could* also go full duplex and avoid the potential for such collisions, but that doesn't mean they cannot also operate in half duplex. In full duplex, of course, there's no issue with either carrier sense or collision detect, but there might still be an issue with buffers filling up. (In other words, congestion is still possible, but it wouldn't occur in the wire itself.)

So, with a hub in the path, you are constrained to half duplex. With a crossover cable between two PCs, you can use either half or full duplex. With a bridge between two PCs, you can also opt for half or full duplex.

Bert

Reply to
Albert Manfredi

Agreed. There are some wrong answers here, but I think you and albert have it.

I guess that if a comp tries to send while it's receiving(i..e. acts full duplex) , then it'll prob cause a collision in the hub, propagated to all comps, but undetected by comps 'cos they're running full duplex.

Reply to
q_q_anonymous

I retract where I wrote "There are some wrong answers here"

Reply to
q_q_anonymous

q_q snipped-for-privacy@yahoo.co.uk wrote in part:

Possibly, but I think that would depend on the the ethernet chip and drivers software. Since the JAM signal that indicates a detected collision is not supposed to exist on full-duplex networks (filtered at switch), the card/driver might [silently?] fall-back to half duplex.

After all, almost all ethercards are capable of full-duplex, but not all networks are.

-- Robert

Reply to
Robert Redelmeier

Getting philosophical, but not so much about cards - but network interfaces. THerefore not so much distinction between ethercards or interfaces, and the network being FDX or HDX. Since Hubs, switches, any network device, has network interfaces, whether portions of network is FDX or HDX is totally a function of that.

Regarding the Jam signal my understanding and memory of what seifert has written previously on usenet, is that the jam signal is a continuation of the frame, it is to lengthen the frame, nothing unique that is detected. And also, it's not even necessary nowadays. Since a jam is part of the frame, it's not "filtered by a switch".

Maybe it was necessary in the days of really long coax. To do with ensuring that the frame stretched from one end of the coax to the other, - I guess it should anyway - but the jam signal (extending the frame) is for some reason only necessary in the context of a collision.

Switches can operate in FDX of HDX. If you attach a hub to a switch port, it has to operate HDX. (at least at that port) (I guess that either - Other ports will be FDX and the switch will buffer accordingly so the HDX port won't receive(from the switch) whilst that HDX port sends outside the switch. OR - any port communicating with a HDX port will act HDX - a form of auto-negotiation will take place, though that seems like it might be inefficient ).

Reply to
q_q_anonymous

q_q snipped-for-privacy@yahoo.co.uk wrote in part:

Yes. However, mixing FDX and HDX is high probability scenario that would get full design attention.

Well, even the stupidest, cheapest hubs still have a collision light, so I think the signal _is_ special, and I cannot imagine why a switch would want to propagate it.

Quite so. Also the 5-4-1 rule could produce some large diameter collision domains before switches became inexpensive and replaced hubs.

Yes, but that's all that's available. How is it "inefficient" when it fully ustilises capabilities?

Reply to
Robert Redelmeier

As q_q_anonymous was talking about switch buffering being the alternative, my understanding was that q_q_anonymous was suggesting that -either- buffering had to be taking place -or else- every time a FDX port wanted to send a packet to a HDX port, that the FDX port would negotiate down to HDX for the duration of the transmission, going back to FDX when it was sending packets to ports that were FDX.

The answer, of course, is that switches *do* buffer packets and that each port is negotiated independantly, with the operating state of the port not depending on the state of the destination port.

If negotiating per packet did happen to be the mechanism, then Yes, that would be rather inefficient.... but the efficiency of that scheme is moot because it isn't how things are done anyhow.

Your response, Robert, that "Yes, but that's all that's available" could give the impression that you were indicating that per-packet negotiation was all that was available, which I don't think is what you had intended.

Reply to
Walter Roberson

Walter Roberson wrote in part:

Exactly. The HDX ports are actually accessed through an internal bridge in the switch or even 10/100 hub.

Sorry for the potential confusion. I meant "that's all that's available _on that link_". A switch treats each link from it individually.

-- Robert

Reply to
Robert Redelmeier

(snip)

Since the collision signal for UTP ethernet is signal on the receive lines during transmit it will look exactly the same as received data on a full duplex link. The only possible difference is the length of the signal, but that isn't a reliable detection method.

-- glen

Reply to
glen herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.