How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

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

Ok, so an option would be to find an old PC, with older HW, so the idle signalling is not implemented

Thanks

Klaus

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

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]

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

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=.) 
--------------------------------------------------------------

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

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?)

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.

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:

--
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 snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

ping!

Actually, it's unclear if that is the case. In previous posts, Klaus has referenced an ethernetEIA485 gateway. As such, there may not be a device on the far side that responds to ICMP echo requests!

Or, the gateway may simply NOT forward them! (what is the EIA485 equivalent of an ICMP echo request/reply??? Is the protocol massaged *in* the gateway?)

Be careful about how much you trust these numbers!

First, they might not have the "resolution" that you need.

Second, you have no way of knowing where the ICMP echo server is implemented in the network stack/kernel/etc. I.e., no way to quantify how much of the reported RTT occurs *in* the remote host, etc.

Klaus hasn't indicated what sorts of numbers he is looking for or how he wants to use the data he gathers. He could end up "seeing" propagation delays longer or shorter than what you might see in a ping.

Ping was never intended to be a "fine grained" tool. So, network stacks may only give it "token" importance.

[And, while it is "required", you may encounter systems that disable ICMP services completely! (Think: stealth) ]

OTOH, I'll admit it would be a "cheap" test to perform *today*. And, depending on the results obtained, may render further testing unnecessary.

The current product we have is a Moxa gateway, with 2 ethernet ports and 2 RS485 ports. The new project is to avoid this cost and make it ourself

We are just interested in how much delay it is, in the sub ms range resolution

Cheers

Klaus

Klaus,

I have not had my morning quart of coffee yet, so I'm not really following what you want to measure. Is the setup: Ethernet in -> gateway -> Ethernet out and you want to measure latency Eth packet to Eth packet? or Ethernet in -> gateway -> some other signal out and measure Eth packet in to assertion of some other signal out?

If it is the first, Ethernet to Ethernet you can use Wireshark or tcpdump and a Linux box with a couple of NICs. Either have the Linux box generate the packet in or put a hub/switch-with-copy-port on the in side. You can tell tcpdump to capture on both interfaces. Then look at the deltas between the packets in the capture.

If it's Eth to signal out, you need some code/interface to monitor signal out on the Linux box. Use a high enough resolution clock source in the code and match up the tcpdump packet time stamps with the signal capture time stamp.

I think you can do what you want with a single Linux box and use that box as your measure time source.

--
Chisolm 
Republic of Texas 
Raining today, more on the way!

Do you have a Moxa model number?

How sub-msec range do you need? Using Fping, 0.1 msec is possible.

0.01 msec is not. I suspect that you do not need that level of precision and resolution. You can try: which claims to be a high resolution ping. When I tried it, I got 0.001 msec resolution, but only 1 msec accuracy. The numbers were all over the place. Note the variations in the examples.

Are you looking for the delay between ethernet ports, which ping can measure, or are you looking for the delay between the ethernet ports and the RS485 ports, which is more difficult?

If you're going to be measuring the ethernet -> RS485 delay, buy an ethernet activated relay board. It closes a relay or provides a change in signal level that can be viewed on a scope. The actual delay does not matter, as long as it's fairly consistent. Measure the delay between sending the initiating packets to the relay board. Then, insert the "gateway" between whatever you're using to send the ethernet packets, and measure it again. Subtract the two numbers and that's your delay.

--
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

I ran a fast test pinging my local router using hrping:

The average latency was 0.521 msec, but the standard deviation was

0.214 msec, making nanosecond resolution of the average latency rather useless. What resolution and accuracy do you really need?

--
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

*Quart*??! Yikes! I drink a pint of tea "fresh from bed" and thought *that* was a lot! (OTOH, I then *continue* to drink another 6-10 pints over the remaining course of the day so I guess I shouldn't make any claims as to the color of the kettle!)

I believe the latter -- from previous posts. The gateway makes an "industrial control" (?) EIA485 network available to the TCP/IP world (or, vice versa)

I think the problem is getting at the signal on the "non-ethernet" side of the gateway. In a manner that has some small and predictable latency.

E.g., assuming industrial control, you'd want to know the propagation delay across the gateway if any aspect of the control algorithm resided on the "far side". You'd also want to know how consistent this delay is -- or, modify your protocols to include timestamps (wrt the industrial control system's idea of time) in messages.

d f g

Sorry if that is not clear, it is:

Ethernet in -> Gateway -> RS485 out (Modbus)

So I am interested in the delay of the gateway, so we can estimate the roun d-robin cycle time for a number of units connected to the gateway, with the delay of the gateway included in the equation

[snip]

The problem is how to sync those two clocks? I thought about making a small program to send the TCP/IP packet from the PC and toogling some other sign al at the PC at the same time, so I could measure the time from that toogle to the gateway RS485 port reacted, but that would only be the delay in one direction

I could assume (assumptions is the.....) that the ethernet TCP/IP latency w ould be small, and just record the time from sending a package to getting a n answer back, but it will probably be wrong by at least 1-10ms (the ping t ime)

Cheers

Klaus

I would be satisfied with 0.1ms resolution, that would be more than good (the unit without a gateway has 25ms turn-around time

Cheers

Klaus

Hi Klaus,

[Argh, what is it with all these blank l> The problem is how to sync those two clocks? I thought about making a

Is there any bit of code on the modbus side that is automatically invoked when "something special" is sent to it? Something that you can observe independently?

Similarly, some event that you can manually generate on the modbus side that will cause some "specific" packet/message to be IMMEDIATELY sent up the wire. I realize you would have to arbitrate for ownership of that bus (you would have to do this any time ANY traffic, regardless of direction, was gated onto the bus) but you could possibly arrange for other traffic to be quiescent?

Is the content of those messages "time critical" in that they are used *in* the control loops? Or, just SCADA that you would *like* to have available, "promptly" (for some idea of "promptly"). I.e., does the performance of your overall system degrade as the propagation delay across the gateway increases?

Depends on how efficient the gateway is at moving the packets it encounters. E.g., does it have to do any filtering or does it just pass everything destined for a particular address/subnet?

What does the current product *claim* this delay to be? Or, is it not specified?

What unit? What and how are you measuring latency?

25 msec is a very long delay. Typical small packet ICMP latency for my junk router from LAN -> WAN -> LAN is about 1-2 msec. Something is wrong with your measurement.

Please re-read my postings and answer the other questions: Between which ports on the "gateway" are you going to be measuring? What's the Moxa model number?

For additional entertainment, try pinging with large packets and watch the latency increase.

I suspect that you're trying to determine what to put on a data sheet or product specification. Whatever number you pick, it has to be measureable by the customer. If I can't understand what you're trying to accomplish, what devices you're measuring, and how you intend to measure it, there's little hope that a prospective customer can do it. Revising the 802.3 specifications for your convenience isn't going to help.

Good luck.

--
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