Re: [ntp:questions] step and stepout
On 2013-06-28, Orna Sumszyk orna.sums...@gmail.com wrote: I write in my ntp.conf file: tinker step 0.01 stepout 1 David Woolley replied that it seems I do not want an accurate time but a low offset... Not really, but I may misunderstand something in the NTP concept... I only have one NTP server and it is a stratum 0 server in a private network. I really need to be less than 10 msec from server time, and if I am above, I prefer stepping to the time server to immediately adjust my time than slewing and waiting until I get to the server time. Do I have something wrong in my NTP understanding? Yes. Let ntpd do what it does. If you are having trouble with your system being within 10ms, find out why, do not try to bugger up ntpd. ntpd will take a while (hours) to settle down but after that it should certainly track better than 10ms. Some possibilities if not-- you are using carrier pidgeons rather than ethernet to exchange packets (or your ethernet is seriously deficient). You are trying to keep virtual machines on time You are using Windows. What should I better do? Thank you! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] pps coming in, not received by ntpd
Hi,
Something odd is happening.
I've connected a garmin 18 lvc to a pc.
The system has a kernel with pps support and i verified it comes in:
root@hoei:/home/folkert# cat /sys/devices/virtual/pps/pps0/{assert,clear}
1372528130.997131540#54
1372528131.097120120#54
I'm running gpsd and it says the gps has a fix and it also has all
appropriate devices open:
gpsd 27762 nobody7u CHR 4,65 0t0
1144 /dev/ttyS1
gpsd 27762 nobody9r CHR 251,0 0t0
82440 /dev/pps0
gps is started with '-n'
ntpd is configurated to listen to the shared memory segments:
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid NMEA
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPS
Both nptd and gpsd look at the first 2 segments:
-- Shared Memory Segments
keyshmid owner perms bytes nattch status
0x4e545030 0 root 60096 2
0x4e545031 32769 root 60096 2
0x4e545032 65538 root 66696 1
0x4e545033 98307 root 66696 1
0x47505344 131076 root 6668240 1
The PPS seems to be seen by gpsd:
root@hoei:/home/folkert# strace -fp 27872 21 | grep ioctl
...
[pid 27873] ioctl(9, PPS_FETCH, 0x7f1e63cc9d00) = 0
and the NMEA sentences are processed correctly:
x127.127.28.0.NMEA. 0 l 10 16 3770.000 -275.55 4.421
but the pps isn't:
127.127.28.1.PPS.0 l- 1600.0000.000 0.000
Anyone any idea?
Folkert van Heusden
--
Curious about the inner workings of your car? Then check O2OO: it'll
tell you all that there is to know about your car's engine!
http://www.vanheusden.com/O2OO/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] pps coming in, not received by ntpd
On 29/06/2013 18:57, folkert wrote:
Hi,
Something odd is happening.
I've connected a garmin 18 lvc to a pc.
The system has a kernel with pps support and i verified it comes in:
root@hoei:/home/folkert# cat /sys/devices/virtual/pps/pps0/{assert,clear}
1372528130.997131540#54
1372528131.097120120#54
I'm running gpsd and it says the gps has a fix and it also has all
appropriate devices open:
gpsd 27762 nobody7u CHR 4,65 0t0
1144 /dev/ttyS1
gpsd 27762 nobody9r CHR 251,0 0t0
82440 /dev/pps0
gps is started with '-n'
ntpd is configurated to listen to the shared memory segments:
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid NMEA
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPS
Both nptd and gpsd look at the first 2 segments:
-- Shared Memory Segments
keyshmid owner perms bytes nattch status
0x4e545030 0 root 60096 2
0x4e545031 32769 root 60096 2
0x4e545032 65538 root 66696 1
0x4e545033 98307 root 66696 1
0x47505344 131076 root 6668240 1
The PPS seems to be seen by gpsd:
root@hoei:/home/folkert# strace -fp 27872 21 | grep ioctl
...
[pid 27873] ioctl(9, PPS_FETCH, 0x7f1e63cc9d00) = 0
and the NMEA sentences are processed correctly:
x127.127.28.0.NMEA. 0 l 10 16 3770.000 -275.55 4.421
but the pps isn't:
127.127.28.1.PPS.0 l- 1600.0000.000 0.000
Anyone any idea?
Folkert van Heusden
Folkert,
Not an area I have a lot of expertise in, but two suggestions:
- shouldn't the NMEA have the prefer, and not the PPS? I am uncertain
about this, but if this is the case, I have this wrong on my Web page.
- I would try to include a time1 fudge factor of 0.275 into the NMEA
configuration, so that the offset had a mean value near to zero. I
presume you are comparing this to a reasonably good known reference -
perhaps one of you other stratum-1 servers.
I hope that helps.
--
Cheers,
David
Web: http://www.satsignal.eu
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] pps coming in, not received by ntpd
folkert wrote:
Hi,
Something odd is happening.
I've connected a garmin 18 lvc to a pc.
The system has a kernel with pps support and i verified it comes in:
root@hoei:/home/folkert# cat /sys/devices/virtual/pps/pps0/{assert,clear}
1372528130.997131540#54
1372528131.097120120#54
I'm running gpsd and it says the gps has a fix and it also has all
appropriate devices open:
gpsd 27762 nobody7u CHR 4,65 0t0
1144 /dev/ttyS1
gpsd 27762 nobody9r CHR 251,0 0t0
82440 /dev/pps0
gps is started with '-n'
ntpd is configurated to listen to the shared memory segments:
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid NMEA
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPS
Both nptd and gpsd look at the first 2 segments:
-- Shared Memory Segments
keyshmid owner perms bytes nattch status
0x4e545030 0 root 60096 2
0x4e545031 32769 root 60096 2
0x4e545032 65538 root 66696 1
0x4e545033 98307 root 66696 1
0x47505344 131076 root 6668240 1
The PPS seems to be seen by gpsd:
root@hoei:/home/folkert# strace -fp 27872 21 | grep ioctl
...
[pid 27873] ioctl(9, PPS_FETCH, 0x7f1e63cc9d00) = 0
and the NMEA sentences are processed correctly:
x127.127.28.0.NMEA. 0 l 10 16 3770.000 -275.55 4.421
but the pps isn't:
127.127.28.1.PPS.0 l- 1600.0000.000 0.000
Anyone any idea?
For my Sure gps I have:
server 127.127.20.2 mode 18 prefer
# NB the server line is prefer
fudge 127.127.20.2 stratum 4 time2 0.417 refid GPSb
server 127.127.22.2
fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb
The time2 value was obtained by running with noselect for a
few days and taking an average from the peer_summary mean for
the GPS. That value has since been adjusted to give a mean
closer to zero.
My MSF derived refclock uses radioclkd2 and that has:
server 127.127.28.0
fudge 127.127.28.0 stratum 1 time 1 0.024000 refid MSFa
with prefer being the pps synced server.
MSF server is about same as my other systems with rms offset of
about 0.4ms vs 3us for GPS/PPS. Also note that minpoll 4 seems
to introduces an occasional spike of 10us so I'm back to
not having minpoll or maxpoll specified.
David
Folkert van Heusden
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
[ntp:questions] step and stepout
Thank you Unruh and David Woolley for your answers. For other readers, in my original question I wrote that I pur tinker step 0.01 stepout 1 in my ntp.conf file. The aim is to have a synchronized clock to a 10 msec offset from the ntp server and get there as fast as possible with stepout 1. First, David you are right, the server I'm synchronizing to is stratum 1, not 0. You both convinced me not to use the tinker command: I will reach my 10 msec accuracy without it. My last question is how can I monitor the time offset from my ntp server during the running of ntpd to make sure this happens? Thank you! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
