Re: pulse-per-second API status
On Fri, Nov 01, 2013 at 01:06:07PM -0400, Greg Troxel wrote: This patch to netbsd-5 adds pps support to ucom(4), which should enable pps on all usb serial chips that report modem control changes. [...] I am inclined to port this change to -current, compile-test it, and commit it. Objections/comments? I just saw this thread the other day. Please commit this. I think it is a fine idea. --chris
Re: pulse-per-second API status
On Nov 1, 2013, at 12:19 PM, paul_kon...@dell.com wrote: On Nov 1, 2013, at 2:04 PM, Mouse mo...@rodents-montreal.org wrote: ... But it still may not work in the sense of living up to the expectations people have come to have for PPS on serial ports. My worry is not that it's not the best time available in some circumstances. My worry is that putting it into the tree will lead to its getting used as if it were as good as PPS on anything else, leading both to timeservers that claim stratum 1 but give bad chime and to people blaming NetBSD for its crappy PPS support when the real problem is that they don't understand the USB issues and it _looks_ like any other PPS support until you test the resulting time carefully. Not just PPS on serial ports, but PPS on other hardware. I don't know this API. But my first reaction when I saw the designation PPS is to think of GPS timekeeping boxes and other precision frequency sources that have a PPS output. On those devices, the PPS output is divided down from the main oscillator frequency, i.e., you can expect accuracies of 10^-9 for modest price crystal oscillators, 10^-10 to 10^-12 for higher end stuff -- and jitter in the nanosecond range or better. It seems rather confusing to have another interface that goes by the same name but has specs 6 or more orders of magnitude worse. How about a different name that avoids this confusion? Just because the signal has an Allen Variance of 10^-10 doesn't mean that you'll be able to measure each pulse with that precision, or that the tau of that figure is 1s... Most common time counter hardware in SoCs and the like is good to anywhere from hundreds of microseconds to tens of nano seconds. Hundreds of microseconds isn't much worse than the millisecondish USB accuracy. The PPS API even allows for an estimate of the accuracy of the measurements, IIRC, but that may be a higher-level facility of NTP (it has been a few years since I've done this stuff professionally). I don't think there will be any confusion at all, especially if the measured accuracy and variance of this facility is documented. 1ms is quite accurate enough for NTP though. NTP has trouble on the network getting below 1ms of accuracy, especially when there are any hops at all in the topology. It won't be the best NTP server in the world, but it will be accurate enough for most things. If you need more accuracy, get better hardware.. To those saying 'fix NMEA mode to be better': You can't. The characters that spit this code out aren't guaranteed to be at top of second any more than approximately...The exact timing varies from receiver to receiver, and if USB is involved, the same silly delays are present there too, only worse because the message spans USB packets (or likely would since it is just short of 100 characters long IIRC)... And even if you get those issues out of the way, I also believe there's ambiguity in the NMEA standard between the 'on time' point for the NMEA messages. Is it the start of the message, the end? Is is the first transition of the first bit of the message, or the end of the first character? Since it isn't considered a precision signal, nobody times it exactly (or didn't a few years ago). It is useful, at best, for knowing what time the external PPS is about to be or just was... So adding support to ucom isn't a horrible idea, as long as expectations are managed... Warner
Re: pulse-per-second API status
On Fri, 01 Nov 2013, Greg Troxel wrote: But if NetBSD enables PPS on ucom, there's going to be an expectation that it is good enough for stratum-1 timekeeping, like PPS on real serial ports. I don't think there's any such expectation created. [...] People who expect the same as serial PPS are confused, and we are not responsible for that. I think that PPS on a device with very high interrupt latency is sufficiently similar to PPS on a device with low interrupt latency that it deserves to have the same API. I don't think it even needs a sysctl to enable it. I think that it just needs careful documentation, in ucom(4) and wherever we document the PPS API. Maybe the documentation for applications like ntpd should also warn against using PPS on USB interfaces. --apb (Alan Barrett)
Re: pulse-per-second API status
On Fri, 01 Nov 2013, paul_kon...@dell.com wrote: I don't know this API. But my first reaction when I saw the designation PPS is to think of GPS timekeeping boxes and other precision frequency sources that have a PPS output. On those devices, the PPS output is divided down from the main oscillator frequency, i.e., you can expect accuracies of 10^-9 for modest price crystal oscillators, 10^-10 to 10^-12 for higher end stuff -- and jitter in the nanosecond range or better. It seems rather confusing to have another interface that goes by the same name but has specs 6 or more orders of magnitude worse. How about a different name that avoids this confusion? It's exactly the same interface. Something in the external timekeeping box is hooked up to one of the modem control lines on a serial port; the modem control line is hooked up to an interrupt (or something like an interrupt); the interrupt is hooked up to something in the kernel that records the time that the interrupt occurred. The difference is only one of interrupt latency. With plain old serial ports, the modem control line can be hooked up to a CPU interrupt pin using low-latency electronics. With USB, if I have understood correctly, the interrupt is faked by some sort of polling interface with much higher latency and jitter. --apb (Alan Barrett)
Re: pulse-per-second API status
On Fri, 1 Nov 2013 14:48:51 -0400
Terry Moore t...@mcci.com wrote:
But using a serial port handshaking line over an emulated com port over USB
is not likely to be terribly wonderful. Long-term accuracy (tick count)
probably no problem, but jitter it will depend on how that's filtered.
That's the key. Once I did a DCF77 decoder in an Atmel AVR. (DCF77 is a
radio station that sends a PPS signal plus BCD encoded absolute time.)
The cheap radio reciver had a considerably jitter. So I simply summed up
the PPS count from the receiver and the tics from the local quarz clock
over the period of hours. Some ms of jitter are negligible compared to
several hours. Using this I was able to calibrate the local quarz
oscilator down into the ppm range. I.e. I was able to notice the
temperature drift of the local quarz oscilator.
If you know what to do, even a jitterish PPS signal can be of good use.
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
Re: pulse-per-second API status
On 2 Nov, 2013, at 03:33 , Alan Barrett a...@cequrux.com wrote: On Fri, 01 Nov 2013, Greg Troxel wrote: But if NetBSD enables PPS on ucom, there's going to be an expectation that it is good enough for stratum-1 timekeeping, like PPS on real serial ports. I don't think there's any such expectation created. [...] People who expect the same as serial PPS are confused, and we are not responsible for that. I think that PPS on a device with very high interrupt latency is sufficiently similar to PPS on a device with low interrupt latency that it deserves to have the same API. I don't think it even needs a sysctl to enable it. I think that it just needs careful documentation, in ucom(4) and wherever we document the PPS API. Maybe the documentation for applications like ntpd should also warn against using PPS on USB interfaces. I think this is correct. How accurate is accurate enough is a value judgement which the operating system probably shouldn't be making for you. I was going to point out that the TI processor on my Beaglebone board has a hardware timestamp peripheral which eliminates interrupt latency entirely, and hence can be accurate to single digit nanoseconds rather than just single digit microseconds (or milliseconds), but I wouldn't expect this fact to make anyone want to add sysctl warnings about how comparatively sloppy even the low interrupt latency devices are. I think everyone should be informed about what is better and what is worse, but in the end I don't think you should be denied, or even inconvenienced by, the use of the hardware you do have just because of the existence of much better hardware that you don't have. Dennis Ferguson
Re: pulse-per-second API status
On 31 Oct 2013 at 19:52, Greg Troxel wrote: I just got a Navisys GR601-W GPS receiver, which provides a PPS signal on DCD via a PL2303. Looking into using it with ntpd and gpsd on NetBSD, a bit of work is needed. This note describes my impressions of what's needed; please let me know if I'm off or if any of this is controversial. * sys/timepps.h NetBSD has sys/timepps.h for RFC2783 support, but the comments reference an older internet-draft. So it needs to be checked for conformance and at least the comments updated. * compare with FreeBSD and OpenBSD It's likely pps support in FreeBSD is better, and this needs checking as it should be easy to snarf the improvements. * ucom(4) needs pps support On -5, trying to use pps on a 16450 serial line (i386) to which no PPS is connected appears to work right. But the ioctls error on ucom(4) interfaces. Hi I'm currently on NetBSD-6 i386 with a Sure GPS and ntpd 4.2.7p393 from www.ntp.org running from /usr/local/bin. Kernel is built with options PPS_SYNC and offsets are usually within +/- 5 usec but with blips of 100 usec or more when system is under heavy load (eg. as just now after compile of a couple of packages). I've not bothered to check on any improvements there might be with PPS from FreeBSD but would be interested. Main problem here is lack of temperature control of my house and I intend to make an add on ovened system clock source. David Script started on Fri Nov 1 14:40:49 2013 bash-4.2$ /usr/local/bin/ntpq -c rv -p associd=0 status=011d leap_none, sync_pps, 1 event, kern, version=ntpd 4.2.7p393@1.2483-o Wed Oct 30 09:50:29 UTC 2013 (1), processor=i386, system=NetBSD/6.1_STABLE, leap=00, stratum=1, precision=-17, rootdelay=0.000, rootdisp=400.015, refid=PPSb, reftime=d61e3c1b.244b6264 Fri, Nov 1 2013 14:41:31.141, clock=d61e3c1c.cf0b29e8 Fri, Nov 1 2013 14:41:32.808, peer=55992, tc=4, mintc=3, offset=-0.012560, frequency=-35.852, sys_jitter=0.007629, clk_jitter=0.004, clk_wander=0.010, tai=35, leapsec=20120701, expire=20131201 remote refid st t when poll reach delay offset jitter == -GPS_NMEA(2) .GPSb. 7 l 29 64 3770.000 20.659 4.820 oPPS(2) .PPSb. 0 l1 16 3770.000 - 0.013 0.008
Re: pulse-per-second API status
* ucom(4) needs pps support It does? I thought USB introduced delays which are both uncertain and, in this context, large, and thus doing PPS on a ucom didn't work (in that it inherently produces exactly the sort of symptom described - basically, a recipe for bad timekeeping). Am I wrong in thinking that? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: pulse-per-second API status
This patch to netbsd-5 adds pps support to ucom(4), which should enable
pps on all usb serial chips that report modem control changes. It's
entirely cut/paste from com(4) except that MSR_DCD became UMSR_DCD.
I have tested it with a GR301-W and the in-tree (-5) ntpd. I am seeing
offsets of about -100ms from the pps signal relative to over-the-net,
but I don't think that's due to a bug in the below patch.
I am inclined to port this change to -current, compile-test it, and
commit it. Objections/comments?
Index: sys/dev/usb/ucom.c
===
RCS file: /cvsroot/src/sys/dev/usb/ucom.c,v
retrieving revision 1.77
diff -u -p -r1.77 ucom.c
--- sys/dev/usb/ucom.c 24 May 2008 16:40:58 - 1.77
+++ sys/dev/usb/ucom.c 1 Nov 2013 15:47:48 -
@@ -49,6 +49,7 @@ __KERNEL_RCSID(0, $NetBSD: ucom.c,v 1.7
#include sys/device.h
#include sys/poll.h
#include sys/kauth.h
+#include sys/timepps.h
#if defined(__NetBSD__)
#include rnd.h
#if NRND 0
@@ -124,6 +125,8 @@ struct ucom_softc {
int sc_refcnt;
u_char sc_dying; /* disconnecting */
+ struct pps_statesc_pps_state; /* pps state */
+
#if defined(__NetBSD__) NRND 0
rndsource_element_t sc_rndsource; /* random source */
#endif
@@ -358,6 +361,13 @@ ucomopen(dev_t dev, int flag, int mode,
ucom_status_change(sc);
+ /* Clear PPS capture state on first open. */
+ mutex_spin_enter(timecounter_lock);
+ memset(sc-sc_pps_state, 0, sizeof(sc-sc_pps_state));
+ sc-sc_pps_state.ppscap = PPS_CAPTUREASSERT | PPS_CAPTURECLEAR;
+ pps_init(sc-sc_pps_state);
+ mutex_spin_exit(timecounter_lock);
+
/*
* Initialize the termios status to the defaults. Add in the
* sticky bits from TIOCSFLAGS.
@@ -668,6 +678,20 @@ ucom_do_ioctl(struct ucom_softc *sc, u_l
*(int *)data = ucom_to_tiocm(sc);
break;
+ case PPS_IOC_CREATE:
+ case PPS_IOC_DESTROY:
+ case PPS_IOC_GETPARAMS:
+ case PPS_IOC_SETPARAMS:
+ case PPS_IOC_GETCAP:
+ case PPS_IOC_FETCH:
+#ifdef PPS_SYNC
+ case PPS_IOC_KCBIND:
+#endif
+ mutex_spin_enter(timecounter_lock);
+ error = pps_ioctl(cmd, data, sc-sc_pps_state);
+ mutex_spin_exit(timecounter_lock);
+ break;
+
default:
error = EPASSTHROUGH;
break;
@@ -781,9 +805,18 @@ ucom_status_change(struct ucom_softc *sc
old_msr = sc-sc_msr;
sc-sc_methods-ucom_get_status(sc-sc_parent, sc-sc_portno,
sc-sc_lsr, sc-sc_msr);
- if (ISSET((sc-sc_msr ^ old_msr), UMSR_DCD))
+ if (ISSET((sc-sc_msr ^ old_msr), UMSR_DCD)) {
+ mutex_spin_enter(timecounter_lock);
+ pps_capture(sc-sc_pps_state);
+ pps_event(sc-sc_pps_state,
+ (sc-sc_msr UMSR_DCD) ?
+ PPS_CAPTUREASSERT :
+ PPS_CAPTURECLEAR);
+ mutex_spin_exit(timecounter_lock);
+
(*tp-t_linesw-l_modem)(tp,
ISSET(sc-sc_msr, UMSR_DCD));
+ }
} else {
sc-sc_lsr = 0;
/* Assume DCD is present, if we have no chance to check it. */
pgp4mRFiLfqgl.pgp
Description: PGP signature
Re: pulse-per-second API status
* ucom(4) needs pps support It does? I thought USB introduced delays which are both uncertain and, in this context, large, [...] The delays introduced by USB are said to be on the order of 1 ms. I find said to be somewhat less than reassuring. It's been a while since I read the relevant doc, but I think this depends heavily on how often the host interface is configured to poll the device. The fuzzy memory also reports that there are different intervals configurable; I don't remember what they were, but I also don't know what NetBSD does for that, so that doesn't mean much. Also, see below - 1ms strikes me as pretty bad for PPS. [in another message] This patch to netbsd-5 adds pps support to ucom(4), [...] I have tested it with a GR301-W and the in-tree (-5) ntpd. I am seeing offsets of about -100ms [...] 100ms is a lot worse than 1ms, and surely bad enough that stamping the implicit approval of it's in the tree on this is a bad idea. Or do you really think your network is bad enough that 99ms of that is coming from network asymmetry? PPS with a lot of wobble in it may be better than a crappy network connection. But if NetBSD enables PPS on ucom, there's going to be an expectation that it is good enough for stratum-1 timekeeping, like PPS on real serial ports. You, Greg, know better. J-randoms who see what looks to them like PPS support on ucom won't. [back to the first message] So it depends on whether 1 ms of fuzz is doesn't work. Not quite: it also depends on how close (your impression of) what [is] said to be is to reality. I would say that if the next best option is worse than that (nmea timecode over the same USB, or asymmetic delays over the Internet), then it does work, even if a real serial port would be better. It does work in the sense that it's the best chime available in that dismal a situation. But it still may not work in the sense of living up to the expectations people have come to have for PPS on serial ports. My worry is not that it's not the best time available in some circumstances. My worry is that putting it into the tree will lead to its getting used as if it were as good as PPS on anything else, leading both to timeservers that claim stratum 1 but give bad chime and to people blaming NetBSD for its crappy PPS support when the real problem is that they don't understand the USB issues and it _looks_ like any other PPS support until you test the resulting time carefully. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: pulse-per-second API status
[...PPS...real serial hardware] Not just PPS on serial ports, but PPS on other hardware. Well, a serial port is the only hardware I'm familiar with that gets used for getting PPS into general-purpose computers; while of course there are lots of other possibilities, I don't recall hearing any others mentioned on the timekeeping lists I'm on. (Not that I've gone looking, mind you; this is just what I've heard mentioned.) I don't know this API. But my first reaction when I saw the designation PP$ As I understand it, that - especially the GPS version - is exactly what's under discussion here. The PPS line gets hooked to a serial-line pin that can be configured to generate an interrupt (carrier detect is a popular one, AIUI) and the kernel captures the relevant timestamp off that interrupt. In normal operation, interrupt latency is the major source of jitter by the time the PPS signal (which is often, as you note, accurate to the level where wire length is important) makes it through to the timekeeping code. With a bit of care (such as capturing a timestamp in the hard interrupt handler), this error can be kept relatively low - well below millisecond levels on many machines. But USB's the host drives everything design, while fine for a lot of things, fails badly here, introducing an unavoidable and (in this context) large delay between the line changing and the kernel noticing the change. This could be corrected for. But that requires designed-for-PPS USB hardware, which normal serial ports don't have. (For example, if the USB device had a high-frequency oscillator sampled when the signal changed and when communicating with the host, with all timestamps passed up to the host, this could be used to compute an accurate timestamp despite USB's issues.) It seems rather confusing to have another interface that goes by the same na$ Because it's not really another interface. The 6 orders of magnitude worse is exactly the reason I think it shouldn't look to a naïve user like PPS works on ucom. Inaccuracy to somewhere around the microsecond level is unavoidable without special-purpose hardware, simply because of interrupt latency. I'm worried that USB will make that a lot worse, and most people will not be competent to expect that. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
RE: pulse-per-second API status
Hi all, I do USB for a living. USB is not a very good way to do PPS synchronization if you're looking for usec resolution -- there are huge and unpredictable delays that can be introduced from a number of sources. Some of the sources are inherent and some are due to system issues. Sources of variation: *) the USB com port may be using an interrupt pipe to report changes in the handshaking lines. Depending on the vendor, there may be variation in the requested frequency of interrupt polling. On high-speed and superspeed devices, USB polling may occur as quickly as every 125us; on full and low-speed devices, the polling interval drops to 1ms max. However, when you get polled within a given 125us or 1ms window will vary based on other devices on the bus. You cannot control this, in general, unless you dedicate a host controller and only plug one device into the bus. Furthermore, even on an unloaded bus, your sampling (polling) frequency will be slaved to the clock of the USB host controller, with additional jitter introduced by the clock of the USB device controller. *) the USB com port may be using a bulk pipe to report changes in the handshaking lines. On a bus with multiple devices, the polling for any particular endpoint will have gaps that are not predictable. Even on an unloaded bus, there are gaps close to end of each frame or microframe during which polls will not occur. *) after the USB I/O operation completes at the hardware, there is unpredictable latency introduced by the USB subsystem. This latency often applies even if you have a dedicated USB host controller (because you have a limited number of CPUs, and even with concurrent processing, activity on other USB busses will often slow down completion processing). Audio devices get around this by disciplining the clock at a higher level. It is easy to imagine a USB device that measures long term clock rate on the bus (using the SOF mechanisms or simply by pushing data over an isochronous pipe) and then feeds back clock difference information. (The device would schedule data to go to the host once per disciplined millisecond; this would either cause gaps in the isoch traffic, or overruns, which would be reported.) The driver on the host would use this to monitor clock drift and feed the information into the kernel clock. But using a serial port handshaking line over an emulated com port over USB is not likely to be terribly wonderful. Long-term accuracy (tick count) probably no problem, but jitter it will depend on how that's filtered. I suspect that the kernel's clock discipline loop is not likely to be happy if there's jitter on this particular reference. Best regards, --Terry -Original Message- From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On Behalf Of Mouse Sent: Friday, November 01, 2013 14:05 To: tech-kern@NetBSD.org Subject: Re: pulse-per-second API status * ucom(4) needs pps support It does? I thought USB introduced delays which are both uncertain and, in this context, large, [...] The delays introduced by USB are said to be on the order of 1 ms. I find said to be somewhat less than reassuring. It's been a while since I read the relevant doc, but I think this depends heavily on how often the host interface is configured to poll the device. The fuzzy memory also reports that there are different intervals configurable; I don't remember what they were, but I also don't know what NetBSD does for that, so that doesn't mean much. Also, see below - 1ms strikes me as pretty bad for PPS. [in another message] This patch to netbsd-5 adds pps support to ucom(4), [...] I have tested it with a GR301-W and the in-tree (-5) ntpd. I am seeing offsets of about -100ms [...] 100ms is a lot worse than 1ms, and surely bad enough that stamping the implicit approval of it's in the tree on this is a bad idea. Or do you really think your network is bad enough that 99ms of that is coming from network asymmetry? PPS with a lot of wobble in it may be better than a crappy network connection. But if NetBSD enables PPS on ucom, there's going to be an expectation that it is good enough for stratum-1 timekeeping, like PPS on real serial ports. You, Greg, know better. J-randoms who see what looks to them like PPS support on ucom won't. [back to the first message] So it depends on whether 1 ms of fuzz is doesn't work. Not quite: it also depends on how close (your impression of) what [is] said to be is to reality. I would say that if the next best option is worse than that (nmea timecode over the same USB, or asymmetic delays over the Internet), then it does work, even if a real serial port would be better. It does work in the sense that it's the best chime available in that dismal a situation. But it still may not work in the sense of living up to the expectations people have come to have for PPS on serial ports. My worry
Re: pulse-per-second API status
Mouse mo...@rodents-montreal.org writes: I now think the 100ms was due to the wrong polarity on the pps signal From this device. After fixing that, I'm seeing times that are within 5 ms (well within expected network asymmetry), and currently the jitter is 0.169 ms. (I still need to figure out if I have a bug in the code that inverts the DCD sense, vs the device being odd.) I find said to be somewhat less than reassuring. It's been a while since I read the relevant doc, but I think this depends heavily on how often the host interface is configured to poll the device. The fuzzy memory also reports that there are different intervals configurable; I don't remember what they were, but I also don't know what NetBSD does for that, so that doesn't mean much. By 'said to be', I meant people on the gpsd list who are using this on other operating systems and looking at what happens. Also, see below - 1ms strikes me as pretty bad for PPS. Sure, but it's vastly better than nmea timecode, which is what the other choice is. But if NetBSD enables PPS on ucom, there's going to be an expectation that it is good enough for stratum-1 timekeeping, like PPS on real serial ports. I don't think there's any such expectation created. I would say that if the next best option is worse than that (nmea timecode over the same USB, or asymmetic delays over the Internet), then it does work, even if a real serial port would be better. It does work in the sense that it's the best chime available in that dismal a situation. It's not that dismal - it's pretty typical. But it still may not work in the sense of living up to the expectations people have come to have for PPS on serial ports. People who expect the same as serial PPS are confused, and we are not responsible for that. 1 ms (if it is that, and it seems to be) is decent compared to non-local networks. And it's better than interpreting NMEA or some other timecode on serial, and one can configure that to be s1. If the facility were such that no reasonable person would ever use it, that would be something else, but it's far better than that. I'll also try this on -6 at work, and compare to s1 at MIT that's only 2ms RTT away. pgpyZUhhtHJQh.pgp Description: PGP signature
Re: pulse-per-second API status
Thanks for the comments. Terry Moore t...@mcci.com writes: USB is not a very good way to do PPS synchronization if you're looking for usec resolution -- there are huge and unpredictable delays that can be introduced from a number of sources. Agreed, but that's not the question on the table. It's Should NetBSD support gathering timestamps from DCD transitions on ucom(4) devices using the RFC2783 API, or should it refuse to support that (on the theory that we are certain that anyone who tries to use it is thereby worse off, even though we do not understand their situation)?. Thanks for the summary of issues. I did not know all of those details, but did not find them too surprising. Still, it seems that there will often be less than 1 ms of trouble in many situations. But using a serial port handshaking line over an emulated com port over USB is not likely to be terribly wonderful. Long-term accuracy (tick count) probably no problem, but jitter it will depend on how that's filtered. I suspect that the kernel's clock discipline loop is not likely to be happy if there's jitter on this particular reference. The normal config would use ntp, which has filtering, and in my case it seems decent, showing 155 us of jitter (it varies, but almost always seems under 500 us). remote refid st t when poll reach delay offset jitter == oPPS(0) .BLOX. 0 l9 16 3770.0001.359 0.155 +[redacted s1] .TRUE. 1 u 19 64 377 95.7506.153 0.797 I should hook up a serial pps also, to compare, in addition to trying this within a few network ms of a believed-ok s1. But the above seems better than reading a serial timecode with a fudge. pgpjsG_R1TQj_.pgp Description: PGP signature
Re: pulse-per-second API status
Also, see below - 1ms strikes me as pretty bad for PPS. Sure, but it's vastly better than nmea timecode, which is what the other choice is. Oh, sure; as I said in other words upthread, I'm not arguing that it's not a good choice for you - I'm arguing that it's not a good choice for the main tree. But if NetBSD enables PPS on ucom, there's going to be an expectation that it is good enough for stratum-1 timekeeping, like PPS on real serial ports. I don't think there's any such expectation created. If I didn't know enough about USB to know how unavoidable some of its delays were, I'd have such an expectation in that situation. It does work in the sense that it's the best chime available in that dismal a situation. It's not that dismal - it's pretty typical. Well, when I wrote that, I was going on the 100ms figure; if your network is so bad that NTP can't do better than 100ms, I think it's fair to call that `dismal'. But it still may not work in the sense of living up to the expectations people have come to have for PPS on serial ports. People who expect the same as serial PPS are confused, In some respects... and we are not responsible for that. ...my argument is that NetBSD _would_ be responsible for that, by making this look just like PPS on any other serial port, right up until discovering that the resulting chime is bad. 1 ms (if it is that, and it seems to be) is decent compared to non-local networks. It is. But for stratum 1, which is what PPS normally drives, it's pretty awful. And it's better than interpreting NMEA or some other timecode on serial, and one can configure that to be s1. I'd argue that should be fixed, then. Of course, I'm not the one doing the work, nor the one passing on it, nor the one taking the flak if it turns out I'm right, nor even someone going to be using it, so it's no skin off my nose. I've said my piece and I'll let you and the rest of the NetBSD people decide what to do; pointing out a risk is all I feel I need to do here - whether you want to take it is up to you. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: pulse-per-second API status
On Nov 1, 2013, at 2:04 PM, Mouse mo...@rodents-montreal.org wrote: ... But it still may not work in the sense of living up to the expectations people have come to have for PPS on serial ports. My worry is not that it's not the best time available in some circumstances. My worry is that putting it into the tree will lead to its getting used as if it were as good as PPS on anything else, leading both to timeservers that claim stratum 1 but give bad chime and to people blaming NetBSD for its crappy PPS support when the real problem is that they don't understand the USB issues and it _looks_ like any other PPS support until you test the resulting time carefully. Not just PPS on serial ports, but PPS on other hardware. I don't know this API. But my first reaction when I saw the designation PPS is to think of GPS timekeeping boxes and other precision frequency sources that have a PPS output. On those devices, the PPS output is divided down from the main oscillator frequency, i.e., you can expect accuracies of 10^-9 for modest price crystal oscillators, 10^-10 to 10^-12 for higher end stuff -- and jitter in the nanosecond range or better. It seems rather confusing to have another interface that goes by the same name but has specs 6 or more orders of magnitude worse. How about a different name that avoids this confusion? paul
RE: pulse-per-second API status
I wasn't commenting on advisability of putting it into NetBSD. Just responding because I had, for a change, something relevant to contribute. (I actually know, in this case, what I'm talking about!) If the time info is presented into NTP using the same interface that network packets use, then jitter will be pretty well damped (and will be less, in any case, than typical network packet transport jitter). It is totally an application question as to whether this is good enough. I was assuming that, since the jitter on local interrupts is much less than on network packets, that there might be a different PLL tracking the data, as there are lots of tradeoffs here. But if it works well, by all means use it. And I know Mouse is more careful than I tend to be about terminology and so forth; he is, if I understand correctly, arguing that PPS directly connected is a lot different than PPS over USB, and so should be called something else. I don't have an opinion on that. I believe that for critical applications you'll get much less jitter using PPS directly connected; but I'd have to do experiments and my day job calls Best regards, --Terry -Original Message- From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On Behalf Of Greg Troxel Sent: Friday, November 01, 2013 15:30 To: Terry Moore Cc: tech-kern@NetBSD.org Subject: Re: pulse-per-second API status Thanks for the comments. Terry Moore t...@mcci.com writes: USB is not a very good way to do PPS synchronization if you're looking for usec resolution -- there are huge and unpredictable delays that can be introduced from a number of sources. Agreed, but that's not the question on the table. It's Should NetBSD support gathering timestamps from DCD transitions on ucom(4) devices using the RFC2783 API, or should it refuse to support that (on the theory that we are certain that anyone who tries to use it is thereby worse off, even though we do not understand their situation)?. Thanks for the summary of issues. I did not know all of those details, but did not find them too surprising. Still, it seems that there will often be less than 1 ms of trouble in many situations. But using a serial port handshaking line over an emulated com port over USB is not likely to be terribly wonderful. Long-term accuracy (tick count) probably no problem, but jitter it will depend on how that's filtered. I suspect that the kernel's clock discipline loop is not likely to be happy if there's jitter on this particular reference. The normal config would use ntp, which has filtering, and in my case it seems decent, showing 155 us of jitter (it varies, but almost always seems under 500 us). remote refid st t when poll reach delay offset jitter == oPPS(0) .BLOX. 0 l9 16 3770.0001.359 0.155 +[redacted s1] .TRUE. 1 u 19 64 377 95.7506.153 0.797 I should hook up a serial pps also, to compare, in addition to trying this within a few network ms of a believed-ok s1. But the above seems better than reading a serial timecode with a fudge.
Re: pulse-per-second API status
On Nov 1, 2013, at 12:53 PM, Mouse mo...@rodents-montreal.org wrote: Also, see below - 1ms strikes me as pretty bad for PPS. Sure, but it's vastly better than nmea timecode, which is what the other choice is. Oh, sure; as I said in other words upthread, I'm not arguing that it's not a good choice for you - I'm arguing that it's not a good choice for the main tree. I'm thinking of a middle ground. Maybe only make it enabled if you enabled a sysctl variable. sysctl -w hw.ucom0.enable_pps=1 That way you have to explicit enable and have it documented in the ucom man page about its problems.
Re: pulse-per-second API status
I'm not arguing that it's not a good choice for you - I'm arguing that it's not a good choice for the main tree. I'm thinking of a middle ground. Maybe only make it enabled if you enabled a sysctl variable. What's this? Interjecting a reasonable suggestion into an on-list disagreement? Heavens! Didn't you know that's not the NetBSD way? Seriously, this - or something of the sort - actually makes a lot of sense to me as a resolution, here. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: pulse-per-second API status
I don't know this API. But my first reaction when I saw the designation PPS is to think of GPS timekeeping boxes and other precision frequency sources that have a PPS output. On those devices, the PPS output is divided down from the main oscillator frequency, i.e., you can expect accuracies of 10^-9 for modest price crystal oscillators, 10^-10 to 10^-12 for higher end stuff -- and jitter in the nanosecond range or better. Yes, I have a GPS receiver with a precise pps signal inside that hooks it up to DCD on a pl2303 usb/serial chip. You can't expect 1 ns; typically GPS receivers are specified to something closer to 50 ns. The receiver I'm using is specifided at 30 ns RMS (before USB). As for the API, see RFC2783, which explicitly conceptually supports arbitrary sources. Other than the fact that there's ~1ms of USB fuzz (vs unknown (but ~surely better) serial port behavior), this is the same thing as serial pps. As to enabling it, to use this one either has to to write a program to use the time_pps interface in sys/timepps.h, or make a symlink in /dev and add a line to ntpd, which requires searching the web to find documentation. This isn't the sort of thing that happens by accident. And enabling it simply means that a user-space program can get timestamps -- it doesn't set the clock, unless one calls a further API procedure (which the spec says is privileged). It's not like this is changing behavior of existing systems, which would be a good case for a sysctl. pgplqPR_q81DP.pgp Description: PGP signature
Re: pulse-per-second API status
Terry Moore t...@mcci.com writes: If the time info is presented into NTP using the same interface that network packets use, then jitter will be pretty well damped (and will be less, in any case, than typical network packet transport jitter). It is totally an application question as to whether this is good enough. I was assuming that, since the jitter on local interrupts is much less than on network packets, that there might be a different PLL tracking the data, as there are lots of tradeoffs here. But if it works well, by all means use it. ntpd seems to have adaptive means to decide how to cope, and this is pretty well shaken out. It switches from PLL to FLL. It's fair to be skeptical here, but it's easy to get carried away, as it's infrequent to get ms-level accuracy synchronzing across other than a local network. And I know Mouse is more careful than I tend to be about terminology and so forth; he is, if I understand correctly, arguing that PPS directly connected is a lot different than PPS over USB, and so should be called something else. I don't have an opinion on that. But PPS means pulse per second, which refers to the signal before it enters the computer. There's a standard Pulse-Per-Second API that is agnostic with respect to connection means. It doesn't mean PPS connected over serial with very small interrupt latency, even though that's the conclusion many jump to. I believe that for critical applications you'll get much less jitter using PPS directly connected; but I'd have to do experiments and my day job calls I think you're totally right on that point, and I didn't mean to suggest otherwise. pgp0hk4IrtPX9.pgp Description: PGP signature
