[TJ9]

On a network when two computers transmit at the same time a collison occurs. The first computer to detect a collision sends a jam signal to tell the other computer to back off and not transmit for a random amount of time. Now, how does the jam signal get to the other computers? Wouldn't it get caugth in the collision or create a collision with one of the other two transmissions?

[su root]

The Jam signal is just an electrical signal that can be read dispite the collision.

The collision will propogate down the wire in all directions, garbled. The first computer that sees the collision jams the line.

The jam signal will still run at the same speed as the collision, so all machines will see the collision first, then the jam signal. (?)

I have a few questions of my own:
1. Why bother jamming if everyone is gonna see the collision anyway? (is it just to stop the sender from continuing?)

2. What is the jam signal exactly?

[engjohn]

The way I understood it was that there is no jam signal, just when a system detects a collision it waits a random amount of time before retransmitting. That way there would be less traffic on the wire, causing less collisions...

[su root]

the stuff I've read (a la cisco) tells me that there is a Jam signal sent out by the first machine that senses the collision. It would only make sense, as hubs and repeaters have no way of cleaning up a collision, they wouldn't know what to do with the garbage, so a universal jam signal that the hubs/repeaters understand and would know how to repeat would be called for.

[engjohn]

Hmm, now you have me thinking, must go do research...

[su root]

I caught these pieces from other boards, it was quoted, but only the latter one has a source:

A second element to the Ethernet access protocol is used to detect when a collision occurs. Each transmitting node monitors its own transmission, and if it observes a collision (i.e. excess current above what it is generating, i.e. > 24 mA) it stops transmission immediately and instead transmits a 32-bit jam sequence. The purpose of this sequence is to ensure that any other node which may currently be receiving this frame will receive the jam signal in place of the correct 32-bit MAC CRC, this causes the other receivers to discard the frame due to a CRC error

and:

>Jamming doesn't have any frame structure, it is merely a 32-bit random sequence.
>
> Jamming seq. length must equal at least slot time. Usually exceed by a
> 'suitable' margin.
>
> Therefore it's length in bits depends upon network speed and maximum
> end-to-end propagation delay experienced. For instance, >100BaseT is 5 x 100m
> segments, and 1 bit equals 0.01us. You can do the sums from there.

>Collisions can still be detected in the normal way, even while sending
> jamming signals, except the card would unlikely be arranged to monitor for
> collisions while sending a jamming signal, as there wouldn't normally be
any
> need.

p281 HALSALL, F, 'Data Communications, Computer Networks & Open Systems'
> 4th
> > Edn., Addison Wesley, 1995. ISBN 0-201-42293-X
> > states 'a random bit pattern'.

So I read that as "the people who are talking also listen, and if they hear anything else, they both discard what they were going to say, and instead transmit garbage" (presumably 1 frame long)

[TC]

The jam signal is transmitted in order to allow the line to clear up before transmitting again. It has no affect on hubs or repeaters because neither type of device looks at the packet structure or mac address - they simply forward everything they receive. It's up to the nodes to find the error and ask for retransmission.

[su root]

but the hubs/repeaters do look at the electrical signals, and when something collides, it is really hard for the hubs or repeaters to clean up the signal when the voltage is double what it's supposed to be, which is not a recognizable 1 or 0.

[TC]

Traditionally hubs didn't do anything to the transmission. If the voltage is too high it may clip it - I'm not really certain about that. Otherwise hubs have no intelligence whatsoever. They quite literally just provide an electrical path from port to port. There are different kinds of repeaters now days. Some simply amplify the signal and spit it out the other end. Some can do some signal cleaning. It might be that some newer repeaters could adjust the line level appropriately, but the bits that collided will not be intelligible to any receiving device. I believe the original intent of the jam signal was to let every device in the collision domain know that a problem had occured. The offending nics then wait a random period, listen for a carrier, and if all is clear they get back to work. I'll ask a colleague about what a hub might do with a collision. It probably just drops the garbled bits.

[su root]

the hubs and repeaters should "read" one bit from one port, then clean it up and repeat it on another port, as a strong, clear signal. (atleast from my understanding of hubs and repeaters).

Otherwise a signal that attenuates won't last long after being repeated, because just amping it won't resolve the clarity problem.

An exception is made for inactive hubs.

[TC]

In the "old" days hubs were considered inactive passive devices because all they did was provide a physical connection between ports. Repeaters typically fall within two categories - analog and digital. Analog repeaters generally can only amplify the signal. Digital repeaters are usually capable of cleaning up noise and returning the signal to near perfect quality before sending it down the wire. It was because of the limitations with passive hubs and repeaters that the 5-4-3 rule was implemented. This helped prevent any problems with attenuation and also to ensure that the time limitations are adhered to. If too much latency is introduced from end to end it will result in packets being sent multiple times. The 5-4-3 rule has somewhat been dropped with the adoption of switches.

[su root]

Originally posted by TC
If too much latency is introduced from end to end it will result in packets being sent multiple times.

Actually, if there's too much latency, it's not so much a problem of multiple packet sends, but late collisions (collisions past 64 bytes).

I didn't know the 5-4-3 rule was based on passive devices. (knowledge=knowledge+1)

With the invention of switches, the 5-4-3 rule really doesn't apply anymore, because in an all-switch environment, the switch acts as a node when it recieves the packet, and resends it, as opposed to hubs that are pretty much just physical connections

[TC]

Yep the late collisions would be a problem, particularly if you're using a switch in fragment free mode or cut through somewhere on the lan. I remember seeing some odd issues when partially upgrading older networks.

[su root]

I talked to my Cisco teacher and everything makes more sense now:

A Jam signal is a special message on a special frequency sent out by the first person who sees the collision.

The person closest to the collision will have a high-quality collision to look at, so they discover very quickly that it is collision and send a Jam signal on the line. The Jam signal is a very powerful signal (as opposed to the normal traffic), so it doesn't get garbled by the collision. When the sending computers see the Jam (actually, the collision followed by the Jam), they stop transmitting. A normal workstation on the line would start to see the collision, but since they aren't the closest person, the collided signal would have attenuated more, and thus it would take them more time to figure out it's a collision, by that time they would observe the Jam on the line & ignore everything & jump into random-timeout mode.

In the perfect scenario that the two sending computers see the collision first (as it would collide between them), then they would both observe it, analyze it, and Jam at the same time. However, all is still good, as a client on one side of them would see the collision, try to examine it, then see the Jam by SenderA, and stop listening (but if were listening, would here the Jams collide). On the other side, they would hear collision, then Jam from computer B, then stop listening.