Jeff Liebermann wrote:
> On Sat, 06 Dec 2014 14:59:23 -0600, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> Jeff Liebermann wrote:
>>> On Thu, 04 Dec 2014 13:51:56 -0600, Joe Chisolm
>>> <jchisolm6@earthlink.net> 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.
Sure.
> 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:
> <http://www.patton.com/ethernet-extender/>
> The company experts declared this gross violation of industry
> standards to be a capital crime,
LOLz!
> 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.
>
Yep.
>> 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:
> <http://802.11junk.com/jeffl/pics/drivel/fiber_01.jpg>
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