Mailinglist Archive: opensuse (3351 mails)

< Previous Next >
Re: [opensuse] Time stability
  • From: Roger Oberholtzer <roger@xxxxxx>
  • Date: Fri, 16 Mar 2007 15:58:02 +0100
  • Message-id: <1174057083.23953.78.camel@xxxxxxxxxxxx>
On Fri, 2007-03-16 at 13:39 +0000, Dave Howorth wrote:
> Roger Oberholtzer wrote:
> > On Fri, 2007-03-16 at 10:32 +0000, peter nikolic wrote:
> >> Can't you use NTP to set the time on boot   i take it they are all connected 
> >> to the net   or a network  with one machine connected to the internet  setup 
> >> a ntp server   use that to check against at boo time ..
> > 
> > Ahh. I forgot to mention one important fact. These computers are in
> > vehicles on the road. If they cannot figure it out on their own, it wont
> > be figured out.
> > 
> > They do have GPS. However, I have not found an efficient way to share
> > the GPS NMEA recored with nntp and our measurement software, which needs
> > the records with little (read no) delay.
> I don't know anything about this, but it's an interesting topic to me (I
> go sailing :)
> A quick <> showed lots of
> hits including one that says "The Star Sync GPS receiver plugs into a
> serial port and interfaces with the generic GPS NMEA driver included
> with the standard NTP distribution."
> If there's a generic GPS driver in the NTP distribution, as it claims,
> couldn't you use that to sync the machines?

The systems are high speed high data rate data collection systems. We
strive to eliminate repackaging data all over the place. Also, the gpsd
method removes any supplier-specific NMEA records, which we want. It is
part of the reason for going tor the Trimble line.

> Or is the key word in your problem 'share'? Aren't the NMEA time
> sentences broadcast so you just need some 'plumbing' to send it to both
> destinations (an extra cable, a small shell script, a one-line C
> program, whatever is appropriate)

The values are over a serial port. These are high-end Trimble receivers.
The reason for the serial port is that there is a pulse-per-second
signal that tells when certain calculations in the receiver were done.
We are striving for sub-meter accuracy in a vehicle traveling up to 110
km/h. Any transmission delay from when something is calculated to when
it is received is a source of error. The pps signal helps eliminate
this. I would be very happy if there was an ethernet or usb receiver
that still had all these features. Unfortunately, they typically are
geared for less demanding location requirements and so do not provide
these extra signals. We keep looking and hoping. There are some
PCI-based models that look interesting.

> The gpsd man page has a section on 'use with ntp', for example.

I would be happy if the ntp daemon could be told when to use the
receiver, and when not to use it. But I do not think this is the way it
is. The GPS will give bad/old/misc times when there are no receivers.
Like in a garage. Which is where the measurement systems often are

Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Kapellgränd 7
P.O. Box 4205
SE-102 65 Stockholm, Sweden

Tel: Int +46 8-615 60 20
Fax: Int +46 8-31 42 23

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >