ECN Forum Forums General Topics of the Trade Voice - Data - Video Discussion How far on a CAT5 Ethernet?

I know the rule but what is the longest CAT 5 run you have seen working? I once strung together over 1000' of IBM token ring wire, daisy chaining building runs together, and it worked. I was showing the guys how TDR worked and I was trying to get a lot of length, wire types, baluns and connections on the line.

Sounds like you need a fiber backbone there. Cat5 will work for a good distance but the performance will degrade as you go farther and farther. You will have to go pretty far to have it just flat out not work. I made a 1000' patch cord out of a box of cable and just for an experiment used it from my PC to the wall jack and it worked. This is 1000' and approximately 190' of additional horizontal cable to the hub in the closet, it was pretty slow but it did work. Sounds like you need a fiber backbone there.

Actually "there" no longer exists. I strung together a bunch of lateral runs from the distribution panel to get that ~1000'length (out one, daisy chain to another one, back to the panel and out on another one). I was playing with TDR so I wanted lots of ugly stuff, switching from STP to UTP with baluns and such. I even had some damaged cable in there.
I couldn't resist hooking it up to a file server and moving big files around. It still worked.

I have only seen a 5000' reel once of cat5, in the early days of it. (Cheap import knock off stuff) And never more than a 1000 of 5E.

What TDR do you have? I think these are that coolest thing out there. I have a Psyber (m.s.) (Numeric), and the shop has a Megger (Graphic). Both are really usefull for troubleshooting all kinds of stuff. Especially if you sample VoP's of larger wire, like 14 - 2 in conduit or cable. Use it to find screws in cable, and on occasion hidden j-boxes, and splices with the graphic.

Longest CAT5 4 pair 24 AWG UTP run that I saw in use on a 100baseT Ethernet LAN - and had no packet errors, etc. (at least for the time period I was there), was around 2,400 Ft. from Switch / MDF, to the Station.

Saw an even longer one on a LON (Local Operational Network - as in Building Automation Control Systems), which was used for Programming the MBC from a "More Convenient Location".
This was a good 3,000 Ft. - or more!

Here's a point to ponder:

Ever seen a CAT5 or CAT5e cable spliced - using normal Wirenuts (little Blues or Little Grays), and there is no data loss situation?

Seen it at 3 different locations.

Who'da thunk it?!

Scott35

We were doing TDR on a Tektronix 475 scope.
That was why I wanted a lot of wire out there (5ns/cm). We could walk down the trace with the "display after time delay" knob and fairly well determine which segment of wire we were looking at. I know these days TDR has become a magic box that gets you within inches of the failure. This was the pioneer days. It was a kerosene powered scope ;-)

When my last electrician got back from learning to install Cat 5 cable and the requirements on bending radius, he told me how he had tied some cable in knots and then proceeded to hammer the lie (meant to type life, but lie looked good here) out of the cable until the insulation was breaking up. He then placed this on a tester which found the cable at a 100 percent pass rate. I am unsure of the length.

Shane

We had a guy run AS/400 data down a barbed wire fence once to prove the twinax rules were silly but I have seen minor bruises on a cable grind the system to a halt.
As in most things like this YMMV

The spec on a 10/100-base-t run is ni more than 100 meters, 320' or so. If I remember correctly that is part of EIA/TIA 568A. Does that mean it won't work at longer runs? Of course not, but how many times have you seen an appliance powered from 16awg zip cord, it works but that does not make it right.

Actually, it comes from the design of the CSMA/CD protocol used by Ethernet. That stands for "Carrier-Sense Multiple Access with Collision Detect." If you visualize the original Ethernet which had transcievers tapped off of a coax backbone cable, it works like this: When a controller has a packet to transmit, it listens for a carrier on the coax. If there is no carrier, it transmits immediately. Otherwise, it waits for the other transmission to complete, waits the specified inter-packet time, and begins transmitting. While transmitting, it listens for others attempting to transmit at the same time. If it detects this condition, it continues to transmit for the specified minimum packet length, and then terminates the packet.

At that point, it begins to execute the Truncated Binary Exponential Backoff algorithm. Which basically means it waits a random amount of time before attempting to retransmit the packet.

The issue with distance is the collision detection scheme. At the bit rates Ethernet operates at, you've transmitted a lot of bits before the first bit you transmitted reaches the other end of the cable. If you were to transmit a rather short packet, you might complete transmitting the packet before the first bit you transmitted reaches the other end of the Ethernet. Someone at the other end could then, seeing a clear ether, begin transmitting. He would collide with your packet, destroying it. But, since you already finished transmitting it before he stepped on it, you won't realize that your packet wasn't delivered. Your packet is therefore lost.

Lost packets are a really bad thing. Higher-level protocols, like TCP, are designed to be able to recover from lost packets, but a large amount of bandwidth is lost in the process.

So, Ethernet was designed to prevent undetectable collisions. It does this by defining a "slot time", which is essentially the round-trip delay through a maximum-length Ethernet LAN. The spec then defines a minimum packet size that is longer than a slot time. This guarantees that a controller on one end of a network will see a collision caused by a controller at the far end of the network, thus allowing it to enter the backoff algorithm, and assure that the packet is eventually successfully transmitted.

By exceeding the maximum cable length, you may create a situation where collisions result in lost packets, resulting in a substantial loss in network performance.

But wait, the situation is even more complicated than that...

A hub essentially emulates the old Ethernet coax, so my foregoing description applies to anything connected to a hub.

A switch, on the other hand, operates on completely different principles. The connection to a switch is an unshared, point-to-point connection between the switch and the device at the other end. Most switches use a full-duplex version of Ethernet that doesn't involve collision detection. So what I wrote doesn't apply.

Unless... the device connected to the switch is a hub. In which case it does apply.




[This message has been edited by SolarPowered (edited 04-22-2005).]