triggering things with ethernet...

[John Larkin]

Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

 

[Dimiter_Popoff]

On 4/17/2023 22:18, John Larkin wrote:

Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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.

 

[John Walliker]

On Monday, 17 April 2023 at 20:45:09 UTC+1, Dimiter_Popoff wrote:

On 4/17/2023 22:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

 

[John Walliker]

On Monday, 17 April 2023 at 22:40:47 UTC+1, John Walliker wrote:

On Monday, 17 April 2023 at 20:45:09 UTC+1, Dimiter_Popoff wrote:
On 4/17/2023 22:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

 

[Ricky]

On Monday, April 17, 2023 at 3:18:59 PM UTC-4, John Larkin wrote:

Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Klaus Vestergaard Kragelund]

On 17-04-2023 21:18, John Larkin wrote:

Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

 

[Klaus Vestergaard Kragelund]

On 18-04-2023 01:38, Klaus Vestergaard Kragelund wrote:

On 17-04-2023 21:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

https://www.cisco.com/c/dam/en/us/solutions/collateral/industry-solutions/white-paper-c11-738950.pdf

 

[Lasse Langwadt Christensen]

tirsdag den 18. april 2023 kl. 01.38.12 UTC+2 skrev Klaus Vestergaard Kragelund:

On 17-04-2023 21:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

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

 

[Don Y]

On 4/17/2023 5:09 PM, Lasse Langwadt Christensen wrote:

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

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

What are the reference points? If you\'re looking at a line of code
to another (remote) \"virtual\" line of code, then you have to look
at: the time involved in processing that line of code (e.g., calling
a function to put a SPECIFIC packet on the wire); the time down through
the stack (esp if you\'ve not developed your *own* stack -- is this
quantified, ANYWHERE?); the competing tasks (for CPU as well as the
packet scheduling algorithm in the stack); the mechanism by which the
packet is passed to the NIC (output need not be ISR driven; input
*should*); any processing *in* the NIC (NICs are increasingly more
like dedicated CPUs); the physical distance to the switch or router
(~speed of light); any queuing in the switch/router (influenced by
other traffic in the fabric); transport to the target; processing
in the receiving NIC; ISR latency and jitter; time to percolate *up*
the receiving stack; etc.

And, the possibility that the packet can simply \"get lost\" or
corrupted (delivery isn\'t guaranteed -- let alone *timely* delivery).

There\'s a reason timing protocols have been developed.

The other insidious issue is that folks always think they can *extend*
a communications network -- whether it\'s tacking another 50 ft of
cable onto an \"RS-232\" cable or using 300 ft of wire to connect your
node to the switch or replacing copper with a km of fiber or dropping
another switch in to act as a repeater or... (ripe for DK)

\"Protocols\" try to address these sorts of things!

 

[John Larkin]

On Tue, 18 Apr 2023 01:39:18 +0200, Klaus Vestergaard Kragelund
<klauskvik@hotmail.com> wrote:

On 18-04-2023 01:38, Klaus Vestergaard Kragelund wrote:
On 17-04-2023 21:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

https://www.cisco.com/c/dam/en/us/solutions/collateral/industry-solutions/white-paper-c11-738950.pdf

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.

 

[Don Y]

On 4/17/2023 2:40 PM, John Walliker wrote:

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

That doesn\'t follow. The delay to any outgoing port will be governed
by the traffic flowing *to* that port/device. So, for a set of N ports
(each with different traffic queued), one port may be \"ready\" presently
while each of the others can be in varying state of transmitting
packets.

Note, also, that the switch only sets the *upper* bound for throughput;
if nodes have negotiated (deliberately or because of, e.g., duplexing
issues) lower rates, that will further limit the throughput TO THAT
NODE.

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

 

[Joe Gwinn]

On Mon, 17 Apr 2023 17:49:33 -0700, John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote:

On Tue, 18 Apr 2023 01:39:18 +0200, Klaus Vestergaard Kragelund
klauskvik@hotmail.com> wrote:

On 18-04-2023 01:38, Klaus Vestergaard Kragelund wrote:
On 17-04-2023 21:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

https://www.cisco.com/c/dam/en/us/solutions/collateral/industry-solutions/white-paper-c11-738950.pdf

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 .

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.

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.

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

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.

Modern network switches are typically far faster than RHEL.

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.

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

Joe Gwinn

 

[John Larkin]

On Mon, 17 Apr 2023 21:38:52 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:

On Mon, 17 Apr 2023 17:49:33 -0700, John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote:

On Tue, 18 Apr 2023 01:39:18 +0200, Klaus Vestergaard Kragelund
klauskvik@hotmail.com> wrote:

On 18-04-2023 01:38, Klaus Vestergaard Kragelund wrote:
On 17-04-2023 21:18, John Larkin wrote:


Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

https://www.cisco.com/c/dam/en/us/solutions/collateral/industry-solutions/white-paper-c11-738950.pdf

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 .

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.

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.

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.


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.

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


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.

Modern network switches are typically far faster than RHEL.

I want numbers!

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.

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

Joe Gwinn

 

[Don Y]

On 4/17/2023 6:38 PM, Joe Gwinn wrote:

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

PTP, itself, does nothing to eliminate the instantaneous variabilities;
it is intended to be used to discipline a local clock (with filtering
above the packet level).

One *could* use 1588 *hardware* to try to quantify the instantaneous
arrival times of packets. But, you\'d still not be sure when YOUR
packet arrived relative to other (broadcast) packets arriving at your
peers.

I.e., you still need *a* protocol built atop that.

 

[Carl]

On 4/17/23 22:26, John Larkin wrote:
> 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.

--
Regards,
Carl

 

[Dave Platt]

In article <u1l0ur$3cn42$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

On 4/17/2023 6:38 PM, Joe Gwinn wrote:
It\'s been done, many times. Guilty. But PTP over ethernet is
sweeping all that stuff away.

PTP, itself, does nothing to eliminate the instantaneous variabilities;
it is intended to be used to discipline a local clock (with filtering
above the packet level).

One *could* use 1588 *hardware* to try to quantify the instantaneous
arrival times of packets. But, you\'d still not be sure when YOUR
packet arrived relative to other (broadcast) packets arriving at your
peers.

I.e., you still need *a* protocol built atop that.

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.

 

[Don Y]

On 4/17/2023 10:15 PM, Dave Platt wrote:

In article <u1l0ur$3cn42$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
On 4/17/2023 6:38 PM, Joe Gwinn wrote:
It\'s been done, many times. Guilty. But PTP over ethernet is
sweeping all that stuff away.

PTP, itself, does nothing to eliminate the instantaneous variabilities;
it is intended to be used to discipline a local clock (with filtering
above the packet level).

One *could* use 1588 *hardware* to try to quantify the instantaneous
arrival times of packets. But, you\'d still not be sure when YOUR
packet arrived relative to other (broadcast) packets arriving at your
peers.

I.e., you still need *a* protocol built atop that.

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.

And, that they *acknowledge* it (e.g., TCP or a bastardized UDP-based
protocol).

Just because you mailed 235 invitations to your wedding -- much in advance
of the actual appointed time -- doesn\'t mean that everyone actually *received*
them!

> Each device sets a timer when it receives the packet.

s/timer/alarm/... you want the future event to happen at time \'X\' not
necessarily \"some time units from now\". I.e., any changes that the time
protocol makes to the notion of current time should affect the point
*in* time that you\'ve called \'X\'.

(timers measure *relative* time so 1 minute from now is \"1 minute from now\",
not current_time+1minute -- because current_time is an arbitrary reference
that the protocol will manipulate)

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.

I can use PTP-ish protocols to synchronize *my* \"clocks\" to << 1us -- without
1588 hardware. But, I can only do that because I have complete control over
ALL the hardware/software AND traffic. The jitter between synchronization
events/messages falls out of the equation because higher protocol levels
cause it to do so. The fact that a message may take 100us to transit (while
another takes 1us) is removed from the calculus.

You still have to sort out what happens when things lose sync or messages
get lost. If Penny doesn\'t make it to the wedding because her invitation
got lost...

The trivial days of \"RS-style\" serial protocols (worst-case analysis on the
back of a napkin) are long past.

