I've seen dedicated devices for measuring TDR and even layer 2&3 network switches with the TDR capability. My question is what would prevent a standard home router from being programmed to measure the same metrics? -Being on the 3rd OSI layer instead of layers 2&3 like the advanced switches? Or do the switches and other devices have a special piece of hardware installed that allows them to detect something that other devices can't? I've been searching all over Google and even pulled the IEEE ethernet standards to see if that would help me understand better (much of the 802.3 material went over my head).
\$\begingroup\$
\$\endgroup\$
7
-
\$\begingroup\$ The fact that it's almost never needed. \$\endgroup\$– Ignacio Vazquez-AbramsCommented Jun 27, 2016 at 22:59
-
\$\begingroup\$ Very true. However, my goal is to determine if it would be possible, not necessarily practical. I updated the title to reflect the distinction. \$\endgroup\$– Landon TholenCommented Jun 27, 2016 at 23:35
-
1\$\begingroup\$ If an oscilloscope isn't "specialized," you can do some approximations by driving the cable with a short-rise-time stimulus signal and then using a T connector to connect to the high-Z oscilloscope input to monitor for returns. \$\endgroup\$– user2943160Commented Jun 28, 2016 at 0:37
-
1\$\begingroup\$ @user2943160 In this case I would consider an oscilloscope a specialized piece of equipment. I'm looking to determine the feasibility of implementing a TDR utilizing existing network infrastructure. -Ideally by designing software to enhance the capabilities of basic routers (i.e. a home router) that follow the current IEEE standards. \$\endgroup\$– Landon TholenCommented Jun 28, 2016 at 1:26
-
1\$\begingroup\$ I think it is a special mode of operation in the phy. Probably most phy's don't support it. This is just a guess. \$\endgroup\$– user57037Commented Jun 28, 2016 at 3:21
|
Show 2 more comments
4 Answers
\$\begingroup\$
\$\endgroup\$
6
I'm looking to determine the feasibility of implementing a TDR utilizing existing network infrastructure.
The Ethernet cable's capacitance is directly proportional to its length. So a network analyzer could, I suppose, perform an out-of-band in-band cable length measurement by injecting a fast rise time u(t) pulse into one end of the cable, providing a resistance of known value at the other ("measurement ") end of the cable, and measuring the RC network's rise time to to determine the cable's length. This technique would allow for auto-ranging (selecting different resistance values under software control), and relatively low-cost hardware could perform this type of measurement (e.g., a sufficiently fast microcontroller with comparator inputs and counter-timer circuitry). This would not be a "true" TDR, but it could, I think, measure a cable's length with adequate resolution and accuracy.
Would it be feasible to retrofit an existing network infrastructure with this kind of cable length measurement system? In my opinion, no; it's not feasible. Firstly, you must design this retrofitted cable length measurement system in such a way that it does not degrade the 100/1000 Mb/s signaling on the cable. Good luck with that. Secondly, the switching/routing software that's executing on the iron inside the switch/router is several orders of magnitude slower than the time of flight of the electrical signals on the cable (at least within a local network segment this would be the case). So there's no point trying determine the time-of-flight differences between cables A and B when those time values are on the order a few nanoseconds, considering the software running on the switch/router requires around one millisecond (<-ballpark estimate) to process the incoming packet and decide which port to relay the packet out of, or to repackage the information for the next hop along the routing path.
-
1\$\begingroup\$ Perfect! This helps greatly! I hadn't considered the lag times between the physical signals and the software processing. When you say, "degrade the 100/1000 Mb/s signaling" are you referring to how the pulse will disrupt all other ongoing signaling? Do you think it would be possible if one were to disregard the quality of other signals and send out a slightly more sustained pulse -long enough that the software would have time to measure and process the differences between cable A & B? \$\endgroup\$ Commented Jun 28, 2016 at 15:24
-
1\$\begingroup\$ "When you say, 'degrade the 100/1000 Mb/s signaling' are you referring to how the pulse will disrupt all other ongoing signaling?" Yes; the transmission of Ethernet frames (I'm assuming Ethernet) must be halted momentarily to perform the in-band cable length measurement task. Additionally, I mean the retrofit hardware must not corrupt or degrade the integrity of the electrical signals on the wires during "ordinary operation" when a cable length measurement is not being performed. \$\endgroup\$ Commented Jun 28, 2016 at 20:58
-
1\$\begingroup\$ And yes, the u(t) pulse width must be wide enough to drive a logic high onto the wire during the entire measurement cycle when measuring the longest allowable cable length (which IIRC is 100m for Cat 5/5e/6 Ethernet cable). \$\endgroup\$ Commented Jun 28, 2016 at 21:08
-
1\$\begingroup\$ @JimFischer surely any measurement would also require one end of the cable to be disconnected, so the known resistance can be introduced and measured accurately? This would preclude use in an actual network. \$\endgroup\$– DavidCommented Jun 28, 2016 at 22:18
-
1\$\begingroup\$ @David "any measurement would also require [...]?" For the system I described above, yes. "This would preclude use in an actual network." Not necessarily. The system could conceivably synchronously DOWN both ends of the cable (halt normal network traffic across the cable), make the in-band cable length measurement, and then synchronously UP both ends and resume normal network traffic. The DOWN/UP control signal could be sent in-band via a special (custom?) Ethernet frame, for example, or via some out-of-band communication channel. \$\endgroup\$ Commented Jun 29, 2016 at 3:59
\$\begingroup\$
\$\endgroup\$
3
I used to have an Intel Pro 1 Gb lan card in my desktop computer and it came with a basic TDR software that could test the length of each of the eight wires in a lan cable (with a minimum length of 3 feet). This software required that the other end of the network cable is open (not connected to anything) and only showed the length of each wire. It did not show a graph as you see with an graphical TDR. I had that Intel NIC until a couple of years ago and I haven't found any NIC since that is capable of doing the same.
-
\$\begingroup\$ My D'Link DIR-605L router has a feature available in its web GUI called Virtual Circuit Test (VCT) which is supposed to do exactly this. It doesn't though, just says "TxPairError at meters" for any link that's down. \$\endgroup\$– Milind RCommented Sep 30, 2021 at 18:39
-
\$\begingroup\$ @MilindR Would you confirm is the VCT feature of DIR 605L could determinate de distance of the cable fault? I have a ethernet that fault one cable, I change it to the 7 and 8 pair to get a 100Mbps connection instead a 1000Mbps, is a 20 meter length aprox but is through the wall and its difficult to change. I would like to know how near the edge is the fault and I could acquire a DIR 605L very cheap \$\endgroup\$ Commented Apr 18, 2023 at 18:35
-
\$\begingroup\$ @AlfonsoVin No I couldn't get the VCT function of DIR605L to work properly \$\endgroup\$– Milind RCommented Apr 22, 2023 at 6:21
\$\begingroup\$
\$\endgroup\$
1
Modern communication systems essentially require TDR capability to operate, under the guise of equalization. The cable tester feature is merely some additional software to change the equalizer information into a useful display.
The TDR cable tester feature in Ethernet is found in 1000base-T gigabit ports. Like all high-speed links, equalization is needed to account for impedance discontinuities (reflections), dispersion, and other effects in the transmission medium. Otherwise, this creates inter-symbol interference which ruins the bit error rate.
Equalization can be seen as finding and compensating for the frequency response of the cable, but is also equivalent to finding and inverting the time-domain impulse response of the cable.
Transceivers must train equalizers this information when a link is first established. Built-in TDR cable tester software simply processes this measured impulse response with logic like finding and characterizing large peaks, and converting time into distance with some assumed velocity of propagation.
A more complex example of this is Wi-Fi imaging that can see through walls and make 3-D maps.
-
\$\begingroup\$ Awesome! Any idea how difficult it is to write software to bubble up this data for further analysis? \$\endgroup\$– Milind RCommented Apr 22, 2023 at 6:24
\$\begingroup\$
\$\endgroup\$
The Linux ethtool command includes a --cable-test-tdr switch, but looking at the Linux kernel source tree (as of 6.12.0-rc5), only the Marvell PHY driver implements the underlying cable_test_tdr_start. The driver supports TDR testing for the following Ethernet PHYs:
- Marvell 88E1510
- Marvell 88E1540
- Marvell 88E6341 Family
- Marvell 88E6390 Family
- Marvell 88E6393 Family
Various other PHYs look like they also include support for reading TDR information (e.g. there is evidence of TDR functionality in their Linux kernel headers files), but nobody has added this functionality to their device drivers.
