On Wed, Apr 26, 2023 at 02:25:12PM +0200, Luigi 'Comio' Mantellini wrote: > Having servers on different > nodes will give a drift because there is not any shared clock in this case.
If the nodes had their system clocks synchronized, as would normally be expected, the sync transmissions would not drift. I think it is a desired property of any network protocol to evenly spread the traffic if possible. Imagine a large number of identical PTP servers powered on at the same time. If their sync transmissions were clumped together in a fraction of the interval, I'd not consider it to be working well. > BTW in a scenario you can have just a couple of servers to handle two > domains, and collision is improbable and must not be a problem. > In addition, using periodic timers will permit you to identify easily > missing ticks for scheduling issues. This is very useful during debugging > of your node when your CPU is not dedicated. You can do that without periodic timers too by comparing the difference between last two transmit timestamps to the expected interval. > During test and qualification the SW implementation has been compared with > HW implementations on Telecom grade devices. A warning message has been > reported to me from a customer regarding the TX tolerance. Unless there is a specification requiring such tight timing, I'd consider it a feature, not a bug. 1588-2019 in 9.5.9.2 requires for the timing of sync messages that "the value of the arithmetic mean of the intervals, in seconds, between PTP message transmissions is within ± 30% of the value of 2^portDS.logSyncInterval" and "at least 90% of the inter-message intervals are within ± 30% of the value of 2^portDS.logSyncInterval. The interval between successive PTP messages should not exceed twice the value of 2^portDS.logSyncInterval." Consider what happens when the CPU or network is heavily overloaded. Periodic timer doesn't allow any slippage, so at some point it will skip the transmission. If it's bad enough, the average can get over the 30% limit, while with the current solution the interval can gradually increase with the load and stay within the limits under worse conditions. Instead of trying to make the interval constant I propose add extra randomness, maybe +/- 1%. This seems to be well within the spec. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
