Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Aug 2001 23:02:40 -0600
From:      Warner Losh <imp@harmony.village.org>
To:        Luigi Rizzo <rizzo@aciri.org>
Cc:        phk@critter.freebsd.dk, thierry@herbelot.com, hackers@FreeBSD.ORG, peo@sssup.it
Subject:   Re: clock synchronization quality via NTP ? 
Message-ID:  <200108230502.f7N52eW81359@harmony.village.org>
In-Reply-To: Your message of "Wed, 22 Aug 2001 21:53:26 PDT." <200108230453.f7N4rQi52619@iguana.aciri.org> 
References:  <200108230453.f7N4rQi52619@iguana.aciri.org>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200108230453.f7N4rQi52619@iguana.aciri.org> 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 -0000	1.1.1.4
+++ ppi.c	2 Nov 2000 18:21:29 -0000	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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108230502.f7N52eW81359>