Re: [ntp:questions] Offset Average (Normal)?
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 you can't get a hardware manual, or if it is uninformative, check the boot-up logs to see what driver is used. Failing that, look at the physical board to see where the connector pins go. If you can't do that, capture the PPS timestamps with the PPS/NMEA drivers set to noselect and the system fully synchronized (loopstats time offset, jitter, and frequency offset all stable) to a reliable source and the system relatively otherwise idle. Collect timestamps for about an hour and plot the offset of the timestamps to the nearest second of the (externally synchronized) system clock. An approximately 1 million nanosecond peak-to-peak sawtooth offset is a tell-tale sign of 0.001 MHz USB-like polling. If you plot a histogram of offsets, USB or similar polling will produce a rectangular distribution of offsets (for a sufficiently large sample set); normally an interrupt-driven serial port PPS sample offset distribution is an asymmetrical long-tailed bell- shaped distribution with a distinct peak. N.B. it is important to capture the PPS edge which is the timing reference; consult your GPS device manual, taking into account any signal inversions due to line drivers. If you're not using a proper line driver (e.g. TI SN75155), do that first. The xmgrace program may be useful in plotting offsets and histograms. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Offset Average (Normal)?
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 tty, is it a normal implementation or via a USB conversion? For USB, a 1 ms pk-pk sawtooth is the best one can achieve. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ESR looking for good GPS clocks
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. Here's an outline of how this can be easily done for far less than $100 of hardware: any parallel output for which a suitable driver exists can be used. Most general-purpose computers have more than one of these (e.g. LED drivers, IR drivers, as well as serial and/or parallel ports). At some time, the computer takes a timestamp, sets an output port line to a specific state and takes another timestamp. The two timestamps bracket the setting of the output (the output state can be reset at some later non-critical time). A simple microcontroller such as a Microchip dsPIC series device does the rest, viz. measure the time interval between the aforementioned computer output pin and the GPS PPS timing reference edge, read and echo NMEA messages from the GPS serial data, and convert the measured time interval into an NMEA sentence which is inserted into the serial output along with echoed GPS NMEA sentences. The computer reads the NMEA data (USB is fine as timing of the serial data is not critical); the measured time interval is encoded in the NMEA data and the computer has before and after timestamps bracketing the output port state transition, from which the local clock timing offset to GPS PPS timing reference is easily computed. Echoed GPS NMEA sentences provide the date and time. Microcontroller and support components, I/O signal conditioning, serial line transceivers, etc. total cost is likely to be well under $100 even in small quantities. Microcontroller requirements are modest; a reasonable timer, serial I/O, and enough memory for a fairly simple program. Of course, there are many boards suitable for use as a router (e.g. Soekris products) that not only have parallel I/O but also can use the on- board CPU for timing, eliminating the need for a microcontroller. And interfacing GPS timing receivers to a Soekris board has already been done (Google can point you to some examples). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] almost decided which new PPS GPS to buy
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 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do you like the Trimble Resolution T
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 HVS NMEA 0183 which I bought new about a year ago for just under $100. Current price at the same vendor appears to be a bit over $100: http://www.gpscity.com/garmin-oem-17x-hvs-nmea-0183.html The unit is specifically designed for outdoor use and comes with several mounting options. Garmin's web page is at: https://buy.garmin.com/shop/shop.do?cID=158&pID=13191 N.B. don't confuse this with the NMEA 2000 version! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpdate removal is coming
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 proceed > > Again, the BCP I described earlier addresses this too... > >> 2) ntpd converges to a stable point that much faster (i.e. it has >>less of an initial offset to remove) > > At the moment, the worst case for this is an offset that is just under > 128ms, which will take under 5 minutes to apply at the standard slew > rate of 500ppm. (64ms will take about 2.5 minutes' time to apply, etc.) Those times apply *after* enough samples have been gathered for an offset estimate, which happens *after* a system peer has been selected. That can take many minutes. With ntp-wait, the boot sequence would be effectively stalled for the duration. >> I use sntp (rather than ntpd -q or ntp-wait) because it's much faster >> than the alternatives (life is too short for thumb-twiddling). > > And you might still get a backwards step in this case. Not a problem during startup, before anything that needs synchronization is running. > The bottom line is that you have not communicated any information to me > that indicates you have a *need* to set the time before NTP starts. "Need" is a strong term; it's true that the world as we know it won't come to an abrupt end if booting is stalled for ten minutes, but it is rather inconvenient. In any event, my initial response was to point out two issues: 1. your reference to "a good drift file" presumes that all systems have a frequency offset which is stable across a reboot; that is an invalid assumption for most machines that I have in service here. Please bear in mind the fact that many systems do not have a stable frequency offset around a reboot and therefore cannot make practical use of a drift file at system startup (stop/restart of ntpd while the system is running is of course another matter). 2. your estimate of "fully sync'd in 11 seconds' time" seemed overly optimistic (and still does, even with minimum polling times and maximum slew rate). To which I would add that there are some configuration options (e.g. xleave) which ameliorate some issues during steady-state operation but which seem to make startup (system peer selection in particular) take much longer after a reboot. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] offset bias in ntpd
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
from ntp_random to produce approximately zero mean dither
in both positive and negative offset directions in the
functions which use ntp_random for dither.
*** libntp/systime.c.orig Wed Dec 9 02:36:35 2009
--- libntp/systime.cSat Nov 19 09:10:31 2011
***
*** 62,67
--- 62,68
)
{
double dtemp;
+ long correction = (1L << 30) + 1L; /* compensate for ntp_random bias */
#if defined(HAVE_CLOCK_GETTIME) || defined(HAVE_GETCLOCK)
struct timespec ts; /* seconds and nanoseconds */
***
*** 78,86
now->l_i = (int32)ts.tv_sec + JAN_1970;
dtemp = 0;
if (sys_tick > FUZZ)
! dtemp = ntp_random() * 2. / FRAC * sys_tick * 1e9;
else if (sys_tick > 0)
! dtemp = ntp_random() * 2. / FRAC;
dtemp = (ts.tv_nsec + dtemp) * 1e-9 + sys_residual;
if (dtemp >= 1.) {
dtemp -= 1.;
--- 79,87
now->l_i = (int32)ts.tv_sec + JAN_1970;
dtemp = 0;
if (sys_tick > FUZZ)
! dtemp = (ntp_random() - correction) * 2. / FRAC * sys_tick *
1e9;
else if (sys_tick > 0)
! dtemp = (ntp_random() - correction) * 2. / FRAC;
dtemp = (ts.tv_nsec + dtemp) * 1e-9 + sys_residual;
if (dtemp >= 1.) {
dtemp -= 1.;
***
*** 102,110
now->l_i = tv.tv_sec + JAN_1970;
dtemp = 0;
if (sys_tick > FUZZ)
! dtemp = ntp_random() * 2. / FRAC * sys_tick * 1e6;
else if (sys_tick > 0)
! dtemp = ntp_random() * 2. / FRAC;
dtemp = (tv.tv_usec + dtemp) * 1e-6 + sys_residual;
if (dtemp >= 1.) {
dtemp -= 1.;
--- 103,111
now->l_i = tv.tv_sec + JAN_1970;
dtemp = 0;
if (sys_tick > FUZZ)
! dtemp = (ntp_random() - correction) * 2. / FRAC * sys_tick *
1e6;
else if (sys_tick > 0)
! dtemp = (ntp_random() - correction) * 2. / FRAC;
dtemp = (tv.tv_usec + dtemp) * 1e-6 + sys_residual;
if (dtemp >= 1.) {
dtemp -= 1.;
*** ntpd/ntp_io.c.orig Sat Dec 25 04:40:36 2010
--- ntpd/ntp_io.c Sat Oct 29 08:12:06 2011
***
*** 3344,3350
tvp->tv_sec, tvp->tv_usec));
nts.l_i = tvp->tv_sec + JAN_1970;
dtemp = (tvp->tv_usec
!+ (ntp_random() * 2. / FRAC)) / 1e6;
nts.l_uf = (u_int32)(dtemp * FRAC);
#ifdef DEBUG_TIMING
{
--- 3344,3350
tvp->tv_sec, tvp->tv_usec));
nts.l_i = tvp->tv_sec + JAN_1970;
dtemp = (tvp->tv_usec
!+ ((ntp_random() - (1L << 30) - 1) * 2. /
FRAC)) / 1e6;
nts.l_uf = (u_int32)(dtemp * FRAC);
#ifdef DEBUG_TIMING
{
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpdate removal is coming
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 in the ballpark before > ntpd starts"? In the worst case, e.g. if the machine has been out of service for a long time, ntpd will just quit if the initial offset is large. 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 proceed 2) ntpd converges to a stable point that much faster (i.e. it has less of an initial offset to remove) I use sntp (rather than ntpd -q or ntp-wait) because it's much faster than the alternatives (life is too short for thumb-twiddling). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpdate removal is coming
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 here currently running ntpd, 11 do not have stable frequency offset across a reboot (i.e. a drift file is not useful at system startup for those machines). The remaining 7 machines do have stable frequency offset across a reboot except in the case of a kernel update, which does sometimes cause a change in frequency offset even in those machines. Four of the machines are not normally on-line; they are running as a testbed for a distribution update which is being rolled out, and one of those four is one of the ones with a stable frequency offset (so the normal numbers are 14 computers running ntpd, 8 of which do not have a stable frequency offset across a reboot). Motherboard/BIOS design seems to have the biggest impact on frequency offset stability across a reboot (four of the seven machines with stable frequency offsets are of a single motherboard design). Ntpd version is a modified 4.2.6p4. 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. Also, I have not seen machines "fully sync'd" in anywhere near as quickly as 11 seconds, but my interpretation of "fully sync'd" may differ from yours; I consider a machine "fully sync'd" only when time offset, frequency offset, and jitter (as reported in loopstats) have all stabilized, which may take a few hours. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 (and which process initialized) in a variable in shared memory. Either ignore locking for setting that variable or try to deal with the chicken-or-egg issue. I still advise using a semaphore in preference to a mutex, or better still, avoid shared access entirely. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 platforms
that won't know what to do with a 64-bit field (declared as such).
The approach I took was to use a local (i.e. non-shared) union of 4
chars and a 32-bit int, setting the 4 chars to known values and
converting to host order with ntohl. That result is then put into
shared memory. Doing that for both processes allows each to detect an
incompatibility with the other (with shared memory for each process'
word size/endianness data). In retrospect, precautions would probably
have to be taken to ensure that the union was in the same page (or at
least a page with the same endianness) as the shared memory. Prior to
shared memory use for transfer, the union itself could be in shared
memory.
> Since the current testing have shown that it works with 13 M
> updates/second, I feel quite safe that it will work fine for one or a
> couple of timestamp messages per second.
I don't expect that endianness would change during process execution,
so initializing one time should suffice. In any case, I wouldn't
expect a performance issue.
> Bruce, I assume you follow both the gpsd and ntp-hackers mailing lists?
No, though I have seen a few messages in my inbox as a result of earlier
postings here ("here" being Usenet group comp.protocols.time.ntp).
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
On Mon, 28 Mar 2011 04:56:24 +, Dave Hart wrote:
> It hasn't come up there, but I've been thinking about backwards
> compatibility in an updated refclock_shm which supports the existing
> SysV shared memory, struct shmTime, and access methods for units 0-3,
> and uses POSIX named shared memory with new layout and access semantics
> for units 4 and up.
I presume that means (in each of the driver functions) something like:
if (unit < 4) {
/* do SHM driver stuff (SVID) */
} else {
/* do new stuff */
}
Is that correct?
> I encourage you to join hack...@lists.ntp.org and/or create a bug report
> at http://bugs.ntp.org/ and share what you've done, if you want to see
> some part of it make it into an updated refclock_shm.c.
I'm already subscribed to more mailing lists than I can keep up with!
If I were continuing with my original plan or redoing it, I'd do things
differently from what I have done. But I have another plan which can
avoid the word size/endianness/locking issues altogether, and it provides
for future precision beyond the nanosecond level. More details to follow
in due course.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
On Mon, 28 Mar 2011 15:01:13 +, David L. Mills wrote: > You may not be aware that all Spectracom devices are supported with one > driver, all TrueTime devices are supported with one driver, all > telephone modem services are supported with one driver, all Austron > devices are supported with one driver, all Heath devices are supported > with one driver and most GPS receivers are supported with one driver. I'm going to give the benefit of the doubt and presume that that's an early April Fool's joke: Spectracom devices involve not one, but multiple drivers: refclock_acts.c refclock_irig.c refclock_wwvb.c GPS receivers invlove *many* drivers, including at least the following: refclock_acts.c refclock_arbiter.c refclock_as2201.c refclock_bancomm.c refclock_fg.c refclock_gpsvme.c refclock_hopfpci.c refclock_hopfser.c refclock_hpgps.c refclock_jupiter.c refclock_mx4200.c refclock_nmea.c refclock_oncore.c refclock_palisade.c refclock_parse.c refclock_ripencc.c refclock_trak.c refclock_true.c refclock_wwvb.c refclock_zyfer.c ...and your reference to all one Austron devices [sic] is contradictory as the supported Austron device *is* a GPS receiver. Note also in the above list of GPS drivers that there are two separate ones for Hopf devices as well as for Trimble GPS devices. The refclock_heath.c driver in fact supports only one of the two (long since discontinued) Heathkit receivers, as is well-documented in the source code, e.g.: * The GC-1001 II was apparently never tested and, based on a Coverity * scan, apparently never worked [Bug 689]. Related code has been disabled. As for Truetime, the driver opens a serial port and parses the received text; it does not need to access different types of objects, different object namespaces, or different APIs -- it's really only one sort of device with relatively minor data stream inconsistencies. With somewhat greater accuracy, you might have said that there is one driver that supports all supported SVID IPC interfaces. > This happened with many hours of dedicated effort on the part of > refclock developers. You can appreciate the serious pushback in creating > a new driver if a similar one is already available. One might then ask, as many of the above all merely grab data from a serial port, why they were not all required to be rolled into a single driver, such as refclock_parse.c. But then, a quick glance at that shows how convoluted things can get... One might also wonder why there are separate drivers for WWVB receivers, all using the same type of serial port communications, and all apparently minor variations derived from the first: refclock_wwvb.c refclock_chronolg.c refclock_dumbclock.c refclock_ulink.c ... or the ones for various IRIG time code receivers. In the case of what I have to date proposed, there are no similar drivers (I looked. Several times). There aren't any that address the issues outlined in the article which started this thread. There aren't any that use any form of POSIX IPC. There seems to be some confusion, probably on the part of those unfamiliar with the differences between SVID and POSIX shared memory: SVID shared memory and POSIX shared memory have as much in common as a Yamaha motorcycle and a Yamaha piano. Less in common than other types of IPC (e.g. semaphores), which are also quite different and in most cases also incompatible. > An appropriate plan > is > > [common interface code] > #ifdef POSIX > ... > #else > ... > #endif That implies compiled-in support for one (exclusive-)or another type of device, i.e. no possibility to use both types. Worse, it means one build will try to access one type of device given a particular refclock server configuration, and a build with a different set of (build) configure options will access a different type of device given the same (runtime) ntpd configuration file refclock server pseudo-IP address specification. In effect, it means that there are two distinct drivers (only one of which can be incorporated at build time) using a single device driver number. Are you really suggesting some sort of build-time configure option and conditional compilation macro that would replace (e.g.) the Heathkit driver with something completely different? If so, in some sense that might not be such a terrible idea; some products (and in some cases the companies that produced them) have long since vanished. Likewise for some technologies (e.g. LORAN). However, it invites confusion when bug reports etc. refer to a device number that might be different things depending on ntp version and build options (and please bear in mind the fact that the person reporting the bug might not be the one who built the executable, as e.g. in binary distributions). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
On Mon, 28 Mar 2011 08:18:24 +, Rob wrote: > Bruce Lilly wrote: >> Endianness (and more generally byte order) are of concern for precisely >> the same reasons. > > This is not relevant in the case of shared memory, as long as the memory > is not shared between processors of different endianess. Please reread the information regarding bi-endian hardware and note that some can be configured to switch endianness on a per-page basis. That's with a single processor. Note also that the mapping of memory in different processes may be to different addresses (i.e. different pages). Given that there are two separate processes involved, I cannot safely assume that different endianness might never arise; it's certainly conceivable that the ntp side might be built big-endian (to simplify networking operations), while the other process might be little-endian (perhaps to more efficiently cope with hardware). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
On Sat, 19 Mar 2011 22:06:16 -0500, Hal Murray wrote: > In article <2wlgp.34776$d46.31...@newsfe07.iad>, > Bruce Lilly 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 google for >POSIX mutex< I get a > bunch of hits that all are part of pthreads. > > Does that stuff work across processes rather than threads? > > The mutex needs to be in shared memory so both processes can get at it. > Right? Who initializes it? Mutexes can work across processes; look for pthread_mutexattr_setpshared. The first party who needs the mutex (if not already initialized) initializes it. Destruction is another issue. There are a lot of complications (e.g. the mutex (and its attributes) typically are mapped to different addresses in different processes). POSIX semaphores are a bit simpler to use, even though a semaphore is more generic than a mutex. And POSIX semaphores come in unnamed (which can reside in shared memory) and named varieties. Unfortunately, there are plenty of implementation issues. In either (mutex/semaphore) case, there is a related issue; viz. it is unclear whether or not either will work in cross-word-size situations (i.e. on a 64-bit machine with both 64-bit and 32-bit libraries where one process is built and linked for 32-bit and the other for 64-bit), or worse (bi-endian machines). About the best one can do is to identify word size and byte order of both processes and refuse to play if there's a mismatch. I can avoid the word size and byte order issues entirely (though not without some small performance cost), and avoid the need for a semaphore or mutex as well using another IPC technology (and with a few additional benefits). But that's a story for another day. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 "shared memory"? They access different objects existing in different namespaces using different methods accessed via different APIs. They really have nothing in common. > OK. I sure know about SVID semaphore mechanism. The semaphore (or > mutex) operations *must* be nonblocking. As I never said anything about blocking, I wonder why you bring this up? >> 4. Assuming specific sizes for an integer is a really bad idea... "(64 >> bits making up the) clockTimeStamp* and receiveTimeStamp* fields" > > I'm missing your point here. We should only be using "generic" integral > types if we have reason to believe they are at least N bits wide. For > anything else, we are using intNN types (for cases where we want exactly > NN bits). Perhaps you should look at the refclock_shm.c code; that's *entirely* '"generic" integral types'. I.e. nothing specifies that those fields comprise a 64-bit chunk of memory (shared or otherwise). [and if one changes the existing generic types, it will break on one architecture or another] ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 existing shm structure, or a variant with > fixed-sized elements. Gack! No! From TFM: "The interpretation of slash characters other than the leading slash character in name is implementation-defined." Don't do that unless you like dealing with lots of implementation dependencies. And the existing SHM driver memory structure is unsuitable for a variety of reasons, as previously mentioned (e.g. word size and byte order issues, no nanosecond support, no proper locking, etc.). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 following is workable: server 127.127.28.1 ... server 127.127.y.1 ... Your proposal in this respect, viz.: server 127.127.28.1 ... fudge 127.127.28.1 flag1 0 ... server 127.127.28.1 ... fudge 127.127.28.1 flag1 1 ... simply won't work. IOW, one can have 4 units ea. using different drivers, but one cannot have multiple devices sharing the same driver and unit numbers but differing flags (or ttl, etc.) 2. With separate drivers, each can perform appropriate initialization via the clock_init function pointer in its struct refclock structure. One cannot alter the way that works based on flag or ttl values as neither are accessible; the prototype is: void (*clock_init) (void); I.e. no pointer to a peer structure. > They are separate issues. We support timespec where it exists. We want > to support timespec under SHM regardless. If I thought that was feasible, I would have done it and submitted patches a year ago. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
On Fri, 18 Mar 2011 03:16:38 +, Dave Hart wrote: > On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly > 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 the sizes of objects is a really good idea when > sharing binary structures across separately-compiled programs. We > cannot presume the same compiler and options build ntpd and anything > that attempts to share memory with it. We need not (and should not) > worry about endianness for a shared memory contract, though. > > Thanks for playing, Endianness (and more generally byte order) are of concern for precisely the same reasons. Perhaps you are unfamiliar with: http://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
On Thu, 17 Mar 2011 22:05:29 +, Harlan Stenn wrote: [quoting "unruh"] >> I suspect what he had in mind was to make an entirely new driver, with >> a new number, which was the posix shm driver, and hope that eventually >> the old one would decay from lack of use. That's about right. >> Of course that >> leads to driver proliferation ( do we really want a world where there >> are 16000 drivers? I'm proposing to add one (1) to address specific issues and which would be capable of being interfaced to a variety of hardware (I currently interface to a GPS/PPS device and a couple of WWVB radio clocks), not 15956... >> Actually more than 255 would be problematic) since >> drivers are never dropped ( someone might be using them) as can be seen >> from some of the drivers which are in there and which I suspect at most >> one person in the world uses. 23, 24, 25 seem to be unused... at REFCLOCK_MAX = 44, I compute at most 18% of the capacity used. Hardly a cause for alarm. > I read this and it only adds to my belief that we need a "refclock > definition language" and a means to easily customize them. From what I > can see, this solution elegantly solves a fairly encompassing "problem > space". > > Just so it's handy still: > > http://support.ntp.org/bin/view/Dev/ GSoCProjectIdeas#Refclock_Definition_Language > http://support.ntp.org/bin/view/Dev/LoadableRefclockDrivers Most of the existing ntp drivers support some way to interface specific hardware to the ntp core daemon code. Shared memory driver(s) are an exception; they represent a sort of middle ground where some client interfaces to the hardware, and communicates via shared memory to the driver which passes the information to the ntp core code. As distinct from the hardware-specific drivers which are compiled into the ntpd executable, hardware interfaces using shared memory are separate programs (like gpsd). Given a suitable shared memory (or similar technology) driver, there should in theory be no need for any separate hardware- specific ntpd drivers; hardware interfaces could simply be shared memory (or similar technology) clients (a la gpsd). Note however: 1. the transition from the current situation isn't going to take place quickly 2. A unit count of 4 is likely to be insufficient if there's only one (or a very few) driver(s) for hardware devices to connect via; in that respect, the existing SHM driver goes into obfuscation mode [well, some might say that 0x4e545030 is already obfuscated :-)] above unit 9, whereas my proposal a. easily handles the IPv4-derived ntp maximum of 256 units b. could easily handle up to whatever the implementation has as an unsigned integer (more than 4 billion on 32-bit architectures) c. could theoretically handle more than a google squared units using only decimal numbers for the unit naming given the POSIX shared memory namespace name size of 255+ [i.e. "ample namespace size for ridiculously huge numbers of units w/o obfuscation"] 3. Interfacing via shared memory opens a means for injecting false timing information that is distinct from what exists with hardware-specific drivers [or with shared libraries (etc.)]. That hasn't been adequately considered either in the existing SHM driver or in my proposed code; some sort of authentication scheme workable via shared memory (or similar technologies) might be a suitable research project. 4. On a positive note, going this route means [eventually] smaller ntpd code with a fairly clean separation between ntpd as a kernel timekeeping manager and separate programs (e.g. gpsd-like) for interfacing to hardware timing devices. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 references. Comments: 1. one code base is probably impractical (see separate response to Dave Hart's post). 2. What's needed to coordinate driver and shared memory client access is a proper semaphore or mutex, not more modes to avoid doing the job properly. For crying out loud, Dijkstra's semaphore paper is now ca. 46 years old: http://en.wikipedia.org/wiki/Semaphore_(programming) http://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD123.html 3. to get nanosecond timestamping on a non-proprietary platform implies use of (POSIX) clock_gettime() or something like it, which uses (POSIX) struct timespec. If one has those, one likely also has POSIX shared memory and POSIX mutexes and semaphores. Mixing POSIX and SVID seems like a bad idea; at some point, the SVID-specific stuff is going to go the way of Lotus-1-2-3 (and I say that as a long time user of genuine UNIX (Registered Trademark) System V). 4. Assuming specific sizes for an integer is a really bad idea... "(64 bits making up the) clockTimeStamp* and receiveTimeStamp* fields" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 before-Spring-arrives :-). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 without adding as much to the maintenance > burden of carrying around so many different drivers. I believe that's a non-starter for several reasons: 1. SVID and POSIX shared memory are quite different. Trying to incorporate both in one driver is likely impractical because: a. either it will present a configure headache as well as a maze of intertwined #ifdefs that will present a maintenance headache and/or b. it will fail to build on systems that have the necessary support for SVID shared memory but not for POSIX shared memory and/or c. vice-versa [ of 417 lines in refclock_shm.c and currently 304 lines in my implementation (built and tested on Linux x86 and x86_64 and FreeBSD x86) there are fewer than 35 non-blank lines that are even close to similar, and many of those are #include lines common to most drivers] 2. it would reduce flexibility for those who wish to compile one flavor but not the other 3. it would not provide for a clean migration mechanism 4. (last and least) I have no interest in pursuing that path; I'd rather drop the effort entirely: a. the WINNT stuff in refclock_shm is alien and untestable by me (been there, done that, found and reported MS implementation bugs over a decade ago that remain unfixed (AFAIK) today). I've migrated away from MS and won't be going back. b. I looked first at modifying the existing driver; ns support implies (POSIX) struct timespec rather than struct timeval [see additional relevant comments in a separate response to Harlan Stenn's post] -- part SVID, part POSIX makes little sense compared to using a proper POSIX mutex and POSIX shared memory in addition to POSIX struct timespec. c. see 1a above. autoconf and automake are no joy. > I realize that is > in conflict with your goal of supporting only POSIX systems, but then, > so is ntpd in general. Don't be surprised to see me extend your > named-shared-memory driver to work on Windows one day... If MS POSIX compliance claims are true, then no "extension" is necessary. Otherwise, the proper place for any changes (if possible at all) is IMO firstly in the lap of the vendor, and secondly in "missing" or "ports". Beyond that, I wouldn't expect a POSIX driver to work on a non-POSIX- compliant system any more than I'd expect a Motorola GPS driver to work with a Garmin (or Magellan, ...) device. Indeed, a major advantage of separate drivers is that only the ones required need be built. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
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 number (e.g. 23, 24, or 25). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] new driver development
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 units will give non-ascii -- provides ample namespace size for ridiculously huge numbers of units w/o obfuscation o nanoseconds, not microseconds -- resolution compatible with bulk of the ntp reference implementation -- using POSIX struct timespec -- client compatibility with POSIX clock_gettime() o per-unit configurable source type (a.k.a. class) -- unlike present SHM driver, which treats all units as identical and unconfigurable -- currently UHF; wrong for everything else -- was TELEPHONE; wrong for everything else o per-unit PPS flag -- permits shared memory PPS drivers o POSIX-comforming code -- no attempt to work around buggy (non-POSIX-conforming) systems! o separate header file to simplify client code -- shared memory structure clearly defined and well-documented o source code/header version strings for use by what(1) or ident(1) -- for facilitation of bug reporting, version verification, daemon- client campatibility checks o client/driver run-time implementation/compatibility tests -- integer and pointer sizes -- endianness o no dead code -- e.g. SHM driver "nsamples"-related cruft o provision in shared memory to specify (variable part of) clockstats output -- client can control clockstats format and content (and frequency of logging) -- can be different for each unit o POSIX mutex for synchronized access to shared memory for updates -- obviates mode 0 / mode 1 / OLDWAY Comments and suggestions are welcome. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP nanokernel, recent experience, PTP
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 timestamping by the kernel and library. I've measured typical time for execution of gettimeofday() and clock_gettime() of several microseconds on desktop systems, with variation in individual times ranging from a couple of microseconds minimum to over a hundred microseconds maximum (embedded systems compiled with special options may be able to do better). Another issue is interrupt latency (e.g. in handling incoming network packets or PPS signals). A third is the transit time for packets between systems -- e.g. with switched gigabit Ethernet, buffers in the switch ports may delay packets from one machine to another. > 3. Why would > people develop PTP (precision time protocol) while nanokernel was > available? PTP requires special hardware (NIC with hardware timestamping support) to achieve performance better than NTP. Equipment designed for PTP typically has such hardware. Without such hardware support, (i.e. PTP on general purpose hardware, NTP), synchronization is affected by software timestamping variability (see above), and PTP w/o the hardware support is comparable in performance to NTP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP nanokernel, recent experience, PTP
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 timestamping by the kernel and library. I've measured typical time for execution of gettimeofday() and clock_gettime() of several microseconds on desktop systems, with variation in individual times ranging from a couple of microseconds minimum to over a hundred microseconds maximum (embedded systems compiled with special options may be able to do better). Another issue is interrupt latency (e.g. in handling incoming network packets or PPS signals). A third is the transit time for packets between systems -- e.g. with switched gigabit Ethernet, buffers in the switch ports may delay packets from one machine to another. > 3. Why would > people develop PTP (precision time protocol) while nanokernel was > available? PTP requires special hardware (NIC with hardware timestamping support) to achieve performance better than NTP. Equipment designed for PTP typically has such hardware. Without such hardware support, (i.e. PTP on general purpose hardware, NTP), synchronization is affected by software timestamping variability (see above), and PTP w/o the hardware support is comparable in performance to NTP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Sole time source in Linux user space.
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 the > time as a single source or I should separate out the Pulse-Per-Second > from the date and time string and configure them as separate sources. It depends (that's the standard answer to all questions ntp-related). It specifically depends on what accuracy and precision you hope to obtain, how you plan to physically interface your source PPS and string information to the device, whether you are stuck with a specific Linux kernel or are willing to recompile from source, which Linux kernel you have, whether you are indeed committed to Linux or could use e.g. FreeBSD instead, how much you are willing and able to tweak your system. > The Pulse-Per-Second is highly reliable, but I can imagine a situation > where the date and time string might not be available. This is > especially a concern if the system shuts down and restarts. The way the reference ntp implementation handles this is to configure two separate sources, with the PPS source using a specific driver which uses a specific (viz. ppsapi) software interface to the hardware (which is typically either a serial port control signal (usu. DCD) or a parallel printer port signal. Although you will find ntp documentation that asserts that there is a ppsapi interface for Linux, that was true of older kernel series with an optional patch; there is not yet a working mainstream implementation for Linux 2.6 series kernels. What little that does exist for 2.6 (as of the last time I looked) consists of partial source code which is not in a source code file, but is instead in a Documentation tree file, and that doesn't do much good even if you move it to where it should be because the serial driver code hasn't yet been interfaced to it. A caveat about interfacing via serial ports; unless you are willing to live with jitter and inaccuracy on the order of 1 million nanoseconds (a.k.a. 1 millisecond), don't even think about a serial-to-USB converter and a USB interface for the PPS signal. USB has no provision for control signals such as DCD; it is polled at 1000 Hz (which leads to the 1 millisecond jitter and inaccuracy). USB = Ugly (dozens of incompatible connectors) Sloppy (1 million nanoseconds worth of slop) Botch. Another caveat is that the ntp algorithms assume gaussian distribution of errors, but typical serial port hardware/drivers result in a non-normal distribution (specifically with a very long one-sided tail resulting from interrupt processing delays), at least with general-purpose (as distinct from real-time) kernels. The samples near the (short, almost triangualar) tail of the other side of the distribution correspond to rapid processing of PPS signals and are what really should be used; the long tail corresponding to delayed processing skews the sample mean, median and other statistical measures which are more suited to a Gaussian distribution. USB (see above) is even worse; the polling essentially results in a flat (rectangular) distribution. There appears to be an unrelated project that attempts to address the non-normal distribution for non-USB sources, but it requires building a custom kernel and the last time I looked there was no support for recent kernels: http://www.cubinlab.ee.unimelb.edu.au/radclock/articles.php Regarding accuracy and precision, most of the ntp reference implementation deals with time to nanosecond precision if the OS kernel supports it. The SHM shared memoy [sic] driver is an exception; it handles microsecond precision only, and multiplies by 1000 to interface to the rest of the ntp code. Specifically for current Linux kernels, there is a related issue in that the glibc header files used by Linux do not properly define macros that indicate nanosecond kernel support, so you'll have to do some tweaking there if you need to build ntp with nanosecond support on Linux. The shared memoy [sic] driver also has a hard-coded interface to ntp which indicates the type of the source; moreover that varies with version (e.g. in the ntp reference implementation version 4.2.6 all shared memory sources are hard-coded to indicate that they are modem sources regardless of what the actual source is; in 4.2.6-p1 that was changed to indicate that all sources are UHF radio sources (such as GPS) regardless of what the actual source is). In theory you could tweak the driver to handle your specific situation and rebuild ntp. > [...] > Is there any place where I can find documentation about how NTP handles > different clocks and different information that clocks may provide? > Where do I find documentation of how to configure these shared memory > time sources? > > Pointers much appreci
[ntp:questions] making sense of stats offset values [or trying to...]
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 ntptrace appears to be broken: 1. peerstats: the sign is unspecified in the documentation, but has been described here as such that adding the offset to the local clock should give time equivalent to the remote peer; i.e. a positive offset means that the local clock is early compared to the remote clock, and a negative offset means that the local clock is late. Is that correct? If so, a clarification to the description in the "monopt" documentation might be helpful to others. 2. loopstats: the distributed documentation is totally unclear. I have found a Sun Microsystems document that describes the offset as "how much time (in seconds) the clock will be adjusted by in the loop cycle". a. Awkward wording notwithstanding, is that correct? b. is the adjustment intended to remove the entire offset between the local clock and the best-guess estimate of UTC, i.e. can the loopstats offset field be interpreted as the offset between the local clock and the best-guess estimate of UTC? Or something else? c. what about the sign in this case? 3. ntptrace output: The man page (oddly enough, with version in the lower left as 4.1.1b-r5) gives an example: % ntptrace localhost: stratum 4, offset 0.0019529, synch distance 0.144135 server2ozo.com: stratum 2, offset 0.0124263, synch distance 0.115784 usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid [let's ignore the missing stratum 3 and the disappearing refid value] and text On each line, the fields are (left to right): the host name, the host stratum, the time offset between that host and the local host (as measured by ntptrace ; this is why it is not always zero for "localhost ")... This is completely baffling: a. what does it mean for the local host to have a time offset from itself? b. are the offset values cached or determined from cached data [if I run ntptrace twice a couple of seconds apart, I get offset values identical from one run to the next down to the last reported digit, while the synchronization distances vary significantly]? c. is it intended that the offset reported by ntptrace bear no resemblance to that reported by ntpq -p and in peerstats?: # ntpq -p remote refid st t when poll reach delay offset jitter = LOCAL(0).LOCL. 10 l 17 64 377 0.0000.000 0.004 +fastener.blilly 192.168.99.703 u 37 64 377 2.8440.722 0.093 *megatron.blilly 18.26.4.105 2 u 27 64 377 2.9270.296 0.122 +wally.blilly.ne 18.103.0.198 2 u 61 64 377 3.0361.352 0.171 # ntptrace localhost: stratum 3, offset 0.000802, synch distance 0.030442 megatron.blilly.net: stratum 2, offset 0.002120, synch distance 0.024161 bonehed.lcs.mit.edu: stratum 1, offset 0.03, synch distance 0.001072, refid 'CDMA' Note that ntpq reports an offset of 0.296 milliseconds from the local host to its system peer, while ntptrace reports an order of magnitude larger offset! The most recent relevant peerstats line is: 54948 73944.514 192.168.99.73 9444 0.000318644 0.002920157 0.004549365 0.57198 which compares reasonably well to ntpq (offset around 300 microseconds, delay around 2.9 milliseconds). Should I really believe what ntptrace says, viz. that the local host is offset from a remote stratum 1 server by a mere 3 microseconds in spite of orders of magnitude larger values of jitter (and that from a program that says the local host is offset from itself by hundreds of microseconds!)? Ultimately I'm trying to do a couple of things: 1. determine if the loopstats offset value can be correlated to something informative about the system time of the local host, such as an estimate of the local clock offset from UTC. 2. determine the best-guess estimate of the offset of a given peer from UTC. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
