C programming language
Mar 22 2020
Mar 21 2020
Mar 7 2020
Feb 12 2020
Nov 25 2019
Nov 16 2019
Oct 7 2019
An alternative proposal for editing ISNs without involving the kernel:
Apr 5 2019
@Patrick What is the status of integration? Since we have kloak this is also a great defense to have. There is a script on there for packing as a deb:
Aug 7 2018
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.
Aug 6 2018
/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.
Aug 5 2018
Jul 27 2018
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).
Jul 25 2018
the time could be set with timedatectl by feeding it the time with this command:
sclockadj3 is done -> T686.
Jul 3 2017
A miracle has happened. All of https://github.com/yongboy/bindp/pull/6 was merged by upstream.
Very well. So finally they applied our patch.
Jun 16 2017
@Patrick In the master branch the only difference in comparison to the original version that I can see is the main function at the bottom of the file. Did you not apply the changes? This code is still the previous one.
Merged into master.
Jun 15 2017
Jun 14 2017
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.
Jun 8 2017
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
Where is adjtime being used in existing time sync applications? NTP?
Using adjtime would be a simple matter (of programming), but only has microsecond precision.
Jun 7 2017
A popular existing linux tool.
Do we need precise control? The only requirement (other than working) is that it imitate an existing linux tool.
adjtimex/ntp_adjtime looks quite complex, but also allow precise control on how time should be adjusted. From those two, according to manual page ntp_adjtime is preferred.
Jun 6 2017
Jun 5 2017
I've left you some minor comments here: https://github.com/JasonJAyalaP/sclockadj/commit/e9bf84e3a400f7a8ef01e5f00dcefc013d0a9efe
What about using adjtime() syscall instead of all this? It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.