gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] NO_HZ Avoidance


From: Fred Wright
Subject: [gpsd-dev] NO_HZ Avoidance
Date: Thu, 30 Jun 2016 18:25:10 -0700 (PDT)

I see the recently added recommendation to disable NO_HZ on ARM.  This
doesn't make sense when using the KPPS driver to capture the PPS timing
with interrupts, since I really don't see how adding more clock interrupts
is going to improve the accuracy of servicing the PPS interrupts.  Of
course if one is sampling the PPS signal in user code, it's completely
different (and highly dependent on how the user code determines its
timing).

My BBB time server is running with NO_HZ enabled, and it doesn't seem to
adversely affect the PPS timing:

address@hidden:~# zcat /proc/config.gz |grep HZ
CONFIG_NO_HZ=y
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_OMAP_32K_TIMER_HZ=512
CONFIG_HZ=512
address@hidden:~# cat /proc/cmdline
console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait 
fixrtc ip=
address@hidden:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+SHM(0)          .GPSs.           0 l    5    8  377    0.000  101.700   0.263
oPPS(1)          .GPS.            0 l   12   16  377    0.000    0.002   0.004
*time.sr.sonic.n .GPS.            1 u   61   64  377   10.896    0.379   1.345
+usdal2-ntp-002. .GPSs.           1 u   48   64  377   51.777    2.533   0.795
-clockb.ntpjs.or 89.109.251.21    2 u   27   64  367  136.121    4.107   1.300
-www.linas.org   129.250.35.251   3 u   15   64  377   68.779   -4.200   1.400
-66-232-97-8.sta 128.138.141.172  2 u   22   64  377   81.003    0.217   1.106
-1.time.dbsinet. 146.186.222.14   2 u   23   64  377   69.796   -1.480   1.113
address@hidden:~# ppstest /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1467335876.999998825, sequence: 5257356 - clear  0.000000000, 
sequence: 0
source 0 - assert 1467335878.000003692, sequence: 5257357 - clear  0.000000000, 
sequence: 0
source 0 - assert 1467335878.999998058, sequence: 5257358 - clear  0.000000000, 
sequence: 0
source 0 - assert 1467335879.999999423, sequence: 5257359 - clear  0.000000000, 
sequence: 0
source 0 - assert 1467335880.999996578, sequence: 5257360 - clear  0.000000000, 
sequence: 0
source 0 - assert 1467335882.000000441, sequence: 5257361 - clear  0.000000000, 
sequence: 0
^C

I wouldn't expect to do better than that with anything that's at the mercy
of interrupt latency.

Fred Wright



reply via email to

[Prev in Thread] Current Thread [Next in Thread]