How to implement TDR in software?

As far as I know, there's no way to create a TDR, with a standard NIC.

I've seen a reference to using a GB NIC, with the right software, as a TDR. I think "marvel" is always mentioned.

Given that one bit, at a BG rate, is about one foot (as a wildass simplification and approximation) it's not out of the question. The software could do some sort of a statistical analyisis to get the uncertaintity range down to a small number of feet.

Google finds this, along with other stuff.

According to what I saw there, it simply adds some diagnostics to the NIC, which is still a long way from being a TDR. For example, can that chip tell you the distance to a short or open?

This is probably true. The PCI bus which carries the NIC interrupts runs at 33 MHz. That 30ns period is about 20 ft of signal in Cat5+. So that's going to be the limit of resolution if you can program the hardware to even be that good. Some on-card special function could be faster, but it will have to have a fast clock.

Pentascanners [et al] aren't cheap for good reason.

-- Robert

Well, the Alaska chipset by Marvell was going to support that functionality that's well beyond the reach for an ordinary NIC card. On the other hand, Alaska is a Gigabit chipset, so it's bound to have much more circuitry to deal with both near-end and far-end cross-talk, which makes it few steps closer to being able to actually test the cable than your regular 2-pair 10/100 NIC.

This chipset first surfaced about a year ago here:

However, all attempts to get my hands around a mobo or a NIC with Alaska chipset to date have failed. Several times I have specifically seek out a part with Alaska chipset in the specs and every time I've gotten a Realtec's chipset instead. So, I have all reasons to suspect that Virtual Cable Tester technology, although sounds very interesting indeed, is not easy to implement, and the manufacturer has all kinds of problems with production as well. With that said, I would be glad to hear from someone who was able to get that elusive Alaska. Any real-life feedback will be greatly appreciated!

Ah, but all four pairs are used in a fancy encoding scheme. The transitions on any given pair are happening at 100 MHz, or a period of 10 ns, about 2m/7ft wire. Divided by two since the reflection takes double.

Statistical analysis on digital signals? Only if there's big scatter or the signal is midrange so it splits.

Oh, if the software or hardware functionality is built-into the GBE controller chip, resolutions down to it's clock are possible.

-- Robert

My understanding was that they give you exactly that, the distance to short/open but not much else. So, of course it is not a good TDR, but if this function were there, it would have been a very nice addition to the network admin's toolbox indeed. Below is a quote from that whitepaper:

Upon installation of a Gigabit switch, the IT manager finds that all Gigabit ports are functioning with the exception of the fourth port. He/she then sees through the switch software interface a ?pop-up? message that reads: ?Network connection has failed on Port 4. Pair 2 (typically pins 3 and 6, orange color) of your CAT 5 cable is discontinuous (?open?) approximately

68 meters from the switch.? The IT manager is then able to make the repair to the cabling plant and all ports of the switch operate flawlessly at Gigabit speeds. The engine behind the above software pop-up message is Marvell?s VCT technology.

Once again, I don't think the technology is quite there outside the lab yet. I was not able to procure a NIC or a mobo that was said to have an Alaska single-port transciever and I'm not aware of a switch using a multi-port version of it either.

As we know the whole TDR concept involves 1) sending a signal down a cable, 2) waiting for its return,

3) taking the time difference, 4) and calculating the distance.

Does a standard NIC allow itself to be configured to send an electrical signal down a cable? Is there a standard way to trigger an NIC (regardless of brand) to send a signal? I was thinking, if it's possible to write a program to achieve 1) and it's guaranteed that the signal would get reflected either at a fault or end of cable, then the rest would not be a problem.

------------------------------------- James Knott wrote:

##-----------------------------------------------##

Article posted with Cabling-Design.com Newsgroup Archive

no-spam read and post WWW interface to your favorite newsgroup -

comp.dcom.cabling - 2354 messages and counting!

##-----------------------------------------------##

A NIC has to send a signal to transmit. However, there's more to a TDR to that. Generally, you send a pulse down the wire and measure the echo characteristics. It's the measuring of the echo that's the hard part.

Well, not a *REGULAR* 10/100 Ethernet NIC card. It sends signal down one pair and receives it from another. So, you are so out of luck if you would have tried to implement it on a *regular* NIC. In any case, I seriously doubt you will have access to such low level of programming on the chipset.

Gigabit NICs are different: they transmit and receive on the same pair (all four of them). As such, they are much better suited for experiments like that (Marvell chipset is one example) although I have a feeling that you still can't get thru to such low level programming on any chipset that's other than the elusive Marvell Alaska.

It's undoubtedly the former.

I'm aware of at least one 10M chipset which supported such a feature.

You would need the data *book* for starters. As well as knowing how the chipset is plugged into the BUS.

This is really a driver programming issue.