Date: Thu, 08 Nov 2001 09:51:36 -0700 From: Warner Losh <imp@harmony.village.org> To: Sansonetti Laurent <lorenzo@linuxbe.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Measuring interrupt latency Message-ID: <200111081651.fA8Gpa744046@harmony.village.org> In-Reply-To: Your message of "08 Nov 2001 17:23:41 GMT." <1005240221.454.13.camel@teneriel.teledisnet.be> References: <1005240221.454.13.camel@teneriel.teledisnet.be>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <1005240221.454.13.camel@teneriel.teledisnet.be> Sansonetti Laurent writes: : I have to measure ISR [*] under FreeBSD, so I'm building a small KLD : which is hijacking a misc driver with timestamps... : : Is there a way to simulate a hardware irq from kernel land ? : I saw swi_dispatcher() in /sys/kern/kern_intr.c, is this right ? : : In fact I have to start hardware irq by hand because I need to take : timestamp at this moment.. : : Anyone have already measured ISR for FreeBSD ? Is that way correct ? : : Thanks in advance ! The usual way to do this is to connect the IRQ line to 'Trigger' on the scope and toggle a line on the parallel port in your ISR and connect that to 'channel 1' or 'channel 2' of the scope. Note: you may wish to measure how long it takes to pull the parallel port line high, because that can be as long as a microsecond on some machines. The easiest way to do this is to toggle the line, measure the width of the pulse and then substract that value from other measurements that you get. You'll find that it is typically on the order of a microsecond (including time to bring the parallel port high) for a fast interrupt, and varies on non-fast interrupts (anywhere from one microsecond to as much as a millisecond on a very heavily loaded system). You can generate an IRQ in a number of ways. Likely the easiest is to have a tie a different line from the parallel port to the #ACK line and pulse that line. If you do this, then the two signals to measure is even easier. Note: you almost certainly will *NOT* be able to accuragely measure this in software. The getting of the time may swamp the latency for fast interrupts. Also, depending on the time keeping device in use, you may not have enough resolution for measuring it on a fast machine. And a good scope will give you *MUCH* better numbers. And if you are writing an article, people will make this criticism. We found at Timing Solutions when we were trying to measure interrupt latency that the system time (getnanotime()) gave us measurements with a larger variance than our expensive scopes that does statistical gathering. 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?200111081651.fA8Gpa744046>