triggering things with ethernet

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.

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.

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

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

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

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

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

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 

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!

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.