1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

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

Discussion in 'Asuswrt-Merlin' started by cmkelley, Jan 11, 2019.

Tags:
  1. cmkelley

    cmkelley Very Senior Member

    Joined:
    Aug 11, 2015
    Messages:
    809
    Location:
    Greater Los Angeles Area, California, USizicstania
    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 [[email protected]]"
    
     
    amplatfus and JDB like this.
  2. dave14305

    dave14305 Very Senior Member

    Joined:
    May 19, 2018
    Messages:
    760
    :D
     
    cmkelley and Dave Parker like this.
  3. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    8,552
    Location:
    UK
    I have to ask the question.... why bother? In my own case the clock might sync 10 seconds earlier.
     
    eddiez likes this.
  4. cmkelley

    cmkelley Very Senior Member

    Joined:
    Aug 11, 2015
    Messages:
    809
    Location:
    Greater Los Angeles Area, California, USizicstania
    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: Jan 11, 2019
  5. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    14,025
    Location:
    San Diego, CA
    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...
     
  6. cmkelley

    cmkelley Very Senior Member

    Joined:
    Aug 11, 2015
    Messages:
    809
    Location:
    Greater Los Angeles Area, California, USizicstania
    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.
     
  7. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    14,025
    Location:
    San Diego, CA
    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..
     
  8. cmkelley

    cmkelley Very Senior Member

    Joined:
    Aug 11, 2015
    Messages:
    809
    Location:
    Greater Los Angeles Area, California, USizicstania
    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!
     
    heysoundude likes this.
  9. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    14,025
    Location:
    San Diego, CA
    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
     
    cmkelley likes this.