[chrony-dev] Poor way to fix Y2038 on linux

[Mirek sic <mirek@xxxxxx>]

Hello chrony-dev,

We want to make some workaround of Y2038 problem.

Imagine some embedded system (EmbdSys) with a kernel not supporting Y2038.

On this EmbdSys is working user process (UP) that need to have be 
synchronized to NTP server and be Y2038 resistant. User process is using 
time64.c function set to handle dates over Y2038.

We decided to set the system clock back 28 years from the network NTP 
clock. 28 years offset preserves calendar in that margins that we need.

We do this with modified ntpdate tool.

Fix in ntpdate is very trivial but do the work:

clock_filter()  // determine a server's delay, dispersion and offset

......

y2038_offset = 883612800

memcpy(&off_recalc, &server->offset, 4);
off_recalc -= y2038_offset;
memcpy(&server->offset, &off_recalc, 4);

....

But ntpdate need to be called from some crone task periodically to keep 
local clock in sync as good as possible. But when crystal is not very 
stable we have got a big jitter. which not satisfy us.

When we run chrony inplace of ntpdate jitter is small and acceptable but 
not Y2038 resistant.

After this big into. I want to ask for advice how to modify chrony to 
use the same offset in system time like in ntpdate case?

How do you rate the required workload for this task?

And finally where are the places in source need to be modified?

Regards Mirek



--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.