Re: Obfusticated data?

I believe it is for security. The remote system does not need this data on the
intial packets. Also, especially the inital packets time data can be way out.
The ntp time protocol looks at the average time of sending and receiving the
packet, and time set back from the remote system when it receives the packet.
It could take the packet 50ms to travel from your system to the server. (eg I
am just pining a server only 3000km away, and it takes 30ms to go one way).
Furhtermore there are random delays. chrony averages the past N packets ( does
a least squares fit to the delays) for N somwhere between 3 and 50., which is
far more accurate than the delay for any one packet. Thus the chrony clock is
at least a factor of 10 ( and sometimes 100) more accurate than the range of
the offsets of single packets. IF you want to make sure that your system is in
spec, then get yourself a gps timing receiver, and use that to synchrnize your
clocks. That will give you a synchronization to UTC better than 1 microsecond,
50000 time more accurate than you need.

The model that your standard seems to be using for time sync looks, from your
description, to be one that that does not understand time standards, and
synchronization.

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ [email protected]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Fri, 30 Sep 2022, Mark Notarus wrote:

> [CAUTION: Non-UBC Email]
> 
>  
> 
> As part of our requirements as a trading business, we need to record a lot of data about timing, and report
> on it if it is out of specification.
> 
>  
> 
> The CAT standard that governs trading companies specifies that we have to log every synchronization event,
> the result, and report if we are more than 50ms out of spec.
> 
>  
> 
> We have been doing that by parsing local logs, which works fine but scales terribly.
> 
>  
> 
> We purchased a grandmaster which among other things uses the self-reported data in PTP and NTP packets from
> all clients, and logs that in a central place, which makes it the perfect place to pull our compliance info
> from.
> 
>  
> 
> While testing, we noticed that Chrony is zeroing out all that data, which means we can’t do that. It
> definitely seems deliberate.
> 
>  
> 
> Even if I disable this code, I find that the reported data in the NTP packets does not seem to match the data
> logged in tracking.log/measurements.log.
> 
>  
> 
> Could someone help me understand the goal of this data deletion? 
> 
>  
> 
>  
> 
> Ntp_core.c , line 1096, codebase 4.3 .
> 
>  
> 
> if (my_mode == MODE_CLIENT) {
> 
>     /* Don't reveal local time or state of the clock in client packets */
> 
>     precision = 32;
> 
>     leap_status = our_stratum = our_ref_id = 0;
> 
>     our_root_delay = our_root_dispersion = 0.0;
> 
>     UTI_ZeroTimespec(&our_ref_time);
> 
>   }
> 
>  
> 
>  
> 
>  
> 
> ------
> 
> Mark Notarus
> 
> Sumo Capital Group – Tech Services team
> 
> 312-548-0718
> 
> [email protected]
> 
>  
> 
> 
>