How to do incremental time leap to avoid data loss

Question

Background : Hi, I am currently working with an old Linux SBC system. It uses BusyBox v1.00-rc2 which is old and had limited functionality. (nope, upgrade is not an option). This SBC was hooked up with several sensor, record the value and time stamped it.

Problem : After several years, the RTC drifted from actual time and some of the SBC delay more than 1hours (slower) from the actual time.

I cannot simply do the ntpdate with the ntp servers because it will cause time jump and causing huge gap on the data monitoring log. It is not acceptable.

Solution: I had created a bash script that will:

1. Check the ntp offset with the SBC and ntp servers
2. Then, record the offset in a variable
3. If the offset value is larger than 7, for example (60sec offset), the script will increase the system clock, little by little using date -s command.
4. It will only increase at maximum 60 seconds every hour
5. Example :
   • SBC time is 14:59:00 4th April 2016
   • Actual time from ntp servers is 15:00:00 4th April 2016
   • If I use ntpdate -q -4 utcnist2.colorado.edu it will return with 60 seconds offset
   • So, my script will only increase 7 seconds every 450 seconds
   • With this logic, SBC time will catchup with ntp time around Apr 4th 16:04:17 2016
   • The problem is, this script manage to slowly adjust the time step by step, BUT sometimes, it will go haywire and the SBC time will be faster compared to the actual time (Ntp time) and this will cause the data loss (server will ot accept if the SBC time is faster than the server time).

Questions :

• Is there any other way to do the incremental time jump similar to this?
• I notice that ntpdate has -B function that will do the incremental time update, but I failed to use this on the SBC. What is the correct method to use this switch? Or I misunterstood it functionality?
• Can adjtimex achieve this purposes?
• Here is my complete bash script if any of you need it (too long to paste here),

http://pasted.co/65beb3db [password : 123456]

Answer 1

I have come to a conclusion regarding to this matters. There are 2 solutions (from my experience. Maybe more. Feel free to add):

Solution 1

• Source : http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html
• Method : Changing the linux tick count and frequency. All calculation can be seen inside the javascript by L.S.Lowe at bham.ac.uk (in the link)
• Example : If I want to speed up the system clock to be 60 seconds faster every hour, I need to change the (tick = 10167) and (frequency = -2184533) and apply it using adjtimex -t 10167 -f -2184533

---

Solution 2 (Which what I am using right now)

• In my question above, I had already mention that I am using old version of busybox which I cannot use many of the latest function such as ps -anySwitch to get the pid of the current running process. Pidof myscript.sh command also did not produce any result.
• So, In my bash script above, I create a function on top of the script so that everytime my script start by cron, which is every 15 minutes, my script will check with the pid that was stored inside a file. If the pid is still running, the new script will terminate itself. This is to avoid multiple script from running every 15 minutes.
• I suspect, there is some flaw with this method. For some reason, the script will run multiple time, and causing the time increment to become faster (since there are multiple script running)
• So, to avoid this suspicion, instead of running the script every 15 minutes, I modified the cron to run another script to check whether my script is running or not.
• I found that if I am launching my script using this method-> ./myScript, i can get the pid number using pidof myscript
• So, it will be much assuring to use this method and avoiding any grey area.
• Until now, it seems that I already solved my problem.
• Launcher Script example:

!/bin/sh

pid=pidof NTP_Update

if [ -n "$pid" ] ; then echo "NTP_Update is running..." else echo "NTP_Update not running..." cd /root/script ./NTP_Update fi

---

Hope this work around method will help anybody that was struggling with old busybox version.