Forums

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Started by Klaus Kragelund September 19, 2013
Hi

I have a system comprised of a computer with a TCP/IP application and a gateway connected to this computer. I need to measure the delay of the gateway, by measuring the delay on the output of the gateway and the signal on the ethernet line

But, the ethernet line is active all the time and I do not have a TCP/IP decoder and it is impossible to trigger on the burried TCP/IP packet.

From what I can learn about the ethernet line, the 100BASE-TX fills the gaps with idle signal. The 100BASE-T4 standard apparently only sends data on the ethernet line when information is actually moved.

Is there any way to "tell" the PC to use a specific standard so its possible to have the scope trigger on a TCP/IP packet?

Regards

Klaus
On 19.9.13 11:30 , Klaus Kragelund wrote:
> Hi > > I have a system comprised of a computer with a TCP/IP application and a gateway connected to this computer. I need to measure the delay of the gateway, by measuring the delay on the output of the gateway and the signal on the ethernet line > > But, the ethernet line is active all the time and I do not have a TCP/IP decoder and it is impossible to trigger on the burried TCP/IP packet. > > From what I can learn about the ethernet line, the 100BASE-TX fills the gaps with idle signal. The 100BASE-T4 standard apparently only sends data on the ethernet line when information is actually moved. > > Is there any way to "tell" the PC to use a specific standard so its possible to have the scope trigger on a TCP/IP packet? > > Regards > > Klaus
It depends, usually not. This is a hardware function of the interface chip / card. What you have on the cable is an IP packet in an Ethernet frame. TCP transport is split in segments encapsulated in some of the IP packets. If you have to time the TCP transport, my guess is that you do need protocol analyzers, but even then the scope trigger does not usually exist. -- Tauno Voipio
On Thursday, September 19, 2013 10:50:10 PM UTC+2, Tauno Voipio wrote:
> On 19.9.13 11:30 , Klaus Kragelund wrote: > > > Hi > > > > > > I have a system comprised of a computer with a TCP/IP application and a gateway connected to this computer. I need to measure the delay of the gateway, by measuring the delay on the output of the gateway and the signal on the ethernet line > > > > > > But, the ethernet line is active all the time and I do not have a TCP/IP decoder and it is impossible to trigger on the burried TCP/IP packet. > > > > > > From what I can learn about the ethernet line, the 100BASE-TX fills the gaps with idle signal. The 100BASE-T4 standard apparently only sends data on the ethernet line when information is actually moved. > > > > > > Is there any way to "tell" the PC to use a specific standard so its possible to have the scope trigger on a TCP/IP packet? > > > > > > Regards > > > > > > Klaus > > > > > > It depends, usually not. > > > > This is a hardware function of the interface chip / card. > > > > What you have on the cable is an IP packet in an Ethernet frame. TCP > > transport is split in segments encapsulated in some of the IP packets. > > > > If you have to time the TCP transport, my guess is that you do need > > protocol analyzers, but even then the scope trigger does not usually exist. >
Ok, so an option would be to find an old PC, with older HW, so the idle signalling is not implemented Thanks Klaus
Hi Klaus,

On 9/19/2013 1:30 PM, Klaus Kragelund wrote:
> I have a system comprised of a computer with a TCP/IP application and > a gateway connected to this computer. I need to measure the delay of > the gateway, by measuring the delay on the output of the gateway and > the signal on the ethernet line
<grin>
> But, the ethernet line is active all the time and I do not have a TCP/IP > decoder and it is impossible to trigger on the burried TCP/IP packet.
What you are looking for is a protocol analyzer. Some *logic* analysers can be coerced into performing this function. You can also build a little circuit (PHY+MAC) and carefully control the traffic on the wire so you *know* that each received packet detected by your little circuit corresponds to a packet on the other side of the gateway. E.g., imagine two of these -- one on each side. You arrange for <something> to push packets at your gateway. You trigger the 'scope when the first circuit sees the packet (ANY packet). Then, monitor the output of the second circuit to see when the gateway has propagated the packet. As long as the time between packets is much longer than the transit time across the gateway, you should be able to know that *this* trigger event is associated with *that* propagated packet (and not the one before, etc.) [Think about how you would do something similar with an EIA232 port. Or, worse, a synchronous serial port. Use the "Rx interrupt" line to signal "character received" -- you don't care *which* character because you are controlling the content of the link as well and are arranging for just "measurement" characters to be passed. Do teh same on the other side of the gateway/bridge. Compare these two digital signals.] A simpler way is to write a piece of code to monitor for a particular packet -- doing nothing else and paying attention to how the code operates so it takes relatively constant time. Then, have the code toggle a digital output when it sees a suitable packet. This is just a software version of the above hardware. Possibly easier to implement (with a scrap PC or two). You could even do it in the same PC and have the PC "time" the difference. Of course, it depends on how much resolution you really need in your measurements...
On Thursday, September 19, 2013 11:58:33 PM UTC+2, Don Y wrote:
> Hi Klaus, > > > > On 9/19/2013 1:30 PM, Klaus Kragelund wrote: > > > I have a system comprised of a computer with a TCP/IP application and > > > a gateway connected to this computer. I need to measure the delay of > > > the gateway, by measuring the delay on the output of the gateway and > > > the signal on the ethernet line > > > > <grin> > > > > > But, the ethernet line is active all the time and I do not have a TCP/IP > > > decoder and it is impossible to trigger on the burried TCP/IP packet. > > > > What you are looking for is a protocol analyzer. Some *logic* analysers > > can be coerced into performing this function. > > > > You can also build a little circuit (PHY+MAC) and carefully control the > > traffic on the wire so you *know* that each received packet detected > > by your little circuit corresponds to a packet on the other side of > > the gateway. > >
Nice idea. I can even take apart the gateway and solder a wire to the Phy on that board, so I do not need external equipment [snip]
> > > A simpler way is to write a piece of code to monitor for a particular > > packet -- doing nothing else and paying attention to how the code > > operates so it takes relatively constant time. Then, have the > > code toggle a digital output when it sees a suitable packet. > >
Ok, so I could even have a PC listening in on the line, with a prioritized interrupt, to trigger say the serial port RTS when a package is detected I just need to turn off all that crap than windows generate in the background. We installed a SW tool to monitor the traffic generated by a computer running windows 7, all kinds of funny stuff going on (probably some from NSA also) Cheers Klaus
Klaus Kragelund <klauskvik@hotmail.com> wrote:

