DComTalk.com

Hi!

I wonder if anyone can help me understand something. I've just read the
whitepaper about the VCT Technology by Marvell and the TDR technique used.
I was just wondering, how did they implemented TDR in software? Did they
manufacture the NIC in such a way that it acts as a reflectometer or did
they program it? If it's the latter, how is that possible?

Thanks for your time. Have a nice day!

-------------------------------------



##-----------------------------------------------#
Article posted with Cabling-Design.com Newsgroup Archiv
http://www.cabling-design.com/forum
no-spam read and post WWW interface to your favorite newsgroup -
comp.dcom.cabling - 2335 messages and counting
##-----------------------------------------------##

Al Dykes <adykes@panix.com> wrote:

Given that one bit, at a BG rate, is about one foot (as
a wildass simplification and approximation)

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.

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.

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

http://www.marvell.com/products/transceivers/quadport/VCT_White_Paper.pdf

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

-- Robert

Dmitri(Cabling-Design.com wrote:

James Knott wrote:

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

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.

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?

James Knott <james.knott@rogers.com> wrote:

NANewbie wrote:
I wonder if anyone can help me understand something. I've
just read the whitepaper about the VCT Technology by Marvell
and the TDR technique used. I was just wondering, how did
they implemented TDR in software? Did they manufacture the
NIC in such a way that it acts as a reflectometer or did
they program it? If it's the latter, how is that possible?

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

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

In article <XsDQe.546$Kk1.317@newssvr19.news.prodigy.com>,
Robert Redelmeier <redelm@ev1.net.invalid> wrote:

James Knott <james.knott@rogers.com> wrote:
NANewbie wrote:
I wonder if anyone can help me understand something. I've
just read the whitepaper about the VCT Technology by Marvell
and the TDR technique used. I was just wondering, how did
they implemented TDR in software? Did they manufacture the
NIC in such a way that it acts as a reflectometer or did
they program it? If it's the latter, how is that possible?

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

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

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.

http://www.marvell.com/products/transce ... _Paper.pdf




--
a d y k e s @ p a n i x . c o m

Don't blame me. I voted for Gore.

NANewbie wrote:

Hi!

I wonder if anyone can help me understand something. I've just read the
whitepaper about the VCT Technology by Marvell and the TDR technique used.
I was just wondering, how did they implemented TDR in software? Did they
manufacture the NIC in such a way that it acts as a reflectometer or did
they program it? If it's the latter, how is that possible?

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

James Knott wrote:

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

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:

http://www.cabling-design.com/forums/Vi ... 491-21.htm

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!

--
Dmitri Abaimov, RCDD
http://www.cabling-design.com
Cabling Forum, color codes, pinouts and other useful resources for
premises cabling users and pros
http://www.cabling-design.com/homecabling
Residential Cabling Guide
-------------------------------------


##-----------------------------------------------##
Article posted with Cabling-Design.com Newsgroup Archive
http://www.cabling-design.com/forums
no-spam read and post WWW interface to your favorite newsgroup -
comp.dcom.cabling - 2340 messages and counting!
##-----------------------------------------------##

James Knott wrote:

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?

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:


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


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.

--
Dmitri Abaimov, RCDD
http://www.cabling-design.com
Cabling Forum, color codes, pinouts and other useful resources for
premises cabling users and pros
http://www.cabling-design.com/homecabling
Residential Cabling Guide
-------------------------------------


##-----------------------------------------------##
Article posted with Cabling-Design.com Newsgroup Archive
http://www.cabling-design.com/forums
no-spam read and post WWW interface to your favorite newsgroup -
comp.dcom.cabling - 2344 messages and counting!
##-----------------------------------------------##

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:

NANewbie wrote:

Hi!

I wonder if anyone can help me understand something. I've just
read the
whitepaper about the VCT Technology by Marvell and the TDR
technique used.
I was just wondering, how did they implemented TDR in software?
Did they
manufacture the NIC in such a way that it acts as a reflectometer
or did
they program it? If it's the latter, how is that possible?

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

##-----------------------------------------------##
Article posted with Cabling-Design.com Newsgroup Archive
http://www.cabling-design.com/forums
no-spam read and post WWW interface to your favorite newsgroup -
comp.dcom.cabling - 2354 messages and counting!
##-----------------------------------------------##

NANewbie wrote:

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.

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.

NANewbie wrote:

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.

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.

--
Dmitri Abaimov, RCDD
http://www.cabling-design.com
Cabling Forum, color codes, pinouts and other useful resources for
premises cabling users and pros
http://www.cabling-design.com/homecabling
Residential Cabling Guide
-------------------------------------

##-----------------------------------------------#
Article posted with Cabling-Design.com Newsgroup Archiv
http://www.cabling-design.com/forum
no-spam read and post WWW interface to your favorite newsgroup -
comp.dcom.cabling - 2381 messages and counting
##-----------------------------------------------##

NANewbie <genielicious_at_yahoo_dot_com@foo.com> wrote:

Hi!

I wonder if anyone can help me understand something. I've just read the
whitepaper about the VCT Technology by Marvell and the TDR technique used.
I was just wondering, how did they implemented TDR in software? Did they
manufacture the NIC in such a way that it acts as a reflectometer or did
they program it? If it's the latter, how is that possible?

It's undoubtedly the former.

--
Mark Evans
St. Peter's CofE Aided School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763

Dmitri(Cabling-Design.com) <info_at_cabling-design_dot_com@foo.com> wrote:

NANewbie wrote:

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.

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

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

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.

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.

--
Mark Evans
St. Peter's CofE Aided School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763