What's new

NTP Daemon for ASUSWRT/Merlin

  • 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!

Here's my patch file for the Asuswrt-Merlin 380.57 Linux kernel for ARM routers. It enables the USB-to-serial drivers: FTDI, CH341 and PL2303. And it disables the GSM modem driver. It also enables the kernel for use with NTPd and PPS over USB.

asuswrt-merlin-380.57-usbtimepps-arm.patch
Thanks Asat. I had setup a build environment a year or so ago. I will dust it off and try this out.
I just ordered an RS-232 to USB cable that uses the FTDI chipset (and claims to support PPS over DCD). I need to do some soldering over the next few days!

In the mean time, I have moved the GPS 18X over to my Asuswrt-Merlin Coprocessor (Banana Pi) and it is happily getting a nice steady GPS time.
 
Thanks to Asat, I have recompiled the 380.57 firmware for the RT-AC88U with the patches he provided. I then took the Garmin 18X GPS puck connected to an FTDI based RS-232 to USB cable and plugged into the USB 2.0 port.
A few quick modprobes to enable the USB SIO cable and voila. Both GPS and PPS timing information being fed to Kvics ntpd.
Results after running for a day - nice clean offset, jitter is a bit crazy, but I have the GPS puck sitting on a ledge with a skylight as it's main source to the sky. Not bad really, thanks Kvic and Asat!
And thanks as well to Ryzhov and Zyxmon for adding gpsd to Entware-ng.

stats-ntp-offset.png
stats-week-ntp-offset.png
 
I have recompiled the 380.57 firmware for the RT-AC88U with the patches he provided.
If your PPS is working properly you will typically see a microseconds scale on the chart, not a milliseconds scale. A "u" is microseconds and "m" is milliseconds. Check /tmp/syslog.log for PPS issues related to NTPD.
 
Last edited:
If your PPS is working properly you will typically see a microseconds range on the chart, not a milliseconds range. A "u" is microseconds and "m" is milliseconds. Check /tmp/syslog.log for PPS issues related to NTPD.

Thanks ASAT, I will look. I am having a problem where periodically gpsd looses connection with the Garmin 18X. Even minicom on the port ttyUSB0 doesn't show any data.
I am going through the process of determining if is it the Garmin device or the RS-232 to USB cable or a configuration issue. I have the baud rate at 38400. I am going to step down a notch and see if it is more stable.
 
I am going through the process of determining if is it the Garmin device or the RS-232 to USB cable or a configuration issue.

I would try 9600 baud, or whatever is the default for the Garmin device. Then type 'cat /dev/ttyUSB0'. If you don't see any NEMA sentences, the problem could be the Garmin device. If you do see NEMA sentences, then you may use the Garmin proprietary commands to turn off all NEMA sentences other than the one that has the current date/time.

Here's how I start up NTPD.

/jffs/scripts/services-start
Code:
set_ntp_ready()
{
  /usr/bin/killall ntp
  /bin/sleep 1
  /usr/sbin/nvram set ntp_ready=$1
  /usr/sbin/nvram unset ntp_server0
  /usr/sbin/nvram unset ntp_server1
  /usr/sbin/nvram unset ntp_server_tried
  #/usr/sbin/nvram commit
}

set_ntp_ready 0

# create some folders used by ntpd, otherwise it don't work
/bin/mkdir -p /tmp/etc/ntp
/bin/mkdir -p /tmp/var/spool/ntp

# initialize ntpd
if [ ! -e /dev/ttyUSB0 ]; then
  /sbin/lsmod | /bin/grep -e "ftdi_sio" > /dev/null 2>&1 || /sbin/modprobe ftdi_sio
  /sbin/lsmod | /bin/grep -e "pps_core" > /dev/null 2>&1 || /sbin/ modprobe pps_core
  /sbin/lsmod | /bin/grep -e "pps_ldisc" > /dev/null 2>&1 || /sbin/modprobe pps-ldisc

  N=1
  while [ $N -lt 30 ]; do
    if [ -e /dev/ttyUSB0 ]; then
      /jffs/bin/setserial /dev/ttyUSB0 low_latency
      LDATTACH_CMD="/jffs/bin/ldattach pps /dev/ttyUSB0"
      LDATTACH_PID=$(/bin/echo $(/bin/ps w | /bin/grep -i "$LDATTACH_CMD" | /bin/grep -v grep) | /usr/bin/cut -f1 -d' ')
      [ -z "$LDATTACH_PID" ] && $LDATTACH_CMD
      [ -e /dev/gps0 ] || ln -s /dev/ttyUSB0 /dev/gps0
      [ -e /dev/gpspps0 ] || ln -s /dev/pps0 /dev/gpspps0

      # block here while the router's clock is sync'd with a GPS time source
      /usr/bin/logger -t $(/usr/bin/basename $0) "custom script attempting system clock synchronization [$$]"
      /jffs/bin/ntpd -d -d -d -d -d -g -q -n -c /jffs/ntp/ntp.conf  # set clock and quit
      /usr/bin/logger -t $(/usr/bin/basename $0) "custom script completed system clock synchronization [$$]"
      set_ntp_ready 1

      break
    else
      let N++
      /bin/sleep 1
    fi
  done
