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

Groups > alt.comp.microsoft.windows > #2718

Re: Crimping tool, odd review

Cross-posted to 3 groups.

Show all headers | View raw

On 2025-05-30, Paul wrote:
> 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.

Note that MDI-X is more of a (fast-)ethernet thing, and not really used
by gbit-ethernet. This is because, whereas (fast-)ethernet specifies
pins 1,2 as TX, and 3,6 as RX, gbit-ethernet utilizes all four pairs
bidirectionally.

Least in 25 years, I've never seen a link come up at gbit with a
crossover-cable.  There *might* be something about this in the gbit
specs, but I don't have them to hand anymore :( .

>
> 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.

If the cable is sufficiently damaged, it might fail down to 10 before
dropping link.

>
> 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.

If by "rolled", you mean swapping pin1 for pin8 (and likewise all the
rest), you are correct in that no NIC can figure that mess out.  

If you mean swapping between 568-A/B on the same cable (pairs 2 and 3 -
white-green/green and white-orange/orange -- i.e. "creating a crossover
cable"), gbit NICs will likely downgrade to fast ethernet due to the
garbled bi-directional pairs.

In order to not accidentally creating crossover cables, regardless of
whether both ends are 8p8c connectors, or if only one end is -- pick
568-A or -B and stick with it everywhere (I learned it as 568-B first,
so that's my go-to).  When you do the 8p8c, the clip needs to be DOWN
(so you're looking at the bottom, with the gold contacts). Being
Right-Handed, I hold the 8p8c connector in the right hand and the cable
in my left.  This ends up setting the orientation as "farthest pin from
me" is pin 1. 

This means that when I untwist the conductors and orient them for
insertion into the 8p8c, their orientation will be: 

  (farthest) white-orange
  orange
  white-green
  blue
  white-blue
  green
  white-brown
  (closest) brown

If you're left-handed, everything just gets inverted (that is, the
farthest pin from you is pin 8).

  (farthest) brown
  white-brown
  green
  white-blue
  blue
  white-green
  orange
  (closest) white-orange

Then it's just a matter of trimming the conductors to the appropriate
length, getting everything into the appropriate pin slots, and the
outer sheathing to where that little strain-relief bit is (the
triangular / rectangular bit that deforms when you crimp down on the
8p8c).  This is sometimes far more difficult than it sounds :)

In the event of cat6 (indoor or outdoor cable), when you're cutting out
that stupid spacer on the inside, give it a decent yank so it stretches
out a little bit (about 1/8" or 3mm is enough), then cut it off. When
you cut it off, it'll retract back to its original length (or
thereabouts), and give you a little bit of an easier time of getting the
outer sheathing into the 8p8c connector.

HTH :)

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

Back to alt.comp.microsoft.windows | 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 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