https://www.kicksecure.com/wiki/Dev/sdwdate#chrony_as_a_replacement_for_sclockadj

Actually, the "apt-daily.timer: Adding 1h 17min 24.927437s random time" message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).

In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.

And then configure NTP to connect only to that local NTP server.

/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.

Yes, not readily accessible from command line.

The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.

From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.

In T815#16509, @HulaHoop wrote:

It doesn't seem that timedatectl supports gradual time adjustment.

Since we are interested in ntpd's default behavior (for blending in purposes) it turns out that it performs instant clock jumps once the delta difference is excessively large otherwise its slewing algorithm would take forever to adjust the time.

It doesn't seem that timedatectl supports gradual time adjustment. Our next best option is ntpd which can do so but cannot coexist with timedatectl - we can only run either but not both. According to popcon, ntpd is the mos widely used time daemon so its the natural choice.

Currently time is set using gnu date (clock jump) (initial run after current boot) or sclockadj (consecutive run) (slow clock adjustment).

the time could be set with timedatectl by feeding it the time with this command:

Stretch+ uses systemd-timesyncd by default therefore its the most popular.

This is sorted in a later version of systemd.

sclockadj3 is done -> T686.

Qubes-Whonix DispVMs won't get any more development attention in Qubes
R3.2 because so much has changed. Please look into Qubes R4.

I didn't notice this bug earlier but caught a reference in one of the Qubes mailing list discussions. For what it's worth, I got this to function under Qubes 3.2 by deleting the sdwdate systemd unit files. It has been a while but I think I did that in the whonix-ws template. The dispvm appears to call bootclockrandomization on every start so time correlation is avoided and I no longer encounter times off by 2+ weeks.

Unless someone else will be taking this one...

Yes to both of you:

• should just work on Qubes 4.0 (savefiles are not used there anymore)
• calling qubes.GetRandomizedTime as post-suspend action would fix that too

This does not seem to happen every time, strangely enough. It seems sdwdate should call qubes.GetRandomizedTime as a post-suspend action if I read this correctly. So I guess under some circumstances that step does not run.

@marmarek this is probably due to Qubes current DispVM savefile implementation? It should fix itself in Qubes R4.0 since DispVM implementation changed there?

For now, I remain positive this can and should be sorted out for Whonix 14.

Removing Whonix 14 tag. It's not necessary to block 14.

In T691#13739, @JasonJAyalaP wrote:

http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

@Patrick 
is it working for you?

When ntp needs to adjust more than 128ms, it uses settimeofday to make one big jump.

@Patrick
is it working for you?

s.sh (ssh):

s.sh added a comment.

Is there a way to use functions like clock_settime without
reporting to the log

There are generally three ways:

1. Hook into the related library call and prevent the syscall

function from being called. 2. Immediately after writing to system
logs following a call to clock_settime() make the appended logs
removed. 3. During the time of calling clock_settime(), disable the
syslog at system level, after returning from the aforementioned
function re-enable logging.

Is there a way to use functions like clock_settime without reporting to the log

Please create a new ticket for porting to some better C function.

adjtimex, as far as I can tell, is for tuning the clock to stay accurate. It's not directly for setting a new time. I assume it's used by ntp to speed up and slow down the clock, with more code that checks on it and stops it when it reaches the right time. Reimplementing this is beyond my skill.

OK. It might strain my limited C knowledge, but I'll give it shot.

Looks like at least NTP and chrony use ntp_adjtime/adjtimex