Forums

How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

Started by Klaus Kragelund September 19, 2013
Hi Jeff,

On 9/19/2013 8:16 PM, Jeff Liebermann wrote:
> 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.
Actually, it's unclear if that is the case. In previous posts, Klaus has referenced an ethernet<->EIA485 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?)
> 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>
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.
On Friday, September 20, 2013 11:34:55 AM UTC+2, Don Y wrote:
> Hi Jeff, > > > > On 9/19/2013 8:16 PM, Jeff Liebermann wrote: > > > 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. > > > > Actually, it's unclear if that is the case. In previous posts, > > Klaus has referenced an ethernet<->EIA485 gateway. As such, there > > may not be a device on the far side that responds to ICMP echo > > requests! >
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
> > > 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?) > > > > > 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> > > > > 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. >
We are just interested in how much delay it is, in the sub ms range resolution Cheers Klaus
On Fri, 20 Sep 2013 03:07:53 -0700, Klaus Kragelund wrote:

> On Friday, September 20, 2013 11:34:55 AM UTC+2, Don Y wrote: >> Hi Jeff, >> >> >> >> On 9/19/2013 8:16 PM, Jeff Liebermann wrote: >> >> > 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. >> >> >> >> Actually, it's unclear if that is the case. In previous posts, >> >> Klaus has referenced an ethernet<->EIA485 gateway. As such, there >> >> may not be a device on the far side that responds to ICMP echo >> >> requests! >> >> > 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 > > >> >> 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?) >> >> >> >> > 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> >> >> >> >> 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. >> >> > 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!
On Fri, 20 Sep 2013 03:07:53 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>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
Do you have a Moxa model number?
>We are just interested in how much delay it is, in the sub ms range resolution
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: <https://www.cfos.de/en/ping/ping.htm> 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
On Fri, 20 Sep 2013 09:55:15 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

>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: ><https://www.cfos.de/en/ping/ping.htm> >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.
I ran a fast test pinging my local router using hrping:
> (...) > From 192.168.1.1: bytes=60 seq=005f TTL=64 ID=af80 time=0.656ms > From 192.168.1.1: bytes=60 seq=0060 TTL=64 ID=af81 time=0.526ms > From 192.168.1.1: bytes=60 seq=0061 TTL=64 ID=af82 time=0.430ms
> Packets: sent=97, rcvd=97, error=0, lost=0 (0.0% loss) in 48.000440 sec > RTTs in ms: min/avg/max/dev: 0.186 / 0.521 / 1.098 / 0.214 > Bandwidth in kbytes/sec: sent=0.121, rcvd=0.121
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
Hi Joe,

