On 2023-04-17, Ricky <gnuarm.deletethisbit@gmail.com> wrote:> 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.I would use RS485 for a better impedance match and better fan-out. -- Jasen. 🇺🇦 Слава Україні
triggering things with ethernet
Started by ●April 17, 2023
Reply by ●April 18, 20232023-04-18
Reply by ●April 18, 20232023-04-18
On 2023-04-17, John Larkin <jlarkin@highlandSNIPMEtechnology.com> 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.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 -- Jasen. 🇺🇦 Слава Україні
Reply by ●April 18, 20232023-04-18
On 4/18/2023 10:44, Don Y wrote:> 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.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.> > 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!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.> > 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). >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.
Reply by ●April 18, 20232023-04-18
On 17/04/2023 20: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.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. -- Martin Brown
Reply by ●April 18, 20232023-04-18
On 4/18/2023 4:36 AM, Dimiter_Popoff wrote:> On 4/18/2023 10:44, Don Y wrote: >> 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. > > 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.Presumably, there is a "line of code" *somewhere* that starts the process. This code has to get executed and drag all of the subsequent mechanisms in before the "correct" packet gets put on the wire. So, any variability in the execution path (e.g., conditionals, preemption, etc.) appears in series with that "line of code" just as any variability in the receiving (and transport) end would.>> 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! > > 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.Do *you* control all of the devices on the LAN your device occupies? I think it's pretty unlikely that a completely closed system would bother with ethernet for triggers -- why not an optical fiber with a pulsed light source wired to the device in question? (or, a piece of copper, etc.) Ethernet as a generic choice imposes limitations that (if triggering were the sole use) can complicate the design. E.g., with more than two devices on the wire, you need a switch/router. Will you supply that, as well? Will you *qualify* third party switches (how much resources will you devote to this? do you know the switches that your customer is *likely* going to have on hand -- or be willing to purchase JUST for you?) [OTOH, a length of wire -- or optical fiber -- is pretty straightforward] Using something as ubiquitous as ethernet opens the door for connection to devices "made by others". So, *you* don't have to make everything that a customer *might* want to use (with your primary product). [The age of standalone boxes is quickly coming to a close; everything WANTS to talk to everything else!]>> 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). > > 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.See above. [I think mail is hosed, again :< ]
Reply by ●April 18, 20232023-04-18
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.Too bad you can't set them up to do whatever it is at a specified time of day.
Reply by ●April 18, 20232023-04-18
On 4/18/2023 16:08, Don Y wrote:> On 4/18/2023 4:36 AM, Dimiter_Popoff wrote: >> On 4/18/2023 10:44, Don Y wrote: >>> 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. >> >> 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. > > Presumably, there is a "line of code" *somewhere* that starts the > process. This code has to get executed and drag all of the > subsequent mechanisms in before the "correct" packet gets put > on the wire. > > So, any variability in the execution path (e.g., conditionals, > preemption, etc.) appears in series with that "line of code" > just as any variability in the receiving (and transport) end > would.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.> >>> 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! >> >> 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. > > Do *you* control all of the devices on the LAN your device occupies?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 :-).> I think it's pretty unlikely that a completely closed system would > bother with ethernet for triggers -- why not an optical fiber with > a pulsed light source wired to the device in question? (or, a piece of > copper, 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 think mail is hosed, again :< ] >I did email you earlier today (nothing worth a second thought if it gets lost).
Reply by ●April 18, 20232023-04-18
On Tuesday, April 18, 2023 at 7:30:50 AM UTC-4, Jasen Betts wrote:> On 2023-04-17, Ricky <gnuarm.del...@gmail.com> wrote: > > 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. > I would use RS485 for a better impedance match and better fan-out.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! -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
Reply by ●April 18, 20232023-04-18
On Tue, 18 Apr 2023 06:08:26 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 4/18/2023 4:36 AM, Dimiter_Popoff wrote: >> On 4/18/2023 10:44, Don Y wrote: >>> 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. >> >> 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. > >Presumably, there is a "line of code" *somewhere* that starts the >process. This code has to get executed and drag all of the >subsequent mechanisms in before the "correct" packet gets put >on the wire. > >So, any variability in the execution path (e.g., conditionals, >preemption, etc.) appears in series with that "line of code" >just as any variability in the receiving (and transport) end >would. > >>> 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! >> >> 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. > >Do *you* control all of the devices on the LAN your device occupies? >I think it's pretty unlikely that a completely closed system would >bother with ethernet for triggers -- why not an optical fiber with >a pulsed light source wired to the device in question? (or, a piece of >copper, etc.) >Of course we can get picosecond precision in a big time distribution/trigger system using fiber; I've done that. But CAT5 cables are cheap and easy to get installed. My question is, what would time response be like? If I send a UTP broadcast packet to my system, the GO trigger to a dozen boxes, does a switch relay them all in parallel? It's hard to find numbers.>Ethernet as a generic choice imposes limitations that (if triggering >were the sole use) can complicate the design. E.g., with more than >two devices on the wire, you need a switch/router. Will you supply that, >as well? Will you *qualify* third party switches (how much resources will >you devote to this? do you know the switches that your customer is >*likely* going to have on hand -- or be willing to purchase JUST for you?) > >[OTOH, a length of wire -- or optical fiber -- is pretty straightforward] > >Using something as ubiquitous as ethernet opens the door for connection >to devices "made by others". So, *you* don't have to make everything >that a customer *might* want to use (with your primary product). > >[The age of standalone boxes is quickly coming to a close; everything WANTS >to talk to everything else!] > >>> 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). >> >> 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. > >See above. > >[I think mail is hosed, again :< ]
Reply by ●April 18, 20232023-04-18
On Tue, 18 Apr 2023 11:10:30 -0000 (UTC), Jasen Betts <usenet@revmaps.no-ip.org> wrote:>On 2023-04-17, Ricky <gnuarm.deletethisbit@gmail.com> wrote: >> 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. > >I would use RS485 for a better impedance match and better fan-out.Ethernet is universal. Every PC, every laptop, has an Ethernet port. CAT5 cables and switches are cheap and everybody knows how to buy and install them.
