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

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.

My suggestion would be to measure it experimentally on a modest sized configuration with the depth of switches you intend to use and have the triggered devices send back a step function to the master box on an identical length of coax. That should give you a good idea of the delay per additional switch added and how the jitter increases with depth.

It will obviously depend a lot on the software and stack at the receiver

- if you can control that and/or put it into a quick response state then you might be able to do quite well. That or have a means to calibrate out the systematic delays using the same length of coax as a reference. Depends a lot on good behaviour from the switches so you might have to be careful about which chipsets you specify.

I just assumed the initiation is sort of a pushed button by a person, so all the skew comes after the broadcast packet is out.

Well, sometimes yes. If they are all dps devices, I can control them. Which is not to say I don't get surprised, stunned etc :-).

John mentioned some 125us, apparently this is the ballpark he is after and wants some verification. This is a huge amount of time, especially by his picosecond standards, if he were after something that fast/low skew obviously he would not have thought of Ethernet.

I have considered syncing multiple MCA-s so in list mode they have skew well below a nanosecond but the customers for that sort of thing just don't call. Obviously I did not think Ethernet, either :-). As it has been typical, they will call here once they have run out of other usable options...

I did email you earlier today (nothing worth a second thought if it gets lost).

Interesting. That's an engineer's reply, optimizing before knowing the requirements. We all do that.

Doesn't matter. Larkin isn't going to use either. He's just fishing for someone to do his work for him. He has since said this will involve customer equipment that is on a network, so Ethernet it is!