drq, Russian
@drq@mastodon.ml avatar

Ethernet connector wiring is so infuriatingly unnecessarily frustrating. It's fiddly, it requires too much micromotorics, it's error-prone, and if you're colorblind or work in dark spaces, you're fucked.

I wonder, why do we even HAVE to bother with wiring order at this point? Shouldn't we really have some kind of smart wire order autonegotiation algorithm by now? Like, whatever, use any color order you like, including flat wires, it really shouldn't matter which order your connector is wired in, as long as all conductors are set, it shall work.

vovanium,
@vovanium@quietplace.xyz avatar

@drq
Good luck with detecting which to which wire is twisted together in the cable.

drq,
@drq@mastodon.ml avatar

@vovanium
You don't have to. They're all twisted the same from the factory, and as long as you transmit corresponding signal through corresponding wire, it uses the same twisted pairs.

vovanium,
@vovanium@quietplace.xyz avatar

@drq Signal is transmitted through a pair, not a single wire. If you transmit, say +1.5V signal through wire 1, you have to transmit -1.5V to a wire it twisted with. If you assemble the cable randomly, you have to detect every pair.

drq,
@drq@mastodon.ml avatar

@vovanium
If you can detect individual wires, understanding which pair each one comes from is trivial.

vovanium,
@vovanium@quietplace.xyz avatar

@drq Try to figure out the circuit and algorithm.
First, what your device will measure and how?

drq,
@drq@mastodon.ml avatar

@vovanium
I described the handshake process here

https://mastodon.ml/@drq/110898501111218611

GalacticJew,

@drq

gg wp but

not only proper pin-to-pin connection is important for ethernet :-) proper physical wire too, because electrical interference between wires can disrupt signals on high speed/long distance. so you need also an reflectometer or something like that per ethernet port :-)

drq,
@drq@mastodon.ml avatar

@GalacticJew
Nah. Wires are the same, it's just ordering switcheroo.

GalacticJew,

@drq they are twisted and twisted certain way and certain pair must be connected to the certain jack pin. if you connect pairs to a jack random way, it will work occasionally. np, just let’s call it “casual ethernet” it will be funny.

GalacticJew,

@drq I once saw a bank lan 10basetx, built using untwisted flat cable. it worked. with crc errors, packet loses etc, but worked against all odds. why not :-)

drq,
@drq@mastodon.ml avatar

@GalacticJew
Why "untwisted"? I don't suggest replacing the cable.

By 'flat' I meant colors.

GalacticJew,

@drq the result will be the same or worse :-)

shake,
@shake@zhub.link avatar

