On Mon, 12 Mar 2012 18:27:52 -0700, Alby VA wrote:
My whole setup isn't anything special. SureGPS is modified so you get
PPS.
RS232 cable to COM1 on a FreeBSD box. USB providing power. And several
NIST/USNO servers in ntp.conf for reference.
COM1 on FreeBSD?!? Are you sure?
If really a
On Mon, 12 Mar 2012 20:21:13 -0700, Alby VA wrote:
The RS232 is handing
the
Rx/Tx/PPS and such. Everything is coming in on /dev/cuau0.
But what is the internal implementation; it is a normal serial UART
type device or an on-board USB conversion (consult the mother board
hardware manual)?
If
On Mon, 05 Mar 2012 20:18:31 +, unruh wrote:
The problem is that parallel ports are far rarer than serial ports these
days, and even rarer than usb ports. And you would then have to get the
output of that counter into the computer. A bit more than $100 for the
whole thing I suspect.
On Sun, 04 Mar 2012 22:37:35 +, Ron Frazier (NTP) wrote:
I
want to see what the max performance I can get with USB with handshaking
is possible. I think I can break the + / - 1 ms barrier.
See http://gpsd.berlios.de/faq.html#time
___
On Wed, 29 Feb 2012 14:16:23 +, Ron Frazier (NTP) wrote:
Other than the Sure board which has been mentioned, are there any other
modern, hi sensitivity, timing GPS's which cost less than $ 100. Many
of the ones mentioned seem to be older technology like this Trimble.
I use a Garmin 17x
On Wed, 07 Dec 2011 23:56:08 +, Harlan Stenn wrote:
Bruce wrote:
I do run sntp to set the clock before starting ntpd (so I don't need
ntpdate). Setting the clock this way at least gets the time offset in
the ballpark before ntpd starts.
OK, and exactly why do you need the time offset
Some code in ntpd applies a dither using ntp_random. However,
ntp_random (which is also used elsewhere, e.g. in getting an
initial association ID) generates only positive integers,
resulting in a one-sided offset bias. The following patch
compensates for this bias by offsetting the return value
On Thu, 08 Dec 2011 20:14:28 +, Harlan Stenn wrote:
Bruce wrote:
On Wed, 07 Dec 2011 23:56:08 +, Harlan Stenn wrote:
Short
of that, getting close to the right offset before starting ntpd means:
1) processes that depend on reasonably-close time synchronization
(rsync, etc.) can
On Wed, 07 Dec 2011 07:30:12 +, Harlan Stenn wrote:
I'm saying I'm not aware of good reasons to set the clock before
starting ntpd at system startup.
[...]
With a good drift file and a proper ntp.conf file, ntpd will have the
clock fully sync'd in about 11 seconds' time.
Of 18 computers
On Sat, 09 Apr 2011 11:55:02 -0500, Hal Murray wrote:
Is there any way to test to see if a mutex has been initialized?
One way is to call pthread_mutex_init and check for an EBUSY error return.
See the pthread_mutex_init man page for details.
One could also keep track of initialization status
On Wed, 30 Mar 2011 07:15:16 +0200, Terje Mathisen wrote:
This is exactly the reason why the shm communication setup I am
currently testing has a 64-bit marker as the first field:
(It is GPSD-NTP when viewed as a little-endian string.)
I suspect that there may be some compilers for 32-bit
On Sat, 19 Mar 2011 22:06:16 -0500, Hal Murray wrote:
In article 2wlgp.34776$d46.31...@newsfe07.iad,
Bruce Lilly bruce.li...@gmail.com writes:
o POSIX mutex for synchronized access to shared memory for updates
-- obviates mode 0 / mode 1 / OLDWAY
I'm far from a POSIX wizard. When I
On Fri, 18 Mar 2011 03:16:38 +, Dave Hart wrote:
On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly bruce.li...@gmail.com
wrote:
4. Assuming specific sizes for an integer is a really bad idea... (64
bits making up the) clockTimeStamp* and receiveTimeStamp* fields
Actually nailing down
On Fri, 18 Mar 2011 04:51:40 +, Harlan Stenn wrote:
I don't see this one. If flag1 0 (the current default) means SVID,
and we decide that flag1 1 means POSIX, what is the issue? How is
that significantly different from changing 127.127.28.x to 127.127.y.x ?
Among others,
1. The
On Fri, 18 Mar 2011 13:32:11 +, Dave Hart wrote:
It is not clear to me the two drivers need to be side-by-side differing
implementations in one driver. I suspect server 127.127.28.x mode 2
can reasonably mean using POSIX named shared memory of the form
/ntpshm/[unit] and either the
On Fri, 18 Mar 2011 05:17:32 +, Harlan Stenn wrote:
[referring to a proposal to somehow combine SVID shared memory and POSIX
shared memory code in a single driver]
I think I've seen these and I still don't think it's a big deal.
Perhaps you are confused because both contain the words
I'm preparing a POSIX shared memory driver (PSHM) for ntp to address a
few issues that exist with the present SHM driver. In no particular
order, these are:
o POSIX (not SVID) shared memory
-- POSIX shared memory namespace rather than hexadecimal constant
-- avoids 0x4e545030 [...] Big
On Thu, 17 Mar 2011 14:13:24 +, David L. Mills wrote:
I take it your driver will replace or modify an existing driver, right?
Long term, possibly; but migrating code that uses an existing driver
isn't likely to happen overnight.
I see no problem though in reusing an abandoned driver
On Thu, 17 Mar 2011 13:57:08 +, Dave Hart wrote:
Sounds good, Bruce. The best way to get that integrated with ntpd is
first integrate it with the existing refclock_shm.c, so that both
flavors of shared memory are supported by a single driver. That allows
us to integrate the new driver
On Thu, 17 Mar 2011 20:02:17 +, Harlan Stenn wrote:
If you think this might make a good GSoC project, we should know
tomorrow if we have been accepted into GSoC 2011 and that would be an
option, too.
As I already have running code, I'm thinking more along the lines of
On Thu, 17 Mar 2011 19:57:02 +, Harlan Stenn wrote:
Please see http://support.ntp.org/bin/view/Dev/RefclockShmV2
[...]
I'm curious if we can support both POSIX and SVID SHM from the same
codebase, and use a flag bit or a mode to select which one is used.
OK, looked at it and the bug it
On Thu, 18 Nov 2010 18:00:11 +, Miernik, Jerzy (Jerzy) wrote:
2. Are offsets as small as to be measured in (tens of) nanoseconds
really achievable, say among Linux workstations on a LAN?
Not readily. Tens of microseconds is achievable. One issue is
the time and time variability of
On Thu, 18 Nov 2010 18:00:11 +, Miernik, Jerzy (Jerzy) wrote:
2. Are offsets as small as to be measured in (tens of) nanoseconds
really achievable, say among Linux workstations on a LAN?
Not readily. Tens of microseconds is achievable. One issue is
the time and time variability of
On Wed, 30 Jun 2010 13:50:44 +, Michael Eder wrote:
[...] The time source is
composed of a date and time string accurate to seconds, and a highly
accurate Pulse-Per-Second. I expect the shared memory interface to NTP
is the way to do this, but what is not clear to me is if I can enter
Running ntp
version=ntpd 4.2@1.1541-o Mon Jan 19 15:18:44 UTC 2009 (1)
as reported by ntpq, on opensuse 11.1 Linux, if that matters.
I'm trying to make sense of the time offset numbers reported in
loopstats and peerstats files and by ntptrace.
The documentation is unclear on a few points, and
25 matches
Mail list logo
