Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]> Luigi Rizzo writes:
: Is this the case ? And if so, what is the "fast interrupt hack" that you
: are mentioning and how would it improve things ?
Yes. I think so. We were measuring on a 5x86 at 133MHz, so the
effect would be exagerated more.
The hack that we did was
Index: ppi.c
===
RCS file: /base/FreeBSD-tsc-4/sys/dev/ppbus/ppi.c,v
retrieving revision 1.1.1.4
retrieving revision 1.4
diff -u -r1.1.1.4 -r1.4
--- ppi.c 2 Nov 2000 02:30:30 - 1.1.1.4
+++ ppi.c 2 Nov 2000 18:21:29 - 1.4
@@ -264,6 +264,7 @@
device_t ppidev = UNITODEVICE(unit);
device_t ppbus = device_get_parent(ppidev);
int res;
+ int itype;
if (!ppi)
return (ENXIO);
@@ -279,8 +280,14 @@
#ifdef PERIPH_1284
if (ppi->intr_resource) {
/* register our interrupt handler */
- BUS_SETUP_INTR(device_get_parent(ppidev), ppidev,
ppi->intr_resource,
- INTR_TYPE_TTY, ppiintr, dev, &ppi->intr_cookie);
+#ifdef PPB_USE_FAST_INTR
+ itype = INTR_TYPE_TTY | INTR_TYPE_FAST;
+#else
+ itype = INTR_TYPE_TTY;
+#endif
+ BUS_SETUP_INTR(device_get_parent(ppidev), ppidev,
+ ppi->intr_resource, itype, ppiintr, dev,
+ &ppi->intr_cookie);
}
#endif /* PERIPH_1284 */
}
And we created a PPB_USE_FAST_INTR option.
Come to think of it, we weren't measuring at the FreeBSD assembler
point, but in the actual interrupt handler. And the clock interrupt
would only be masked if interrupts were turned off (which can happen
in the SIO routines for microseconds at a time) or if we were at
splhigh, and got 2 irq0 interrupts. The second one would be delayed
because we'd turn off irq0 at the PIC on the second one.
Looking at the above, I suspect that we could have gotten even better
results if we made it INTR_TYPE_MISC. This would involve shooting the
parallel port for printers in the head (since I think it needs to run
at spltty to keep invariants in the rest of the driver happy), but
given the application that we had, we certainly didn't care...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
> beyond "normal HVAC" and stock xtals on the motherboard. This is > after we've done the fast interrupt hack. Without it, the other > system activity was causing enough interrupt latncy variance that we > would see more like +- 80us with outliers way off in the weeds > (+- just under 10ms!). Warner, this sounds related to a problem we are having... a student of mine is seeing sporadic but relatively large (~50-100us) variations in the period of clock interrupts (int0 calls to the assembly routine). This is in the assembler part of the interrupt service routine, so the only reason I can see for these variations is that there are some significantly large sections of code (this is a 750 MHz box) which run with interrupts disable on the CPU. Is this the case ? And if so, what is the "fast interrupt hack" that you are mentioning and how would it improve things ? thanks luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <46651.998541806@critter> Poul-Henning Kamp writes: : In message <[EMAIL PROTECTED]>, Warner Losh writes: : : >: More precisely : is it reasonable to hope having a system clock not : >: farther from the GPS clock by more than 50 micro-seconds ? : : 50 microseconds should be feasible provided that you either : provide a very stable temperature or replace the 14.318 MHz : xtal on the motherboard with a something more stable. Yea. I just took a look at the data that we have, and we're seeing more like +- 15us on machines here without temerpature stability beyond "normal HVAC" and stock xtals on the motherboard. This is after we've done the fast interrupt hack. Without it, the other system activity was causing enough interrupt latncy variance that we would see more like +- 80us with outliers way off in the weeds (+- just under 10ms!). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]>, Warner Losh writes: >: More precisely : is it reasonable to hope having a system clock not >: farther from the GPS clock by more than 50 micro-seconds ? 50 microseconds should be feasible provided that you either provide a very stable temperature or replace the 14.318 MHz xtal on the motherboard with a something more stable. >PC hardware really sucks for timing. Tell me about it... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]> Wilko Bulte writes: : On Wed, Aug 22, 2001 at 09:47:34PM +0200, Thierry Herbelot wrote: : > Hello, : > : > I know FreeBSD can be used with great success for timing solutions (at : > least two core members do it ?). : > : > has someone some performance data of the quality of system clock : > synchronization, while using NTPd with a GPS reveiver and a hard 1PPS : > signal ? : > : > More precisely : is it reasonable to hope having a system clock not : > farther from the GPS clock by more than 50 micro-seconds ? : : Talk to Poul-Henning, he is the clock/time expert ([EMAIL PROTECTED]). : Poul used to have some nice Web pages around on this subject but they : were killed in a disk crash IIRC. http://phk.freebsd.dk/rover.html used to be that URL... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
In message <[EMAIL PROTECTED]> Thierry Herbelot writes: : I know FreeBSD can be used with great success for timing solutions (at : least two core members do it ?). Well, there's one core member, and a second committer. Or was until a few days ago... : has someone some performance data of the quality of system clock : synchronization, while using NTPd with a GPS reveiver and a hard 1PPS : signal ? : : More precisely : is it reasonable to hope having a system clock not : farther from the GPS clock by more than 50 micro-seconds ? It depends on the machine. We had troubles with 486-class hardware getting below a tens microseconds for extended periods of time. Part of this was due resolution of the timer used in the sytem. Part of it was due to thermal variance in the temperature. Part of it was due to the extremely crappy oscillator that was on the board. And we also had to hack the parallel port driver to use fast interrupts. Otherwise the interrupt latency variance caused too much jitter. Or at least enough jitter to measure and be concerned about. We've not repated the experiment now that pentium class hardware is available, which we think will yield much better results. PC hardware really sucks for timing. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clock synchronization quality via NTP ?
On Wed, Aug 22, 2001 at 09:47:34PM +0200, Thierry Herbelot wrote: > Hello, > > I know FreeBSD can be used with great success for timing solutions (at > least two core members do it ?). > > has someone some performance data of the quality of system clock > synchronization, while using NTPd with a GPS reveiver and a hard 1PPS > signal ? > > More precisely : is it reasonable to hope having a system clock not > farther from the GPS clock by more than 50 micro-seconds ? Talk to Poul-Henning, he is the clock/time expert ([EMAIL PROTECTED]). Poul used to have some nice Web pages around on this subject but they were killed in a disk crash IIRC. -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
clock synchronization quality via NTP ?
Hello, I know FreeBSD can be used with great success for timing solutions (at least two core members do it ?). has someone some performance data of the quality of system clock synchronization, while using NTPd with a GPS reveiver and a hard 1PPS signal ? More precisely : is it reasonable to hope having a system clock not farther from the GPS clock by more than 50 micro-seconds ? -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
