Electronics-Related.com
Forums

triggering things with ethernet

Started by John Larkin April 17, 2023

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.