On 9/20/2013 9:07 AM, Joe Chisolm wrote:
> On Fri, 20 Sep 2013 03:07:53 -0700, Klaus Kragelund wrote:
> I have not had my morning quart of coffee yet,
*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!)
> 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?
I believe the latter -- from previous posts. The gateway makes an "industrial control" (?) EIA485 network available to the TCP/IP world (or, vice versa)
> 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.
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.
On Friday, September 20, 2013 6:07:52 PM UTC+2, Joe Chisolm wrote:
> On Fri, 20 Sep 2013 03:07:53 -0700, Klaus Kragelund wrote: >=20 >=20 >=20 > > On Friday, September 20, 2013 11:34:55 AM UTC+2, Don Y wrote: >=20 > >> Hi Jeff, >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> On 9/19/2013 8:16 PM, Jeff Liebermann wrote: >=20 > >>=20 >=20 > >> > On Thu, 19 Sep 2013 13:30:12 -0700 (PDT), Klaus Kragelund >=20 > >>=20 >=20 > >> > <klauskvik@hotmail.com> wrote: >=20 > >>=20 >=20 > >>=20 >=20 > >> > >=20 > >> >> I have a system comprised of a computer with a TCP/IP application >=20 > >>=20 >=20 > >> >> and a gateway connected to this computer. I need to measure the >=20 > >>=20 >=20 > >> >> delay of the gateway, by measuring the delay on the output of >=20 > >>=20 >=20 > >> >> the gateway and the signal on the ethernet line. >=20 > >>=20 >=20 > >>=20 >=20 > >> > >=20 > >> > The "gateway" probably has two ethernet ports. >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> Actually, it's unclear if that is the case. In previous posts, >=20 > >>=20 >=20 > >> Klaus has referenced an ethernet<->EIA485 gateway. As such, there >=20 > >>=20 >=20 > >> may not be a device on the far side that responds to ICMP echo >=20 > >>=20 >=20 > >> requests! >=20 > >>=20 >=20 > >>=20 >=20 > > The current product we have is a Moxa gateway, with 2 ethernet ports an=
d
>=20 > > 2 RS485 ports. The new project is to avoid this cost and make it oursel=
f
>=20 > >=20 >=20 > >=20 >=20 > >>=20 >=20 > >> Or, the gateway may simply NOT forward them! (what is the >=20 > >>=20 >=20 > >> EIA485 equivalent of an ICMP echo request/reply??? Is >=20 > >>=20 >=20 > >> the protocol massaged *in* the gateway?) >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> > You can simply ping >=20 > >>=20 >=20 > >> > the computer THROUGH the gateway, to get an approximation of the >=20 > >>=20 >=20 > >> > delay. The ping time (latency) will be twice the delay through the >=20 > >>=20 >=20 > >> > gateway, plus whatever the computer adds. Just ping the computer >=20 > >>=20 >=20 > >> > directly, then ping it through the "gateway" and subtract for the >=20 > >>=20 >=20 > >> > "gateway" delay. You should get similar results with both ICMP and >=20 > >>=20 >=20 > >> > UDP ping. >=20 > >>=20 >=20 > >>=20 >=20 > >> > >=20 > >> > If your "gateway" happens to be a router, you may need to do some >=20 > >>=20 >=20 > >> > configuring to allow pinging devices on the LAN side from the WAN >=20 > >>=20 >=20 > >> > side. However, pings should work normally to the WAN side, from the >=20 > >>=20 >=20 > >> > LAN side without doing anything special. >=20 > >>=20 >=20 > >>=20 >=20 > >> > >=20 > >> > For better resolution pings try Fping: >=20 > >>=20 >=20 > >> > <http://fping.sourceforge.net> >=20 > >>=20 >=20 > >> > <http://www.kwakkelflap.com/fping.html> >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> Be careful about how much you trust these numbers! >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> First, they might not have the "resolution" that you need. >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> Second, you have no way of knowing where the ICMP echo server >=20 > >>=20 >=20 > >> is implemented in the network stack/kernel/etc. I.e., no way >=20 > >>=20 >=20 > >> to quantify how much of the reported RTT occurs *in* the >=20 > >>=20 >=20 > >> remote host, etc. >=20 > >>=20 >=20 > >>=20 >=20 > >>=20 >=20 > >> Klaus hasn't indicated what sorts of numbers he is looking for >=20 > >>=20 >=20 > >> or how he wants to use the data he gathers. He could end up >=20 > >>=20 >=20 > >> "seeing" propagation delays longer or shorter than what you might >=20 > >>=20 >=20 > >> see in a ping. >=20 > >>=20 >=20 > >>=20 >=20 > > We are just interested in how much delay it is, in the sub ms range >=20 > > resolution >=20 > >=20 >=20 > > Cheers >=20 > >=20 >=20 > > Klaus >=20 >=20 >=20 > Klaus, >=20 >=20 >=20 > I have not had my morning quart of coffee yet, so I'm not really followin=
g
>=20 > what you want to measure. Is the setup: >=20 > Ethernet in -> gateway -> Ethernet out >=20 > and you want to measure latency Eth packet to Eth packet? >=20 > or >=20 > Ethernet in -> gateway -> some other signal out >=20 > and measure Eth packet in to assertion of some other signal out? >=20
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]
>=20 > If it's Eth to signal out, you need some code/interface to monitor >=20 > signal out on the Linux box. Use a high enough resolution clock source >=20 > in the code and match up the tcpdump packet time stamps with the signal >=20 > capture time stamp. >=20
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
On Friday, September 20, 2013 6:55:15 PM UTC+2, Jeff Liebermann wrote:
> On Fri, 20 Sep 2013 03:07:53 -0700 (PDT), Klaus Kragelund > > <klauskvik@hotmail.com> wrote: > > > > >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 > > > > Do you have a Moxa model number? > > > > >We are just interested in how much delay it is, in the sub ms range resolution > > > > How sub-msec range do you need? Using Fping, 0.1 msec is possible. >
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 lines in your posts???]

On 9/20/2013 11:00 AM, Klaus Kragelund wrote:

> 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 signal 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
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?
> I could assume (assumptions is the.....) that the ethernet TCP/IP > latency would be small,
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?
> and just record the time from sending a package to getting an answer > back, but it will probably be wrong by at least 1-10ms (the ping time)
What does the current product *claim* this delay to be? Or, is it not specified?
On Fri, 20 Sep 2013 11:01:33 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>I would be satisfied with 0.1ms resolution, that would be more >than good (the unit without a gateway has 25ms turn-around time
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