Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #81600

Re: Crimping tool, odd review

From Paul <nospam@needed.invalid>
Newsgroups alt.os.linux, uk.comp.os.linux, alt.comp.microsoft.windows
Subject Re: Crimping tool, odd review
Date 2025-05-30 06:05 -0400
Organization A noiseless patient Spider
Message-ID <101bvsv$e55c$1@dont-email.me> (permalink)
References (2 earlier) <1019f0h$3r5ur$1@dont-email.me> <kKm*FmIdA@news.chiark.greenend.org.uk> <101a54q$3vmta$1@dont-email.me> <lKm*bSIdA@news.chiark.greenend.org.uk> <101ali7$322n$1@dont-email.me>

Cross-posted to 3 groups.

Show all headers | View raw

On Thu, 5/29/2025 6:02 PM, Java Jive wrote:
> On 2025-05-29 19:48, Theo wrote:
>>
>> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
>>>
>>> As I understand, the two halves of those testers slide apart and you can
>>> put one half at each end to perform the test.
>>
>> Do you need to see both ends to run the test, or is one sufficient?
>>
>> I saw a video showing that a green light on each part scans down the numbers
>> 1 to 8 then 'G'.  But I'm not sure if you are testing that the lights match
>> at both ends, or if a fault is only shown at the end that detects it.
>>
>> (eg if you had open circuit at one end and a short at the other, what would
>> it tell you?)
> 
> Well, I've not used one, so I'm guessing based solely on electronic logic.  Hopefully, if I'm wrong, someone will correct me.
> 
> 1)  If the cable was miswired by crossing two cables, then I'd expect the lights at one end, most probably the remote end, to light in the wrong order.
> 
> 2)  If you have a short at one end, I'd expect two lights to be on at the same time at least at that end, probably at both.
> 
> 3)  If you have an open circuit, I'd expect the corresponding light at one end or the other to fail to light.
> 
> But let's see if anyone can confirm what actually happens based on actual experience.
> 

A GbE chip, has MDI/MDIX and the two ends of the cable
automatically negotiate the highest rate they can manage.
I presume in this case, that starts with selecting
GbE full duplex 1gbit mode and trying to make that work.

If the four pairs do not operate, for whatever reason,
the negotiation will eventually drop to 100BT and the
two pairs on 1,2,3,6 . I don't think there is a reason
for the GbE end to move to 10BT 1,2,3,6, unless some kind
of response from the other end, indicates that is all the
hardware can manage.

A second kind of diagnostic, is a Marvell Ethernet Chip,
has a TDR (Time Domain Reflectometer), it shoots a pulse
down each pair. If the end is shorted or open, that causes
a reflection off the spot, and the Marvell
logic block measures the pulse polarity and arrival time
(possibly to the nearest 1 nanosecond). If your cable
was shorted in the middle and not at the crimp, the TDR
method tells you roughly where to look for crushing damage.

I'm not aware of any NIC PHY having the ability to work
at the "I've got eight wires level" and figure out
what is connected to what, as a means of vetting home made
cables with the wires shoved in the wrong holes (like
an attempt to make a "rolled" cable). For that matter,
the MDI/MDIX on the Gbe, is even capable of dealing
with "straight" wiring pattern or "rolled" wiring
pattern. Either cable works. Whereas with 100BT NICs
as endpoints, if you use the wrong cable, it fails
to function, you switch cable types (remove that yellow
cable from the broadband modem box), and the interface
starts to work.

The GbE NIC then, is the magical beast, up to the point of
the user has mis-wired and put the wires in the wrong holes,
and the wrong-ness happens to not be in the MDI/MDIX feature
set :-)

The PCI Express used on computer motherboards, is similarly
whizzy at this kind of stuff. If one of the wires on a
PCI Express interface isn't working, the interface
can restore enough functionality (reduced bandwidth)
for the equipment to carry on. PCI express can even handle
an endian problem, such that if the diff pairs are flipped
on bus order... it still works. I don't know what they
were smoking when they came up with all of this, but it must
drive the implementers nuts to support it all. You're running
at very high speed, and you have all these modes, and negotiations
to do. (The negotiation was even broken, in one generation, and
some video cards needed their VBIOS flashed up, to jam the bus
into the lower speed mode. The industry is better at checking
for compliance now.)

   Paul

Back to alt.os.linux | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-05-28 15:37 +0100
  Re: Crimping tool, odd review Poblano <8minutes@450F.com> - 2025-05-28 10:20 -0700
    Re: Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-05-29 11:49 +0100
  Re: Crimping tool, odd review Andy Burns <usenet@andyburns.uk> - 2025-05-28 19:20 +0100
    Re: Crimping tool, odd review Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 04:17 +0000
  Re: Crimping tool, odd review Chris Green <cl@isbd.net> - 2025-05-28 19:29 +0100
  Re: Crimping tool, odd review Theo <theom+news@chiark.greenend.org.uk> - 2025-05-29 09:33 +0100
    Re: Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-05-29 12:04 +0100
      Re: Crimping tool, odd review Theo <theom+news@chiark.greenend.org.uk> - 2025-05-29 17:34 +0100
        Re: Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-05-29 18:22 +0100
          Re: Crimping tool, odd review Theo <theom+news@chiark.greenend.org.uk> - 2025-05-29 19:48 +0100
            Re: Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-05-29 23:02 +0100
              Re: Crimping tool, odd review Paul <nospam@needed.invalid> - 2025-05-30 06:05 -0400
                Re: Crimping tool, odd review Dan Purgert <dan@djph.net> - 2025-05-30 14:10 +0000
              Re: Crimping tool, odd review Jasen Betts <usenet@revmaps.no-ip.org> - 2025-07-01 09:10 +0000
                Re: Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-07-01 18:46 +0100
                Re: Crimping tool, odd review "Carlos E.R." <robin_listas@es.invalid> - 2025-07-01 20:58 +0200
            Re: Crimping tool, odd review Dan Purgert <dan@djph.net> - 2025-05-29 22:55 +0000
              Re: Crimping tool, odd review Java Jive <java@evij.com.invalid> - 2025-05-30 11:56 +0100
            Re: Crimping tool, odd review "Carlos E. R." <robin_listas@es.invalid> - 2025-05-30 16:20 +0200
  Re: Crimping tool, odd review Dan Purgert <dan@djph.net> - 2025-05-29 11:21 +0000
    Re: Crimping tool, odd review Chris Green <cl@isbd.net> - 2025-05-29 12:38 +0100
    Re: Crimping tool, odd review "Carlos E. R." <robin_listas@es.invalid> - 2025-05-29 13:54 +0200

csiph-web