Date: Mon, 24 Dec 2001 17:31:45 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, David Greenman <dg@root.com>, Bruce Evans <bde@zeta.org.au>, Mike Silbersack <silby@silby.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/sio sio.c Message-ID: <90234.1009211505@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 24 Dec 2001 02:19:13 PST." <200112241019.fBOAJDO05785@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200112241019.fBOAJDO05785@apollo.backplane.com>, Matthew Dillon wri tes: > All you need to measure interrupt latency is a cheap oscilliscope. > About $60. If the interrupt rate is high enough (11KHz is plenty > high enough, IMHO) you can figure the spread out by eye just by > looking at the scope. You trigger the scope on the start bit and > adjust the timing so the retrigger doesn't occur in the middle of > a character, and you poke a value into the paralell port in the > interrupt service routine and tie that into the second channel. Poof, > instant latency, jitter & spread measurement. Pfft... Instant measurement of lots of random stuff added to the interrupt latency. You have obviously not done this, or if you have, the method is not good enough to reveal the #1 unsolvable problem with interrupt latency. Bruce has correctly identified that problem with a simpler setup btw, but I am giving you the chance to prove me wrong by not telling you what I'm talking about yet. All you have to prove that you have actually done your measurement and analyzed the results is to tell us what this particular source of trouble is. But I'll hand you that our interrupt latency is not _worse_ than what you measure the way you propose above, but having a flicker on an oscilloscope doesn't allow you to do any statistical analysis of the data, in particular things like the Allan Variance and a frequency spectrum is out of your reach. To actually measure interrupt latency, you need a timecounter (or other time-source along the lines that Warner has access to) on a fast bus, minimum PCI, and it has to have a PPS latch. This can be (already is) trivially implemnted in an FPGA like HOT-I from www.vcc.com See /sys/pci/xrpu.c for our driver, send me email if you want the VHDL for the counters. Now feed the same signal to the PPS latch in the FPGA and to the serial or parallel port, use the PPS-api to timestamp the event on your chosen port and on the FPGA timecounter and you will know our interrupt latency into the nanosecond realm. If you want to make it easy for yourself, synthesize a 14.318181818 MHz frequency from an atomic source, inject it into the motherboard PLL chip instead of the 5cent xtal it uses and derive the signal you time from a different atomic source which is detuned 1e-11 or so. Been there. Done that. Gave a WIP talk about it in New Orleans in 1998. The results suck. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?90234.1009211505>