On 21 Feb 2009 12:15:30 GMT, Rob wrote:
> I think the value returned by the gettimeofday function will probably
> have a worse resolution on the MOXA board than it has on the PC.
> That will make it difficult to get a low offset value, as the gpsd process
> sends the gettimeofday value at the time
I think the value returned by the gettimeofday function will probably
have a worse resolution on the MOXA board than it has on the PC.
That will make it difficult to get a low offset value, as the gpsd process
sends the gettimeofday value at the time of the PPS pulse to ntpd via
the shared memory b
I would like to correct my previous data and send in more accurate
information. we are using RT3000(more accurate GPS receiver)and using ntp -q
program to query the output in both the nTP machine as well as the moxa board.
The following output were obtained.
NTP data
remote refid
>gpsd does not perform any filtering at all. it puts the timestamp
>data from NMEA and PPS into shared memory and lets ntpd do all the
>filtering via the shm driver.
I tweaked the shm driver a while ago. It's in ntp-dev.
It used to grab one sample per polling interval. Now it grabs
one per seco
Dave Hart wrote:
> On Feb 6, 5:35 pm, rxd1...@louisiana.edu (Dahal Runa) wrote:
>> gpsd: Packet discard of 35, chars remaining is 0 =
>> gpsd: <= GPS: $GPZDA,220649.000,05,02,2009,,*51
>> gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 0
>> gpsd: PPS pulse rejected. No fix.
>> gpsd: pps-detect (DC
David Mills wrote:
> Rob,
>
> That would work fine, but does not explain the large jitter reported,
> unless gpsd displays the raw data placed in the shared segment. That
> wouldn't be very useful; the ntpq rv data would be useful and in fact
> the ultimate performance calibration. Also, why is
Rob,
That would work fine, but does not explain the large jitter reported,
unless gpsd displays the raw data placed in the shared segment. That
wouldn't be very useful; the ntpq rv data would be useful and in fact
the ultimate performance calibration. Also, why is there a PPS claimi
but the ke
On Feb 6, 5:35 pm, rxd1...@louisiana.edu (Dahal Runa) wrote:
> gpsd: Packet discard of 35, chars remaining is 0 =
> gpsd: <= GPS: $GPZDA,220649.000,05,02,2009,,*51
> gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 0
> gpsd: PPS pulse rejected. No fix.
> gpsd: pps-detect (DCD) on /dev/ttyM0 changed
David Mills wrote:
> Third, the data reported is not from ntpd, but another daemon called
> gpsd. Apparently it doesn'tt like the PPS signal. I don't know what
> grooming algorithm it uses, but both the kernel and atom driver use a
> trimmed-mean median filter, which is a rather heave dose of s
Dahal,
I've never seen a properly configured GPS/PPS configuration behave as
badly as you report. See pogo.udel.edu as example. It rarely strays more
than a couple of microseconds.
First, as mentioned several times, ntpdc lies through its teeth. Some of
the billboard items reflect data that ha
We are using a highly accurate (GPS RT3000) and we are synchronizing our
system's time using the NTP computer. The time synchronization is pretty
accurate But we are receiving high offset and jitter values in moxa(UC-7112
plus) therefore we are not able to replace the moxa with the NTP.By using nt
On Sun, Jul 20, 2008 at 12:18 PM, <[EMAIL PROTECTED]> wrote:
> That doesn't seem right. Some forms of virtualization virtualize the
> time in this manner, but some do not. For instance on a multiple
> processor system, any type 1 hypervisor like xen or Hyper-X should be
> able to keep the time ju
On Jul 14, 11:29 am, [EMAIL PROTECTED] (Ryan Malayter) wrote:
> issue is not specific to VMware - all virtualization solutions have
> the same problem with time itself being virtualized (Xen, Microsoft
> Hyper-V, KVM, etc...)
That doesn't seem right. Some forms of virtualization virtualize the
ti
I added this section to the NTP Wiki a few weeks ago to address
similar questions:
http://support.ntp.org/bin/view/Support/VMWareNTP
We are wrapping up a large virtualization project at my office, and I
was surprised how poorly virtual machines keep time. Note that this
issue is not specific to VM
I'm cross-posting this from the Kerberos mailing list since this is
useful information for people running O/S's on top of VMWare and people
come here for time issues.
Danny
Original Message
>How about using the VMWare-Player for setting up various test machines?
>Ciao, Micha
15 matches
Mail list logo
