Re: [Ntp] Antw: Re: Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)

[Magnus Danielson <[e-mail]>]

Martin,

On 2021-01-11 11:27, Martin Burnicki wrote:
> Magnus,
>
> Magnus Danielson wrote:
>> On 2021-01-11 08:22, Hal Murray wrote:
>>> if you are using smearing servers you have to be careful to not use any 
>>> non-smearing servers.
>>>
>>> If you are using real/correct (non-smearing) servers, you have to make sure 
>>> you don't use any smearing servers.
>> Which is exactly the division of servers and problem to handle them at
>> client side, as client operation needs to know which servers too choose
>> from. As you create a wider range of server types, all of a sudden you
>> create less servers that we can use for any type of operation.
> Once more I disagree. If you want smearing at the client side, client
> software could be modified to do this right now.
>
> If the client receives a leap second warning from the server, it could
> include apply a smear offset when adjusting the system time, and each
> client had to be individually configured if and how to smear its own
> system time.
>
> The reason for letting the NTP server send smeared time to its clients
> is that you *only* have to configure your server(s) accordingly, and
> *all* NTP clients get the same, smeared time.
The trouble is not technical, but the consequence of what that leads to.
While I agree that there is technical benefits of doing it on the server
side, I also see downsides with doing it that way. The proliferation of
various server time-scales also leads to higher division of servers into
groups for which most clients cannot use outside of any of those groups.
This leads to problem regardless if it is within a dedicated network or
Internet. The users require to know about the different type and
configure the right set. It also makes it difficult to meet different
requirements on the same machine (and today virtual machines). You might
end up having to divide the server farm depending on which time it uses.
That's the path we already face, and I ask the question if this is the
path we want to maintain? I think it would be unwise.
>
>> This is
>> why putting this on the server side is unhelpful for the community. If
>> we have a common NTP core time and then map that out to whatever format
>> the client need, we can have a common set of of servers, serving a wide
>> range of clients need together.
> Of course you can run into a mess if you use smearing and non-smearing
> servers at the same time.
>
> However, admins who have to take care how the clients behave just need
> to select a few appropriate servers for their clients instead of having
> to check that each client supports smearing at the client side in the
> same way. If you have a huge number of different clients, the effort is
> probably much higher and more error prone than just having to select a
> few servers.

This is a scalability issue for sure. That's exactly my point. In the
end, the configuration of the clients needs to consider this regardless.
So the question is how we make this work out as we scale up.

In the ideal world, the OS would provide multitude of time-scales and
applications would use the appropriate for their need and the timing
structure supports them all. We are for sure not there yet, but I think
we should consider how we create needed support to get there, at least
if you want.

Cheers,
Magnus