@drq ethernet - это гениальный интерфейс, я удивляюсь, зачем нужен USB, когда есть ethernet!
4 провода, скорость 10 или 100 Мбит + питание до 100 Вт, аж на 100 метров. + ещё 4 провода и экранирование, и доступны стандарты 1 и 10 Гбит. Коннектор не удобный (толстый), можно другой придумать(. При обжиме можно перепутать провода в паре или пары между собой, и оно продолжит работать (главное между парами провода не менять и не включать в такой кабель PoE). И куча уже готовых протоколов для всего разного, зачем нам USB?

drq,
@drq@mastodon.ml avatar

@shake Современный USB4 дает от 20 до 40 гигабит. Вторая его редакция может держать до 80.

shake,
@shake@zhub.link avatar

@drq А зачем столько, это единичные задачи. Стандарт 40 Гбит по витой паре тоже, когда-то разрабатывали, но почему-то свернули

drq,
@drq@mastodon.ml avatar

@shake Картинку сырую с видюхи гонять, например? (да, usb-видюхи сущестуют, как и USB-мониторы) Параллельно со всеми остальными данными.

dside,
@dside@mastodon.ml avatar

@drq we are so not going to like how costly and unreliable that'll make a lot of the networking hardware. So many additional moving parts and failure states, most of them utterly unfixable in the field. And considering PoE exists, every single one of those smart conductors will have to be quite beefy too.

But we could at least color the wires in a way that's easy to piece together intuitively and without relying on color hues. Green lightness gradient? High-contrast dash pattern of varying lengths?

mo,
@mo@mastodon.ml avatar

@drq so you need to software decode every bit...? :blobcatgooglyholdingitsheadinitshands:

drq,
@drq@mastodon.ml avatar

@mo
Uh... No? Just pulse-test wire order upon connection, and memorize it until connection is lost.

mo,
@mo@mastodon.ml avatar

@drq memorise and then? Like, imagine there is signal at physical wire №2. But because order is random, wire №2 may correspond to... any «logical» wire. So you have to go where you memorised wire order, and see, that №2 is actually №8. Repeat on every signal.

drq,
@drq@mastodon.ml avatar

@mo and then transmit the data according to the order you've negotiated, until the plug is pulled and connection is lost. You don't have to repeat that on "every" signal. The order doesn't change randomly as long as the wire is connected.
I mean, hell, we already do negotiate between A and B wiring standards where four wires are switched. It's not much different.

mo,
@mo@mastodon.ml avatar

@drq you still have to fix wire order at software level.

drq,
@drq@mastodon.ml avatar

@mo we're already doing this.

mo,
@mo@mastodon.ml avatar

@drq not like this, because wires couldn't be in any order.

mumzik,

@mo @drq But order really could be determined in parallel. I guess it could be done even on hardware level. Like we define distinct signal forms for each input. Upon connection the device assumes "classical" scheme and awaits input. If no valid input, the negotiation cycle starts. Our device reads all inputs for incoming "signature" signal. If received, inputs are mapped internally and the existing Ethernet protocol module is connected to the wires. If still no input, our device at random interval broadcast signatures(assuming classical pins wiring)/listens to the answer until valid Ethernet packet arrives (that means our schema was accepted) or signature arrives (then we accept schema and send back Ethernet packet)

drq,
@drq@mastodon.ml avatar

@mumzik I can do you one simpler. Make no assumptions on wiring order in the first place. Upon connection, burst a rainbow of frequencies on the conductors 1 through 8. There you go, what comes out the other side, is your conductor order for the day. Write that down to network device's RAM (the same RAM you save ARP tables to). You will roughly need 1 byte for that (8 wires make 256 combinations). Send "ready" signal back, repeat that on the other side, and you're golden.

@mo

vovanium,
@vovanium@quietplace.xyz avatar

@drq @mumzik @mo Here's rough simulation of your detector https://tinyurl.com/24chm5cz Can you guess which oscilloscope connected to each wire?

drq,
@drq@mastodon.ml avatar

@vovanium What you're showing me looks like "data transmission" step, not "handshake" step.

At the point of data transmission we already know what conductor belongs to what pair and have already adjusted for it, we don't have interference.

@mo @mumzik

mumzik,

@vovanium @drq @mo

Maybe I'm missing something, but what are you showing? That there could be noise that will complicate detection?

vovanium,
@vovanium@quietplace.xyz avatar

@mumzik @drq @mo I'm showing that dealing with high speed transmission lines is not that easy as you might expect.
The model shows only two aspects of this: crosstalk and lack of common grounding.
There are also other issues you must deal with.

  • DC decoupling. Normally ethernet ports are decoupled by transformers, ignoring this you'll have to deal with high DC voltage offsets (tens or even hundreds of volts) and high common mode noise.
  • Proper waveguide parameters of the board traces. Normally each twisted pair continue on a PCB as differential microstrip line matched in impedance. There's no way to match impedance of 8 wires in all possible pair combinations. Ignoring this will greatly reduce signal integrity making connection unreliable.
    The image (taken somewhere form the internets) shows proper (not perfect however) PCB trace design between a jack and a transformer. Traces are grouped by pairs corresponding to each twisted pair in a cable.
drq,
@drq@mastodon.ml avatar

@vovanium Okay, these look like valid reasons.

@mo @mumzik

mo,
@mo@mastodon.ml avatar

@drq 8 wires mapped to 8 wires in unpredictable order is 8⁸

@mumzik

mo,
@mo@mastodon.ml avatar

@drq wait no, it's not that bad, but still much more than 1 byte

@mumzik

drq,
@drq@mastodon.ml avatar

@mo apparently, we're both wrong.

https://en.m.wikipedia.org/wiki/Permutation

The number of permutations is a factorial of a number of items.

8! = 40320

That's 158 bytes. Still not really all that expensive.

@mumzik

iliazeus,
@iliazeus@lor.sh avatar

@drq you're still wrong :)

It can just be a byte for each of the wires, telling which one it corresponds to. So 8 bytes.

Or even 3 bits per wire, since there's only 8 possibilities. So 24 bits, or 3 bytes.

So yeah, storing it is not expensive at all.

@mo @mumzik

drq,
@drq@mastodon.ml avatar

@iliazeus Why do you need the whole byte for each of the wires?

@mo @mumzik

iliazeus,
@iliazeus@lor.sh avatar

@drq to make mapping as simple as possible, assuming RAM stores bytes. You just go wire_lookup_table[wire_index].

Or you can compress it even further, as I wrote below.

@mo @mumzik

drq,
@drq@mastodon.ml avatar

@iliazeus Wait, do you mean for each wire or each cable?

If cable, then yeah, you need to save wiring state for each cable, but then again, that's what, around 8 kilobytes total for a 52-port switch? Man, I've seen ARP tables much bigger than that.

@mo @mumzik

iliazeus,
@iliazeus@lor.sh avatar

@drq not arguing against you :) just correcting calculations

