> The following is an example from ntpd.log
>
> 14 Apr 07:22:25 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
> 14 Apr 07:22:25 ntpd[1048]: time reset +0.231004 s
> 14 Apr 07:23:35 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
> 14 Apr 07:39:33 ntpd[1048]: time reset +0.318457 s
> 14 Apr 07:39
Bill wrote:
> On 2011-07-12, Lars Ericsson wrote:
> > Hi all,
> >
> > I have been running the ntp client on a Linux platform for some time and
> > have not seen any problems.
> >
> > I recently run into a strange behavior where our communication software
> > failed on some critical timeouts.
> > A
On 2011-07-14, Michael Eder wrote:
> Not using gpsd, just writing the NMEA time and receive time into SHM (0)
> like gpsd does. The pps does the same to SHM (1). Effectively the pps code
sounds like a bad procedure. You want to make sure that the nmea
actually gets associated with the second ma
> ??? Exactly which of the problems he mentioned had anything to do with
> "setting up ntp server in the ocean"?
inability to use a timing GPS receiver and having to use a nav type unit.
This entire problem would go away if he could use one of the more
common timing receivers and a fixed antenna.
Not using gpsd, just writing the NMEA time and receive time into SHM (0)
like gpsd does. The pps does the same to SHM (1). Effectively the pps code
just increments the second from the NMEA string and writes it to SHM. We
need certain values from the NMEA string so have not looked into anything
b
On 7/14/2011 9:46 AM, Uwe Klein wrote:
> Rob wrote:
>> The native binary protocol usually has a SPECIFICATION
>> about the time field in the messages (like: it is the
>> current time at the moment the beginning of the message
>> is leaving the receiver). The NMEA protocol has a
>> "time of fix
On 2011-07-14, Chris Albertson wrote:
> On Thu, Jul 14, 2011 at 7:04 AM, unruh wrote:
>
>> Why? That native binary will also suffer from large latency (the serial link
>> is slow no matter what is being sent over it) and probably also fairly
>> large jitter. And it suffers from the huge downside
>$GPZDA ?
I tried it on one unit. It didn't help. If anybody has examples of
it working please let us know what type of GPS receiver you tested.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
ques
Rob wrote:
The native binary protocol usually has a SPECIFICATION about the time
field in the messages (like: it is the current time at the moment the
beginning of the message is leaving the receiver). The NMEA protocol
has a "time of fix", and that tells you nothing about what time it is
now.
On Thu, Jul 14, 2011 at 7:04 AM, unruh wrote:
> Why? That native binary will also suffer from large latency (the serial link
> is slow no matter what is being sent over it) and probably also fairly
> large jitter. And it suffers from the huge downside of your having to
> learn a whole new languag
unruh wrote:
> On 2011-07-14, Rob wrote:
>> Michael Eder wrote:
>>> We have looked at our GPS on a scope, the PPS it is dead on and the NMEA
>>> (just one sentence) is also reliable with about a 680 ms latency and 10 ms
>>> jitter.
>>
>> Again, are you using gpsd?
>>
>> If so, you may want to tr
On 2011-07-14, Rob wrote:
> Michael Eder wrote:
>> We have looked at our GPS on a scope, the PPS it is dead on and the NMEA
>> (just one sentence) is also reliable with about a 680 ms latency and 10 ms
>> jitter.
>
> Again, are you using gpsd?
>
> If so, you may want to try removing the (huge) 68
On Wed, Jul 13, 2011 at 10:51:46PM +0100, David Woolley wrote:
> Hal Murray wrote:
> >>OK. I asked since a timewarp of 200ms is a bit surprising for real HW,
> >>but is something to be expected if you were running in a VM.
> >
> >It's easy to get a time-warp of 200 ms on a DSL link. Just download
On Wed, Jul 13, 2011 at 04:49:37PM -0500, Hal Murray wrote:
> >The problem is that the adjustment takes to large steps, not that it
> >takes to long time.
>
> ntpd will slew the clock at 500 PPM. You may be willing to wait a while
> for a second or two, but it takes a long time if you have to
Michael Eder wrote:
> We have looked at our GPS on a scope, the PPS it is dead on and the NMEA
> (just one sentence) is also reliable with about a 680 ms latency and 10 ms
> jitter.
Again, are you using gpsd?
If so, you may want to try removing the (huge) 680ms offset inside gpsd
instead of in n
15 matches
Mail list logo