>On Thursday, September 19, 2013 11:58:33 PM UTC+2, Don Y wrote: >> Hi Klaus, >> >> >> >> > >Ok, so I could even have a PC listening in on the line, with a prioritized interrupt, to trigger say the serial port RTS when a package is detected > >I just need to turn off all that crap than windows generate in the background. We installed a SW tool to monitor the traffic generated by a computer running windows 7, all kinds of funny stuff going on (probably some from NSA also)
Linux is the magic word here. I bet there are lots of tools for Linux which can do the measurement for you. No need to use a scope. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
On Thu, 19 Sep 2013 13:30:12 -0700 (PDT), the renowned Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>Hi > >I have a system comprised of a computer with a TCP/IP application and a gateway connected to this computer. I need to measure the delay of the gateway, by measuring the delay on the output of the gateway and the signal on the ethernet line > >But, the ethernet line is active all the time and I do not have a TCP/IP decoder and it is impossible to trigger on the burried TCP/IP packet. > >From what I can learn about the ethernet line, the 100BASE-TX fills the gaps with idle signal. The 100BASE-T4 standard apparently only sends data on the ethernet line when information is actually moved. > >Is there any way to "tell" the PC to use a specific standard so its possible to have the scope trigger on a TCP/IP packet? > >Regards > >Klaus
Have you tried Wireshark (free)? Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Hi Klaus,

On 9/19/2013 3:15 PM, Klaus Kragelund wrote:
>> You can also build a little circuit (PHY+MAC) and carefully control the >> traffic on the wire so you *know* that each received packet detected >> by your little circuit corresponds to a packet on the other side of >> the gateway. > > Nice idea. I can even take apart the gateway and solder a wire to the > Phy on that board, so I do not need external equipment
D'oh! That's an even better idea. Or, ask the guys who wrote the code to push a byte to some (unused) I/O port or memory address that you can configure a logic analyzer, 'scope, etc. to monitor. (I am assuming this is the same gateway that you mentioned in a previous post?)
>> A simpler way is to write a piece of code to monitor for a particular >> packet -- doing nothing else and paying attention to how the code >> operates so it takes relatively constant time. Then, have the >> code toggle a digital output when it sees a suitable packet. > > Ok, so I could even have a PC listening in on the line, with a > prioritized interrupt, to trigger say the serial port RTS when a > package is detected
Only if that PC is running some software that you have written to run on "baremetal". If you put windows (or damn near any other COTS OS) in the picture, then you will get lousy data. There can be large variations in interrupt response times in these systems.
On Thu, 19 Sep 2013 13:30:12 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>I have a system comprised of a computer with a TCP/IP application >and a gateway connected to this computer. I need to measure the >delay of the gateway, by measuring the delay on the output of >the gateway and the signal on the ethernet line.
The "gateway" probably has two ethernet ports. You can simply ping the computer THROUGH the gateway, to get an approximation of the delay. The ping time (latency) will be twice the delay through the gateway, plus whatever the computer adds. Just ping the computer directly, then ping it through the "gateway" and subtract for the "gateway" delay. You should get similar results with both ICMP and UDP ping. If your "gateway" happens to be a router, you may need to do some configuring to allow pinging devices on the LAN side from the WAN side. However, pings should work normally to the WAN side, from the LAN side without doing anything special. For better resolution pings try Fping: <http://fping.sourceforge.net> <http://www.kwakkelflap.com/fping.html> -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
On a sunny day (Thu, 19 Sep 2013 23:24:40 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <523b8764.1037008546@news.kpn.nl>:

>Linux is the magic word here. I bet there are lots of tools for Linux >which can do the measurement for you. No need to use a scope.
ping!