What I meant is:

  • the easiest solution is 1 byte per wire
  • it can be easily optimized to 3 bits per wire
  • the theoretical minimum is ≈15.3 bits per cable

And yes, I agree, it is not much. I'm on your side in this argument :)

@mo @mumzik

mumzik,

@drq @mo first "assumption" is the way to be backward compatible with the old devices

mo,
@mo@mastodon.ml avatar

@mumzik
> inputs are mapped

This requires firmware, didn't it? I have no idea how to map random 8 wires using analog schemas

@drq

drq,
@drq@mastodon.ml avatar

@mo all network hardware already has firmware.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq good luck with fixing wire order on the fly at 1Gbit/s

@mumzik

drq,
@drq@mastodon.ml avatar

@mo as I've told you: we're already doing it regarding a//b standards.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq I doubt that random pair of network adapters could work via randomly inserted A-B cable. Most of cables are A-A, some are B-B. If wire order is same, their colors don't matter

@mumzik

drq,
@drq@mastodon.ml avatar

@mo You're probably too young to remember network hubs and switches requiring cross cables to function.

Now they negotiate crossing all by themselves, if they need it.

So how is it in the slightest fucking way different?

@mumzik

mumzik,

@drq @mo Hey hey, fellow old fart :ablobcatattentionreverse:

mo,
@mo@mastodon.ml avatar

@drq again, 2 combinations is not 8! combinations, and I can imagine analog scheme for doing it. Set state once, and work forewer
...but this is not easily scalable to 8! possible combinations

@mumzik

drq,
@drq@mastodon.ml avatar

@mo AutoMDI-X algorithm was introduced in 1998.

We've come a long way since then, we can easily scale that crap to 8! combinations.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq also we can easily transform bread into a trolley
With modern technologies, it even could be used in trolley problem!

@mumzik

drq,
@drq@mastodon.ml avatar

@mo Nothing more to say, huh.

Go fucking wire 115 patch cords for a new server rack, and then double that for client PCs.

We'll see who gets the last laugh :)

@mumzik

mo,
@mo@mastodon.ml avatar

@drq go fucking replace all network adapters/routers/motherboards, but before that, try to convince business it requires to buy new adapters/routers/motherboards which are 10% more expensive than normal

@mumzik

drq,
@drq@mastodon.ml avatar

@mo We already did that with AutoMDI-X. We can do it again.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq btw, it will be cheaper and easier to buy cables with connectors already

@mumzik

drq,
@drq@mastodon.ml avatar

@mo Easier - yes. Cheaper - no :)

@mumzik

drq,
@drq@mastodon.ml avatar

@mo Also, not the case if you need to wire rooms. You have to crimp then.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq cheaper than replacing all network hardware

@mumzik

drq,
@drq@mastodon.ml avatar

@mo The hardware will be replaced eventually. This is not an excuse for the new feature (any new feature) not to exist.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq btw, auto wire sorter using color sensors/Computer Vision looks more realistic than replacing all network infrastructure

@mumzik

drq,
@drq@mastodon.ml avatar

@mo sounds expensive AF, but I woldn't turn one down if one existed.

@mumzik

mo,
@mo@mastodon.ml avatar

@drq
> Sounds expensive as fuck
> Suggest replacing all hardware just to not sort wires

@mumzik

drq,
@drq@mastodon.ml avatar

@mo hardware gets replaced, like, all the time, gal. Just naturally. And also, new houses and workplaces need wiring as well, and the easier and quicker it is, the cheaper it will be. Human time is way more expensive than machine time. Your argument sounds like "screw your automatic transmission, we don't want to replace our manual gearboxes". And this argument was made, multiple times.

But look around, automatic transmission is everywhere at this point. So manual cars did get replaced by a more convenient alternative eventually. Same with AutoMDI-X. That's why you don't see cross-wire cables anymore, because it was stupid.

So, your argument is kinda non-argument, sorry

@mumzik

mumzik,

@mo @drq But I still fail to get, why on the fly and why transmission speed matters? What we are talking about is just one time procedure upon physical layer connection.

drq,
@drq@mastodon.ml avatar

@mumzik Yes, which also basically already happens. Just not all the way.

@mo

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • kavyap
  • thenastyranch
  • ethstaker
  • DreamBathrooms
  • osvaldo12
  • magazineikmin
  • tacticalgear
  • Youngstown
  • everett
  • mdbf
  • slotface
  • ngwrru68w68
  • rosin
  • Durango
  • JUstTest
  • InstantRegret
  • GTA5RPClips
  • tester
  • cubers
  • cisconetworking
  • normalnudes
  • khanakhh
  • modclub
  • anitta
  • Leos
  • megavids
  • provamag3
  • lostlight
  • All magazines