Re: RJ45/8P8C alternatives

Started by Les Cargill December 9, 2014
  To: Jeff Liebermann
Jeff Liebermann wrote:
> On Sat, 06 Dec 2014 14:59:23 -0600, Les Cargill > <> wrote: > >> Jeff Liebermann wrote: >>> On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm >>> <> wrote: >>> >>>> Try it. Take a patch cable, whack it in half and solder a DB9M and F in >>>> line. Run several GB of TCP traffic through it and watch the error >>>> counts. If you have access to the FW you could pull out more detail on >>>> what lower level errors you are seeing. >>> >>> The easy way to test that is to find a 10/100baseT *MANAGED* ethernet >>> switch, and use an SNMP MIB browser to look at the errors at the MAC >>> (Data Link) layer. There are plenty of SNMP tools available to do >>> this. Details, if anyone wants me to scribble something on the topic. > >> You should be able to use any old Ethernet MAC that supports >> publishing those counters. The managed switch just provides more likely >> instrumentation. > > True. However, the advantage of using a managed switch is that I can > carry it around with me, "tap" into any ethernet cable, and produce > immediate results without needing to install SNMP services on a target > machine. Using a managed switch also allows me some control over NWAY > (Auto-Negotiation) negotiation and allows fixing the interface rate > and protocol. >
I have yet to run into much that does not allow intervening in auto negotiation, managed or not.
>> That is fine for testing, but at least where I am, nobody wants a >> managed switch for deployed systems unless you have a solution to >> guarantee the switch configuration pretty much without human >> intervention. > > A "managed" solution seems to imply that there's someone around to do > the managing. That usually means me. However, you do have a point. > Most of my customers fail to appreciate receiving error logs via > email, and wouldn't know what to do with them anyway. However, long > term monitoring is not my purpose here (although I do graphs with MRTG > and RRDTool, which my customers can easily understand). Inserting a > managed switch, and using SNMP to collect numbers is for testing if a > creative cabling and connector scheme is likely to be usable. Think > of it as a piece of test equipment, which is normally not left in the > circuit. >
Sounds about right. Once you have the SNMP toolset, it's not hard to establish your configuration. But these things confuse people.
>> This might seem an odd post, but these days, the line between testing >> and deployment is pretty fine. > > Customer tested products? Yeah, I know the feeling. When firmware > updates start to look like recall notices, I start to worry. > >> A respectable BER fighure for Ethernet is 10^-10. Almost everything is >> even better than that. > > Well, let's see. BER = 10^-10 at 100 Mbit/sec is about 1 error every: > 100*10^6 / 1*10^-10 = 1*10^4 = 10,000 seconds = 7 hrs > at the MAC layer. For an office environment, I usually see about 1 > error per day.
> For a noisy industrial environment, maybe 10 errors > per day. Yeah, that's in the ballpark. Since the observed errors are > usually externally induced (i.e. power glitches), the error frequency > for 1000baseT is the same as 100baseT, resulting in a BER = 1*10^-11. >
Thereabouts. IMO, the Ethernet interface is no longer the source of most errors these days.
>> I know this is just a test methodology,. but I'd avoid 1000 feet of >> copper for deployment unless you have a cable management system capable >> of keeping *everything* off those cables. > > I didn't have much choice. The run was through 3/4" PVC conduit, > across an open field, and through a plumbers nightmare at each end. > For various reasons, RF was unacceptable. The conduit was crammed > full of cables and no more could be added. However, there was one > existing CAT5e cable that was being used for a single POTS phone line. > I proposed to use the existing pairs for ethernet, without expensive > ethernet extenders: > <> > The company experts declared this gross violation of industry > standards to be a capital crime,
> so I offered to demonstrate that it > would work using a new 1000 ft roll of CAT5e cable. No problems at > all at 10baseT HDX (half-duplex) or FDX (full-duplex) . 100baseT was > iffy in FDX due to NEXT (near end crosstalk), but worked just fine > using HDX. I vaguely recall posting a rant on the topic in > comp.dcom.wiring, and being accused of heresy or something. > > I will admit that I had problems with duplex mismatch at one end of > the link, but that was solved by replacing an old 10/100baseT switch > with a newer one that correctly implemented auto-negotiation. >
>> We do use 200 foot cables as a backup for 802.11 but they're purely >> a security blanket at this point. > > I have a spare pair of Ubiquity M5-HP bullet radios, panels, PoE, etc > for such occasions. I also have at least 500ft of CAT5e handy for > wi-fi backup. I use it sometimes for keeping a link up and running, > while I'm juggling radios, updating firmware, or trying to find > sources of interference. However, mostly it's used for deploying an > added WAP (ireless access point) to extend coverage, while get someone > to do the CAT5e backhaul wiring. > >> Optical is coming farther and farther downmarket. Run 4:1 media >> redundancy and hope for the best :) > > Yep. I've done some fiber. The problem with a high fiber diet is > that it's still rather expensive and I have problems selling fiber to > my cheap customers. Certainly not for residential work: > <>
Probably not in residential.
> We do have some fiber running around the neighborhood as part of a > previous internet and CATV sharing system. The fiber parts have > survived quite nicely. However, fiber is no guarantee against assault > by mice, squirrels, back hoes, the water district, or falling trees. > >> I'd really just bypass the managed switch and go for the Fluke >> certifier. They're excellent. I have not measured *how* excellent, but I >> have no failures due to cables since we invested in one. > > I would love to own a Fluke certifier. I can't justify the expense > and borrow one when the customer insists on testing. Meanwhile, I use > a DC continuity tester to deal with my wiring errors, and a home made > TDR for finding cable defects and split pairs. (The fun really began > when I wired one end of the cables for EIA-568B, while my accomplice > wired the other ends for EIA-568A). >
A TDR is just fine so long as you know what to look for and it supports the right cable profiles. I think the certifier we have is like $1K. Might be less - there are a lot of them. Not having one probably cost us at least an order of magnitude more.
>> And again; we run M12 in very rugged environments ( outside, mobile >> equipment, industrial environment, filthy-dirty ) and they work great. >> >> The Fluke certifier loves 'em. > > That's probably the right way to do it, but I find exploring the > creative and non-standard alternatives more interesting. >
These days, I just want the phone not to ring :) -- Les Cargill --- SoupGate-Win32 v1.05 * Origin: <SpaceSST.BBS.Fidonet<>> (1:249/999) --- Synchronet 3.15b-Win32 NewsLink 1.92 SpaceSST BBS Usenet <> Fidonet Gateway