Not getting microsecond accurate time in Linux with GPS setup
Hi all. I've grown interested in precise timekeeping so I decided to
buy an inexpensive Transystem iBlue 737 GPSr clone with MTK 3301 +
3179 chipset (32-channel, -158dBm tracking sensitivity, Silicon Wave
Bluetooth 1.2 chipset) for use with my Fedora 12 Linux Netbook (An
Acer Aspire One D150). Having lock indoors of 5/9 satellites I've
succeeded connecting the device via rfcomm to my netbook and using
gpsd for parsing the data. I restart the nptd server in the machine
and after a few minutes I get:
[root@PHOENIX Streamer]# ntpq -p
remote refid st t when poll reach delay offset jitter
---============
*SHM(0) .GPS. 0 l - 16 377 0.000 24.511 42.977
If I execute ntpstat, it shows:
[root@PHOENIX Streamer]# ntpstat
synchronised to modem at stratum 1
time correct to within 67 ms
polling server every 16 s
In /var/log/mesages I see the lines:
Jan 18 20:38:39 PHOENIX ntpd[6898]: ntpd 4.2.4p8@1.1612-o Wed Dec 9
11:49:22 UTC 2009 (1)
Jan 18 20:38:39 PHOENIX ntpd[6899]: precision = 5.448 usec
Jan 18 20:39:28 PHOENIX ntpd[6899]: synchronized to SHM(0), stratum 0
So why my system is telling me the time is correct within 67 ms and
not 5.44 usec? My GPSr is located at 1-1.5 meters from my netbook
(GPSr battery lasts around 40 hours, low power is not an issue). Does
my Linux installation need special Kernel patching or I'm missing
something?
Thanks in advance,
Mark
You'll probably get better (and more interesting!) answers on the NTP
group/mailing list, but a first thought is that NTP takes quite a long
time to stabilize after startup.
From the jitter value below being larger than the offset, I'm guessing
you took this ntpq snapshot after only a few polling intervals. Give it
a couple of hours and see where you end up. (Because of the slow
convergence, the typical laptop usage pattern is not conducive to good
NTP performance.)
John
On 1/18/2011 3:21 PM, Mark Ngbapai wrote:
Hi all. I've grown interested in precise timekeeping so I decided to
buy an inexpensive Transystem iBlue 737 GPSr clone with MTK 3301 +
3179 chipset (32-channel, -158dBm tracking sensitivity, Silicon Wave
Bluetooth 1.2 chipset) for use with my Fedora 12 Linux Netbook (An
Acer Aspire One D150). Having lock indoors of 5/9 satellites I've
succeeded connecting the device via rfcomm to my netbook and using
gpsd for parsing the data. I restart the nptd server in the machine
and after a few minutes I get:
[root@PHOENIX Streamer]# ntpq -p
remote refid st t when poll reach delay offset jitter
---============
*SHM(0) .GPS. 0 l - 16 377 0.000 24.511 42.977
If I execute ntpstat, it shows:
[root@PHOENIX Streamer]# ntpstat
synchronised to modem at stratum 1
time correct to within 67 ms
polling server every 16 s
In /var/log/mesages I see the lines:
Jan 18 20:38:39 PHOENIX ntpd[6898]: ntpd 4.2.4p8@1.1612-o Wed Dec 9
11:49:22 UTC 2009 (1)
Jan 18 20:38:39 PHOENIX ntpd[6899]: precision = 5.448 usec
Jan 18 20:39:28 PHOENIX ntpd[6899]: synchronized to SHM(0), stratum 0
So why my system is telling me the time is correct within 67 ms and
not 5.44 usec? My GPSr is located at 1-1.5 meters from my netbook
(GPSr battery lasts around 40 hours, low power is not an issue). Does
my Linux installation need special Kernel patching or I'm missing
something?
Thanks in advance,
Mark
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Some thoughts..
-
Can you really even expect 1uS timing with a BlueTooth GPS that
lacks a direct, wired 1PPS interface? My guess is "no". -
Next, add some pool servers to the ntp.conf file and let ntp get
your computer clock's rate of advance "in the ball park" As is
"drift" and "offset" are being compared to what? Let it run with pool
servers for an hour or more -
A "few minutes" is not enough time to know what the final steady
state result will be. Try 1/2 hour or over night.
I'd like it if someone could prove me wrong, but I think 1uS or better
timing will require different hardware and a more "direct" connection
to the GPS' PPS.
As a basic check, can you see how the location reported by the GPS
moves around. Ideally it would never move by even an inch but the
system is not perfect and there will be a spread in reported lat.
long. Just write down the low order digits every couple minutes for
an hour or so. the spread will change as the sats geometry changes.
At this point a rough estimate is good enough, is the GPS bouncing
around at the 100 meter level or the 1m level?
I tried using an old Garmin 12 GPS with NMEA only NTP driver and got
about 10X worse then your result. Basically the "12" was useless.
That was with good reception too as a put the GPS in the roof and ran
a long RS232 cable back to the computer. On the other hand my Oncore
UT+ GPS gives results on order of 1000X or 500x better then you
report. Not all GPS units are good for timing
On Tue, Jan 18, 2011 at 12:21 PM, Mark Ngbapai
lightningbolt31@gmail.com wrote:
Hi all. I've grown interested in precise timekeeping so I decided to
buy an inexpensive Transystem iBlue 737 GPSr clone with MTK 3301 +
3179 chipset (32-channel, -158dBm tracking sensitivity, Silicon Wave
Bluetooth 1.2 chipset) for use with my Fedora 12 Linux Netbook (An
Acer Aspire One D150). Having lock indoors of 5/9 satellites I've
succeeded connecting the device via rfcomm to my netbook and using
gpsd for parsing the data. I restart the nptd server in the machine
and after a few minutes I get:
[root@PHOENIX Streamer]# ntpq -p
remote refid st t when poll reach delay offset jitter
---============
*SHM(0) .GPS. 0 l - 16 377 0.000 24.511 42.977
If I execute ntpstat, it shows:
[root@PHOENIX Streamer]# ntpstat
synchronised to modem at stratum 1
time correct to within 67 ms
polling server every 16 s
In /var/log/mesages I see the lines:
Jan 18 20:38:39 PHOENIX ntpd[6898]: ntpd 4.2.4p8@1.1612-o Wed Dec 9
11:49:22 UTC 2009 (1)
Jan 18 20:38:39 PHOENIX ntpd[6899]: precision = 5.448 usec
Jan 18 20:39:28 PHOENIX ntpd[6899]: synchronized to SHM(0), stratum 0
So why my system is telling me the time is correct within 67 ms and
not 5.44 usec? My GPSr is located at 1-1.5 meters from my netbook
(GPSr battery lasts around 40 hours, low power is not an issue). Does
my Linux installation need special Kernel patching or I'm missing
something?
Thanks in advance,
Mark
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi,
A couple of things not mentioned in the previous responses:
" precision" here is not how accurate your laptops clock is.
"precision" is a measure of how much the time changes during successive
reading of the system clock as viewed by ntpd. Its minimum value is 1us
due to the timeval structure variable types.
Your ntpq data is showing a high offset 24,5 ms but that it also has
high jitter , adding the two gives you around 67 secs reported.
Laptops often have variable speed oscillators to save power when not
much is going on. This will cause unreliable timing and may be the
source of your jitter. If your machine has that facility I suggest you
turn it off (probably in the bios) and see if the stability improves.
As mentioned , the time source is not optimal. I am pretty sure you
only have the NMEA sentences to get time info and they are sent after
the 1sec GPS mark. Check to see if the SHM driver has a fudge variable
to take that into configuration. If you are seeing a constant offset of
25ms and the shm driver has a fudge to allow for it, then configure it.
However I doubt that you will be able to get better than 10s of ms
accuracy with the hardware you have.
You should be configuring more time servers. Take them off the ntp
pool for instance over the network.
Le 18/01/2011 21:21, Mark Ngbapai a écrit :
Hi all. I've grown interested in precise timekeeping so I decided to
buy an inexpensive Transystem iBlue 737 GPSr clone with MTK 3301 +
3179 chipset (32-channel, -158dBm tracking sensitivity, Silicon Wave
Bluetooth 1.2 chipset) for use with my Fedora 12 Linux Netbook (An
Acer Aspire One D150). Having lock indoors of 5/9 satellites I've
succeeded connecting the device via rfcomm to my netbook and using
gpsd for parsing the data. I restart the nptd server in the machine
and after a few minutes I get:
[root@PHOENIX Streamer]# ntpq -p
remote refid st t when poll reach delay offset jitter
---============
*SHM(0) .GPS. 0 l - 16 377 0.000 24.511 42.977
If I execute ntpstat, it shows:
[root@PHOENIX Streamer]# ntpstat
synchronised to modem at stratum 1
time correct to within 67 ms
polling server every 16 s
In /var/log/mesages I see the lines:
Jan 18 20:38:39 PHOENIX ntpd[6898]: ntpd 4.2.4p8@1.1612-o Wed Dec 9
11:49:22 UTC 2009 (1)
Jan 18 20:38:39 PHOENIX ntpd[6899]: precision = 5.448 usec
Jan 18 20:39:28 PHOENIX ntpd[6899]: synchronized to SHM(0), stratum 0
So why my system is telling me the time is correct within 67 ms and
not 5.44 usec? My GPSr is located at 1-1.5 meters from my netbook
(GPSr battery lasts around 40 hours, low power is not an issue). Does
my Linux installation need special Kernel patching or I'm missing
something?
Thanks in advance,
Mark
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.