fi

# start ntpd as an unstoppable daemon and carry on
if [ "$(/usr/sbin/nvram get ntp_ready)" == "1" ]; then
  /jffs/bin/ntpd -c /jffs/ntp/ntp.conf
fi
 
I would try 9600 baud, or whatever is the default for the Garmin device. Then type 'cat /dev/ttyUSB0'. If you don't see any NEMA sentences, the problem could be the Garmin device. If you do see NEMA sentences, then you may use the Garmin proprietary commands to turn off all NEMA sentences other than the one that has the current date/time.

Here's how I start up NTPD.
Thanks ASAT, I will give that a try - both reducing the baud rate and your script.
BTW, which sentences do you allow?

Thanks
 
which sentences do you allow?
Mines is configured to send only NEMA sentence $GPZDA. Example:
Code:
$GPZDA,122235.00,13,01,2016,00,00*65

Maybe you do not need GPSD at all? The Garmin device should be set to output standard NEMA sentences to /dev/ttyUSB0. Then you tell NTPD how to configure the serial port through the server 'mode' byte in ntp.conf. My server 'mode' byte is set to 24, which means "9600 baud + only $GxZDA for time message". Then, you specify a server fudge 'flag' byte to configure the PPS input. It is documented here: http://doc.ntp.org/4.2.8/drivers/driver20.html


ntp.conf
Code:
...
# Generic NMEA GPS Receiver
#  mode is 9600 baud + only $GxZDA for time messages
#  /dev/gps0 for NEMA
#  /dev/gpspps0 for PPS
#  http://doc.ntp.org/4.2.8/drivers/driver20.html
server 127.127.20.0 mode 24 minpoll 4 prefer
fudge 127.127.20.0 flag1 1 # Enable PPS signal processing
fudge 127.127.20.0 flag2 0 # Capture the pulse on the rising edge
fudge 127.127.20.0 flag3 1 # Use the kernel discipline
fudge 127.127.20.0 flag4 1 # Obscures location in timecode


http://doc.ntp.org/4.2.8/drivers/driver20.html
...
The 'mode' byte

Specific GPS sentences and bitrates may be selected by setting bits of the 'mode' in the server configuration line:
server 127.127.20.x mode X
mode byte bits and bit groups Bit Decimal Hex Meaning
0 1 1 process $GPMRC
1 2 2 process $GPGGA
2 4 4 process $GPGLL
3 8 8 process $GPZDA or $GPZDG
4-6 0 0 linespeed 4800 bps
16 0x10 linespeed 9600 bps
32 0x20 linespeed 19200 bps
48 0x30 linespeed 38400 bps
64 0x40 linespeed 57600 bps
80 0x50 linespeed 115200 bps
7 128 0x80 Write the sub-second fraction of the receive time stamp to the clockstat file for all recognised NMEA sentences. This can be used to get a useful value for fudge time2.
Caveat: This will fill your clockstat file rather fast. Use it only temporarily to get the numbers for the NMEA sentence of your choice.
8 256 0x100 process $PGRMF
9-15 0xFE00 reserved - leave 0
16 65536 0x10000 Append extra statistics to the clockstats line. Details below.

The default (mode 0) is to process all supported sentences at a linespeed of 4800 bps, which results in the first one received and recognised in each cycle being used. If only specific sentences should be recognised, then the mode byte must be chosen to enable only the selected ones. Multiple sentences may be selected by adding their mode bit values, but of those enabled still only the first received sentence in a cycle will be used. Using more than one sentence per cycle is impossible, because there is only fudge time2 available to compensate for transmission delays but every sentence would need a different one and using more than one sentence per cycle overstuffs the internal data filters. The driver uses 4800 bits per second by default, but faster bitrates can be selected using bits 4 to 6 of the mode field.

Caveat: Using higher line speeds does not necessarily increase the precision of the timing device. Higher line speeds are not necessarily helpful for the NMEA driver, either. They can be used to accomodate for an amount of data that does not fit into a 1-second cycle at 4800 bps, but high-speed high-volume NMEA data is likely to cause trouble with the serial line driver since NMEA supports no protocol handshake. Any device that is exclusively used for time synchronisation purposes should be configured to transmit the relevant data only, e.g. one $GPRMC or $GPZDA per second, at a linespeed of 4800 bps or 9600 bps.
 
Last edited:
@kvic I got a few questions for you:

1. Is it possible to achieve microsecond time without a GPS ?

