What's new

Setting the clock as early as possible (using local time server)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

cmkelley

Very Senior Member
If you have a local time server on your network, below is a script that can be called from init-start to set your router clock as early as possible in the bootup sequence. Put it in /jffs/scripts and of course make it executable with chmod a+x fetch-ntp
Code:
#!/bin/sh
#
# Script: fetch-ntp
#
# script to get time from time server as quickly as possible
# call from init-start as "/jffs/scripts/fetch-ntp ww.xx.yy.zz cc &"
# where ww.xx.yy.zz is IP address (duh!) and cc is number of cycles to loop
# do not use URL; use IP only so we don't wait for DNS to come up
# `&` at end is critical - spawns this as a separate task and continues

# verify 2 parameters passed, no other error checking
if [ "X$2" = "X" ]; then exit; fi

ntp_ip=$1
cycles=$2
count=$cycles

rm /jffs/timelog.startup
touch /jffs/timelog.startup

while [ $count -gt 0 ]
do
       echo "Cycle #$count:" $(date) >> /jffs/timelog.startup
       sleep 1 # give it a chance to wake up
       count=`expr $count - 1`
       if ping -w 1 -c 1 $ntp_ip > /dev/null 2>&1 # Give me a ping, Vasily. One ping only, please.
       then
               if ntpd -q -n -p $ntp_ip
               then
                       logger -t "SCRIPT_$(basename $0)" "Time synced from $ntp_ip in `expr $cycles - $count` cycles"
                       exit
               else
                       logger -t "SCRIPT_$(basename $0)" "FAILED to sync time from $ntp_ip! (valid ip)"
                       exit
               fi
       fi
done

logger -t "SCRIPT_$(basename $0)" "FAILED to find time server $ntp_ip in $cycles cycles!"
To use, add the following line to your init-start script:
Code:
/jffs/scripts/fetch-ntp IP.OF.YOUR.SERVER count &
Where IP.OF.YOUR.SERVER is the IP of your local NTP sever and "count" is the number of cycles (1 second each) you want it to try before giving up. The '&' at the end is important to spawn it as a separate task. The timelog.startup file is interesting about once or twice to verify it's all working nicely, and then you can delete the relevant lines.

With my system it syncs to my time server on the second try, so 2 seconds after the init-start script runs. On my system, that seems to be about 2-3 seconds before the next script in line, services-start runs, and 4-5 seconds before dnsmasq and wan-start run.
Code:
May  4 22:05:06 kernel: wfd_registerdevice Successfully registered dev wl0.1 ifidx 1 wfd_idx 0
May  4 22:05:06 kernel: Register interface [wl0.1]  MAC: [redacted]
May  4 22:05:06 kernel: wfd_registerdevice Successfully registered dev wl1.1 ifidx 1 wfd_idx 1
May  4 22:05:06 kernel: Register interface [wl1.1]  MAC: [redacted]
Jan 11 10:55:29 SCRIPT_fetch-ntp: Time synced from [redacted] in 2 cycles
Jan 11 10:55:30 avahi-daemon[826]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 11 10:55:31 lldpd[904]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
Jan 11 10:55:31 avahi-daemon[826]: Alias name "RT-AC86U" successfully established.
Jan 11 10:55:32 SCRIPT_services-start: started []
Jan 11 10:55:34 SCRIPT_wan-start: started [0]
Jan 11 10:55:34 dnsmasq[814]: ignoring nameserver [redacted] - local interface
Jan 11 10:55:35 kernel: ubi1: attaching mtd9
My services-start and wan-start scripts actually don't do anything right now except write to logger; leftovers from figuring out the order that scripts run.
Code:
#!/bin/sh

logger -t "SCRIPT_$(basename $0)" "started [$@]"
 
I have to ask the question.... why bother? In my own case the clock might sync 10 seconds earlier.
 
I have to ask the question.... why bother? In my own case the clock might sync 10 seconds earlier.
There's some indication that Stubby is time sensitive and I wanted to put that to bed as definitively as possible. And, well, because I can. :)

I literally bought a Raspberry Pi for the sole purpose of having a GPS-synced time server on my network. Its "error" is generally less than 200 usec (i.e. .0002 sec). Time is part of my nerdom. I realize fully it makes absolutely no difference in the world having a time server that accurate on my own little network, but I think it's cool.
 
Last edited:
With my system it syncs to my time server on the second try, so 2 seconds after the init-start script runs. On my system, that seems to be about 2-3 seconds before the next script in line, services-start runs, and 4-5 seconds before dnsmasq and wan-start run.

Nice little script...

Just be careful with hacking the init... one can run into race conditions which could slow things down, worst case would be the watchdog jumping in and causing problems...
 
Nice little script...

Just be careful with hacking the init... one can run into race conditions which could slow things down, worst case would be the watchdog jumping in and causing problems...
Yeah, that's why the asynchronous fork to span it from init-start. Init should continue merrily, though I don't know for sure that init-start will actually exit while the forked script is running.
 
I literally bought a Raspberry Pi for the sole purpose of having a GPS-synced time server on my network. Its "error" is generally less than 200 usec (i.e. .0002 sec). Time is part of my nerdom. I realize fully it makes absolutely no difference in the world having a time server that accurate on my own little network, but I think it's cool.

Do a search on the forums - there's been work done on ntp, integrating GPS into AsusWRT, and external NTP services via devices like the Pi...

IMHO - ntpd on Pi is good enough for most, but with Pi and Raspbian, one does have some flexibility with time sources..
 
Do a search on the forums - there's been work done on ntp, integrating GPS into AsusWRT, and external NTP services via devices like the Pi...

IMHO - ntpd on Pi is good enough for most, but with Pi and Raspbian, one does have some flexibility with time sources..
Right, that's where I got the idea. I tried to get a GPS that would connect right to the router, but had troubles getting a suitable one. And since a time server is a low-workload thing, I can use the Pi for other things as well if I want. I used this guide and this board for getting it set up and running. For a while I was running @kvic's ntp status scripts but I let that go with the code upgrade to 382/384. I know they have it running on 384 / HND now, but I think next I'm going to try setting up a local webserver on the Pi and get that data right from pi. Plus, I get to learn more!
 
Fun thing - the Pharos 500 devices are easy to come by on the bay of E and the Lists of Craig...

USB based, and the chipset is fully supported by mainstream linux and gspd.... run this on a Pi with ntp, and you've got an excellent time source (and a good location source for war driving if one is into that)

This dongle was included with an old Microsoft Maps application...

81jDxmT9k7L._SX425_.jpg
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top