Remember, most protocols are designed to share *information*, not *timing*.

 

[Don Y]

On 4/17/2023 12:44 PM, Dimiter_Popoff wrote:

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

Remember, the switch isn\'t a wire. Instead, it can be seen as a buffer
upstream of each port. So, if port 4 is busy delivering a packet to it\'s
client (from port 7, e.g.) but port 3 is idle (because no one loves him!),
then a message intended for port 3 will be delivered before a message
(possibly the same BROADCAST message) will be delivered to port 4.

Depending on the switch architecture, a backlog at switch 4 may cause the
\"next\" message intended for it to be dropped, *in* the switch -- while
port 3 manages to receive it.

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.

10Base2/5 preferable to <any>BaseT (*wire* instead of hub/switch).

But, even there, you have differences in the PHYs/NICs, stack, etc.
that add to the variability.

If you don\'t control the hardware *and* software in each node, you\'re
just pissing in the wind and hoping not to get wet!

So, you have to resort to standards\' compliance and figure out how to
get the performance you want/need *in* that framework (and, then,
insist that everything you talk to is compliant).

 

[Arie de Muijnck]

On 2023-04-17 21:18, John Larkin wrote:

Suppose one were to send a broadcast packet from a PC to multiple
boxes over regular 100 Mbit ethernet, without any fancy time protocols
like PTP or anything. Each box would accept the packet as a trigger.
Assume a pretty small private network and a reasonable number of
switches to fan out to many boxes.

Any guess as to how much the effective time trigger to various boxes
would skew? I\'ve seen one esimate of 125 usec, for cameras, with
details unclear.

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

 

[Jan Panteltje]

On a sunny day (Mon, 17 Apr 2023 22:15:44 -0700) it happened
dplatt@coop.radagast.org (Dave Platt) wrote in
<0ll1hj-m4kn2.ln1@coop.radagast.org>:

In article <u1l0ur$3cn42$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
On 4/17/2023 6:38 PM, Joe Gwinn wrote:
It\'s been done, many times. Guilty. But PTP over ethernet is
sweeping all that stuff away.

PTP, itself, does nothing to eliminate the instantaneous variabilities;
it is intended to be used to discipline a local clock (with filtering
above the packet level).

One *could* use 1588 *hardware* to try to quantify the instantaneous
arrival times of packets. But, you\'d still not be sure when YOUR
packet arrived relative to other (broadcast) packets arriving at your
peers.

I.e., you still need *a* protocol built atop that.

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.

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:
https://panteltje.nl/panteltje/pic/ethernet_color_pic/index.html

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.
https://panteltje.nl/panteltje/xpequ/index.html