2. After a few weeks, I notice offsets jumps up to about 100ms and the back down to the normal (for me) 2-3ms. It ping pongs like this until I restart the ntpd service. Is this normal?

3. Any list of recommended ntp servers? Is it simply a matter of selecting the closest ones to your location?

Thanks in advance.
 
@kvic I got a few questions for you:

1. Is it possible to achieve microsecond time without a GPS ?

Very unlikely in a home environment I believe. The best I've seen on my router is hundreds of micro seconds.

2. After a few weeks, I notice offsets jumps up to about 100ms and the back down to the normal (for me) 2-3ms. It ping pongs like this until I restart the ntpd service. Is this normal?

When spikes in offset happen, most likely you'll see huge jitters too. Perhaps your router was very busy with other network traffic at those moments. You can smooth out by giving priority to NTP packet in traditional QoS.

If you're using Adaptive QoS, I actually don't know how to set that nor we can be sure it actually honours NTP packets. But one thing you can do is to leave enough head room for your maximum throughput. If you have 100Mbit/s up/down, maybe set it to 95% or even 90%. That works well for my NTP daemon.

And don't worry about you're wasting 5% or 10% bandwidth by letting it idle. From my observation, TrendMicro's adaptive QoS always overshoot.

3. Any list of recommended ntp servers? Is it simply a matter of selecting the closest ones to your location?

Shall give preference to time servers close to you i.e with short network latency. You can do a ping to check. Even stratum two or three severs are fine if they give you much better latency. If you could find strata one servers near you, of course that's best.

You can check a strata one server near you from here: http://support.ntp.org/bin/view/Servers/StratumOneTimeServers
[/QUOTE]

Attached is the past 7 days of my NTP daemon:
ntp.png
 
New minimal NTP binaries
  • updated to ntp-4.2.8p7
  • compiled in support for IPv6
    • great to use IPv6 servers near you when they're mostly sitting idle!
Download ntpd_stats-BIN.zip from here: https://github.com/kvic-z/goodies-asuswrt
  • pick the right binaries for arm or mips, rename and overwrite your existing copies
  • ensure still with execute permission afterward (apply chmod a+x ntp* if necessary)
(ntpd.SHM.arm in the ZIP has SHM driver compiled in for using with some GPS hardware. Mostly ppl don't need this one although it won't harm you except consuming a few more kB of RAM.)

Not sure what's tuned in 4.2.8p7 or perhaps just coincidence. Here is my past 24 hour charts. I like the stability of how the curves move. Volatility in offset looks much narrower than before..

Best of all I haven't seen outrageous spikes yet. Will see how it goes in the coming week.

stats-ntp-offset.png
stats-ntp-sysjit.png
 
Best of all I haven't seen outrageous spikes yet. Will see how it goes in the coming week.

All honesty, it shouldn't be swinging about that much - but this is a PLL likely, so it'll drift a bit (HW).... what would be interesting is to chart it against CPU load and Temp... rrdtool is fun ;)
 
All honesty, it shouldn't be swinging about that much - but this is a PLL likely, so it'll drift a bit (HW).... what would be interesting is to chart it against CPU load and Temp... rrdtool is fun ;)

rrdtool is fun indeed. Note that the unit for offset chart is micro-second. The variation within 1000 micro-second (without GPS hardware) looks pretty good IMO.

The chart is trending upward as we can see below. Clearly the algorithm has been continuously adjusting the system clock toward zero offset. Very likely it'll overshoot in the next 24 hours..then starts trending downward.

Some kind of sinusoidal movement in the bigger waves pleases me. Only hope stock ticks like this..

stats-ntp-offset.png


I saw there was a 'package" for graphing CPU and a few other variables...haven't tried.
 
I am having trouble getting this to work.
I am using RT-N66U on Merlin 378.56_2.
When I execute the command: /opt/etc/init.d/S77ntpd-custom start
It returns "failed"
The system log shows this:
Jun 5 21:17:56 ntpd[8412]: ntpd 4.2.8p4@1.3265 Fri Jan 1 10:34:19 UTC 2016 (8): Starting
Jun 5 21:17:56 ntpd[8412]: Command line: ntpd -c /jffs/etc/ntp.conf
Jun 5 21:17:56 ntpd[8413]: systime.c:109: INSIST(sys_fuzz >= 0) failed
Jun 5 21:17:56 ntpd[8413]: exiting (due to assertion failure)

Any ideas?
 
ntpd fails the assertion here: https://github.com/ntp-project/ntp/blob/stable/libntp/systime.c#L111

Don't know why...can you try with the newer binary from #71?

Probably would be better if we regularly write a time value into a location in NVRAM/JFFS somewhere, and grab that at boot before ntp has a chance to update -

this is a back to the future bug and the delta between system time (at boot) and real time is larger than the double... hence the assert...
 

Latest threads

Sign Up For SNBForums Daily Digest

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