Question re: collisions & half-dup

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

I want to know the answer to several questions regarding half-duplex and
collisions.

1) If you have a workstation talking half-duplex on a UTP cable to a switch
(not a hub), does the workstation use a separate conductor for transmitting
and receiving while in half duplex? If so, is it ever possible to have
collisions while running in such a way (from what I've read it seems that
under half-dup on UTP to a switch you use a separate xmit and rcv but can
still have collisions).

2) If you hook half-dup from the workstation up to full-dup on the switch,
then do you get discarded packets on the workstation-end, resulting in an
unreliable connection? I've read that this is so.

Finally, if anyone can answer these questions can you also send me reputable
articles (if possible) that back up your conclusion?

Thanks in advance,

Tom

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Tom Edelbrok wrote:

> I want to know the answer to several questions regarding half-duplex and
> collisions.
>
> 1) If you have a workstation talking half-duplex on a UTP cable to a
> switch (not a hub), does the workstation use a separate conductor for
> transmitting
> and receiving while in half duplex?

Depends on the specific implementation. For the more common varieties that
are likely to be used in half-duplex mode separate pairs are used for
transmit and receive. Regardless, this is not a function of duplex--half-
or full- duplex the same pairs are used, what changes is the signals.
10baseT and 100baseTX for example always use separate pairs for transmit
and receive, while 1000baseT uses all four pairs bidirectionally.

> If so, is it ever possible to have
> collisions while running in such a way (from what I've read it seems that
> under half-dup on UTP to a switch you use a separate xmit and rcv but can
> still have collisions).

Yes, it is possible to have collisions any time you are running half-duplex.
There is little point to running half-duplex to a switch port but if you do
that then if the workstation and the switch port attempt to transmit at the
same time a collision will occur.

The manner in which collisions are detected and handles twisted pair is
somewhate different from the manner on coax, which might be what is
confusing you.

> 2) If you hook half-dup from the workstation up to full-dup on the switch,
> then do you get discarded packets on the workstation-end, resulting in an
> unreliable connection? I've read that this is so.

It is always possible, regardless of duplex, to have discarded packets.
Ethernet does not guarantee delivery. This does not mean that the
connection is unreliable, it means that guaranteeing of delivery has to be
handled at a higher level. If you need guaranteed delivery at layer 2 then
Ethernet is not the right protocol to be using.

> Finally, if anyone can answer these questions can you also send me
> reputable articles (if possible) that back up your conclusion?

As far as "reputable articles" go this is covered by the Ethernet
specification which can be downloaded from <http://www.ieee.org>. There is
a charge for any release less than 6 months old but the questions you raise
have been in the spec for a decade or more.

>
> Thanks in advance,
>
> Tom

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

 

[Michael]

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Tom Edelbrok" wrote...

> I want to know the answer to several questions regarding half-duplex and
> collisions.
>
> 1) If you have a workstation talking half-duplex on a UTP cable to a
switch
> (not a hub), does the workstation use a separate conductor for
transmitting
> and receiving while in half duplex?

Yes, there are different pairs for transmitting and receiving if you use
10BASE-T or 100BASE-TX.

> If so, is it ever possible to have
> collisions while running in such a way (from what I've read it seems that
> under half-dup on UTP to a switch you use a separate xmit and rcv but can
> still have collisions).

If both stations start transmitting a frame at the same time (or within a
very short time interval from each other), the stations will detect that
they're receiving something from an other station while they're
transmitting. In half duplex mode, such an event is called a collision,
regardless of the underlying physical medium.

> 2) If you hook half-dup from the workstation up to full-dup on the switch,
> then do you get discarded packets on the workstation-end, resulting in an
> unreliable connection? I've read that this is so.

If you bring the link up in that way, the workstation will declare
collisions every now and then, and the bridge will not react properly to
them.

> Finally, if anyone can answer these questions can you also send me
reputable
> articles (if possible) that back up your conclusion?

Go to http://standards.ieee.org/getieee802 and look for IEEE Std 802.3.

--
Michael
http://www.ethernetinthefirstmile.com

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,

Here is a model that has worked well for me for a
number of years. It allows predictions to be made
about the errors generated when duplex mis-matches occur.

I don't know exactly how accurate it is but I think that
is is pretty close.

The key thing is that in a HD transceiver (lets call it)
the TX and RX cables are *connected* inside the
transceiver. This means that for example when
the HD side is transmitting, if the FD side
transmits too the HD side detects a collision.
In this case the HD side might record a late
collision (it is not necessarily late)
and the FD side will record a FCS error, and/or align error.

FCS is computed by a method known as CRC
and the terms are often used interchangeably.

###########################################

The Tx cable and Rx 'cable' are each connected to a seperate
twisted pair outside the transciever.


The little boxes are intended to represent the
boundary between the external 'big bad world'
signalling methods 'e.g Manchester encoding'
and the reliable internal signalling 'e.g TTL logic'.

The collision detection comparator compares each
Tx and RX bit and signals a collision
if the they are different.

This is 10BaseT Ethernet, there will be small,
but at this level insignificant, differences
between 10 and 100 (and 1000). Co-ax cable
ethernets use a different collision detection
mechanism.

Connect XX to XX and YY to YY for FD-HD missmatch.


Half Duplex
--
Tx-->>--------------------| |-------------------------->XX
|| -- /\
|| ||
|| ||
|| ||
\/ ||Tx signal copied to Rx
Collision Collision ||Rx signal copied to Tx
Detected <------Detection || -this is a wire-
Signal Comparator ||
/\ ||
|| ||
|| ||
|| -- \/
Rx--<<--------------------| |---------------------------<YY
--



Full duplex
--
XX>-----------------------| |------------------------>>--Rx
--










--
YY<-----------------------| |-------------------------<<--Tx
--

I am sending this via google groups which seems to
use proportional fonts!!! Anyway the diagram should work OK
in a fixed pitch font.