Mailinglist Archive: opensuse (3351 mails)

< Previous Next >
Re: [opensuse] Time stability
  • From: Roger Oberholtzer <roger@xxxxxx>
  • Date: Mon, 19 Mar 2007 08:17:10 +0100
  • Message-id: <1174288631.25107.15.camel@xxxxxxxxxxxx>
On Sat, 2007-03-17 at 13:31 -0600, Tom Patton wrote:
> On Sat, 2007-03-17 at 18:13 +0100, Roger Oberholtzer wrote:
> > On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
> > 
> 
> > We already do all this. My original question was not really about gps at
> > all. It was simple about a computer keeping time correct across boots.
> > Not changing the time by, say, 8.3 hours. The gps discussion has been an
> > aside.
> Which is what I thought you were asking in the first place.  So was it a
> problem with the /etc/adjtime file?
> 
> We've been using GPS per-second pulse for years, and usually involves
> phase-locking a clock.  (Simulcasting and HDTV, for example.  To the
> point of calculating the delay site-to-site for location AND elevation.)
> Sounds like you are on that path, but I haven't heard you mention a
> "master-car-clock" you would then sync all your equipment to.  There are
> even stand-alone time servers you could install in each vehicle,
> referenced to GPS and serving the in-car lan (not necessarily
> Ethernet-type, but your sensor "network") .  Each device would "learn"
> its inherent delay and compensate accordingly, if the lan was
> synchronous and predictable.  Include the time pole concurrently with
> your other sensor polling.  Your "get-data" loop would know precisely
> how many cycles it took, assuming it didn't get interrupted.
> 
> Perhaps you actually need TWO clocks, one known stable to very tight
> tolerance (short-term), and the other phase-locked to the GPS so you
> would know the GPS variance to apply, compensating for the movement your
> sensors detect.

> Sounds like you are caught in an "oops" mode and trying to avoid an
> earlier oversight in the plan stage, necessitating a major
> re-write? ...no offense intended.  If you are really pushing the
> envelope, then BEST of luck, and have FUN.

No offence taken. Not a design oversight. Systems evolve over time. New
things get added that need to be integrated. It would be great if one
could retro-design existing hardware based on new requirements. In fact
we have two independent time sync methods. One is based on our own
hardware. We are trying to move away from that as we move to a COTS
solution. Or, at least, 95% COTS. There are few solutions for this that
do not simply change the problem to a different one. We are trying to
keep problems limited to those we understand and can explain, it not
actually solve.

Also, the original question I had was not so much about not being able
to sync. It was that it makes quality control ever so much more reliable
when dates on files somewhat (within some minutes of tolerance) match
the real time. The sync/accuracy thing was also an aside. We just want
the damned PC clock not to change random amounts at reboot.

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