triggering things with ethernet

Hmmm, interesting question. Since switches do "buffer then transmit" this might go either way; if the same copy is retransmitted to all rj-45s this can be done with practically no skew (apart from that at the receiving side, clock phases, software latencies etc.). But I doubt many - if any - switches do that, my bet would be that they transmit one cable at a time. On the old coaxial Ethernet the answer is obvious but not much use.

Whatever the skew, it would surely be lower with 1Gbit/s ethernet. If the broadcast packets are sent out sequentially then they will be sent faster if the data rate is ten times higher. The cost is hardly any higher and the maximum range is the same.

John

Something else that can cause timing jitter is other traffic. It is well worth looking at a live network with Wireshark to see all the chatter that goes on between boxes that are not in theory doing anything. Things like ARP packets and DHCP exchanges. If any of the boxes are running Windows then there is lots of other background chatter. Even the switches talk to each other when they think nobody is listening...

John

I would use those RJ45 to RS-232 socket adapters and drive the cable from an RS-232 port. Wire all the cables in parallel, or daisy chain them. Very low skew. Use a high baud rate and send a very small message to keep the delay time low as well. Likely a 1 character "packet" would suffice.

If you are connected to the Phy directly with high priority ISR, I think you can do typical less than 1us.

problem is loading on the bus, or retransmissions, then it could be way longer

If you need precise timing, you can use real time ethernet

the thing is that a switch might not send broadcast messages to all ports at the same time, depending on traffic on each port and how it is implemented

it is not like old school 10mbit with hub where everyone hears everything at the same time all the time

I was wondering what sort of time skew I might get with an ordinary PC shooting out commands and fairly ordinary receivers and some switches. The PC could send a message to each of the boxes in the field, like "set your voltage to 17 when I say GO" and things like that to various boxes. Then it could broadcast a UDP message to all the boxes GO .

The boxes would have to be able to accept the usual TCP commands at unique IP addresses, and a UDP packet with some common IP address, and process the GO command rapidly, but I was wondering what the inherent time uncertainty might be with the ethernet itself.

I guess some switches are better than others, so if I found some good ones I could recommend them. I'd have to understand how a switch can handle a broadcast packet too. I think the GO packet is just sent to some broadcast address.

The fancy time protocols, ethercat and PTP and TSN (and others!) are complex on both ends. I might invent a new one, but that's another story.

With Windows <anything>, it's going to be pretty bad, especially when something like Java is running. There will be startling gaps, into the tens of milliseconds, sometimes longer.

Which is not a criticism - Windows is intended for desktop applications, not embedded realtime. So, wrong tool.

With RHEL (Red Hat Enterprise Linux) with a few fancy extensions, it's going to be on order of hundreds of microseconds, so long as you run the relevant applications are a sufficiently urgent realtime priority and scheduling policy.

To do better, one goes to partly hardware (with firmware) solutions.

How good that stack is depends on what the host computer is optimized for.

Modern network switches are typically far faster than RHEL.

It's been done, many times. Guilty. But PTP over ethernet is sweeping all that stuff away.

Joe Gwinn

All I want to know is the destination time skews after the PC sends the GO packet. Windows doesn't matter.

My customers mostly use some realtime Linux, but that doesn't matter either.

I want numbers!

I think pinging between random pairs of PC's on your in-house network should give you an estimate somewhere between the number you want and about twice that number, depending on how the trip time compares to the PC response times. It's at least a start.

I agree. The simplest reliable approach I can think of, is to use PTP or something of similar intent to distribute a well-synchronized clock to all of the devices in the house.

Then, send out a broadcast "Turn on, at time X" packet to all nodes, where "X" is far enough in the future that you can reasonably ensure that all nodes will receive the packet before time "X" arrives.

Each device sets a timer when it receives the packet.

The skew in the actual "turn on" times will depend on the success of your time-synchronization protocol, and the accuracy of each node's internal timer. It should be possible to get it down to much less than the skew in transmission times.

When using the QOS field in the message header, and switching actually validating that, I've seen jitter below e few usec even in the presence of videostream (with a lower QOS value).

On a sunny day (Mon, 17 Apr 2023 22:15:44 -0700) it happened snipped-for-privacy@coop.radagast.org (Dave Platt) wrote in snipped-for-privacy@coop.radagast.org>:

Yes this is about what I do in one project, I also send time sync every now and then so make sure the receiver clock is still running correct (has no battery backup) raspberrypi: ~ # cat time_to_ethernet_color_pic #!/bin/bash # hour and minutes to ethernet_color_pic hour=/bin/date +"%H" minute=/bin/date +"%M"

echo hour=$hour echo minute=$minute /bin/echo H$hour M$minute | /bin/netcat -w 0 -u 192.168.178.157 1024 sleep 1 /bin/echo H$hour M$minute | /bin/netcat -w 0 -u 192.168.178.157 1024 sleep 1 /bin/echo H$hour M$minute | /bin/netcat -w 0 -u 192.168.178.157 1024

Link and source code:

netcat is your friend for all network stuff I use UDP here as the receiving end uses UDP and send time 3 times to make sure it arrives, and that script is called from crontab 19 minutes past each hour:

Entry in crtab: # synchronise the LED lighting timers.

19 * * * * /usr/local/sbin/time_to_ethernet_color_pic &

The actual times ethernet color pic uses to switch things was programmed in its EEPROM via same UDP link.

I can 'talk' to that ethernet_color_pic using netcat too, once you called it from the address IP you are then it will reply to it, I use 2 xterms for that, one to start up the communication then use an other one to set events.

First xterm: To initiate an UDP llnk, ask for status or any other command: raspi95: ~ # netcat -u 192.168.178.157 1024 v

Second xterm: raspi95: ~ # netcat -u -l -p 1024 v

11:32 ADC 2=262 4=117 5=49 6=295 Light level=75 setpoint=128 RGB 0 0 0 l 128 Timers 0 23:59 0 0 0 1 18:0 180 0 47 2 22:0 180 0 47 3 255:255 255 255 255 4 255:255 255 255 255 T1 reload 175

h Panteltje (c) ethernet_color_pic-0.3

UDP commands:

a n print adc. B nnn set blue. c n clear digital output. G nnn set green. H nn set hours. h help, this help. i n print digital input. K nnn set clock calibration. L nnn set light sensitivity. l print light sensitivity. M nn set minutes. R nnn set red. S save settings. s n set digital output. T n hh mm rrr ggg bbb set timers (n = 0-4). v print status.

UDP protocal even allows me to make a disco light show by streaming audio data.

I would use RS485 for a better impedance match and better fan-out.

They sell these not to spec multi-port POE injector boxes, that parallel the two unused pairs in the RJ45 use them instead of switches, (or in adition to switches if you need ethernet for some other purpose)

Put your signal pulse in the "power" channel

Well not as much, the PHY I remember (an NSC part) does not buffer data so it must add just nanoseconds of delay. I meant that all skew is receiver generated, MAC, CPU etc.

Of course so, but I assume John controls all receiver nodes, his devices I have seen. Obviously he will have to rely no someone else's network design but taming it to behave coherently may be doable.

If you need some diversity of triggered and/or trigger devices you put on the market yes, of course. In scientific equipment this is rarely the case, they typically need a particular system for a particular problem and if you design all of it you have more options.