| OSDev.org https://forum.osdev.org/ |
|
| Reading the PIT https://forum.osdev.org/viewtopic.php?f=1&t=33062 |
Page 1 of 1 |
| Author: | ShukantPal [ Sun Jul 08, 2018 2:37 am ] |
| Post subject: | Reading the PIT |
I hope that many of you have implemented the PIT. Would you mind rather checking that if you latch the PIT counter and read it, twice in a row, then how much difference you get while running in QEMU. I get a difference of about 50-100 ticks - which means a lot of instructions. Is this due to a bug - or due to delay in reading the PIT counter after latching in QEMU? |
|
| Author: | Brendan [ Sun Jul 08, 2018 6:19 am ] |
| Post subject: | Re: Reading the PIT |
Hi, ShukantPal wrote: Would you mind rather checking that if you latch the PIT counter and read it, twice in a row, then how much difference you get while running in QEMU. I get a difference of about 50-100 ticks - which means a lot of instructions. Is this due to a bug - or due to delay in reading the PIT counter after latching in QEMU? I don't know about Qemu; but for real hardware you can expect that each read or write to a "legacy" IO port will probably cost 1 microsecond (due to ancient ISA bus timing); and the "latch, then read then read" sequence will cost about 3 microseconds (or around 9000 cycles for a 3Ghz CPU). Note that you can set the access mode to "hibyte only" or "lobyte only", so that you can read the current count with a single read without issuing the latch command (making it around 3 times faster to read the count). For example, if the PIT was set to "4660.867 Hz, lobyte only" then your IRQ handler could increment a 32-bit "hibyte variable" in RAM, and you could combine that with the lobyte read from the PIT (and then check the "hibyte variable" from RAM and handle roll-over) to get a 40-bit counter value with the same (~838 nanosecond) precision; however for each IRQ you'll probably send an EOI to the PIC chip and that will cost about 1 microsecond too, so this "lobyte only" scheme can be even more expensive if you get the counter rarely (and could be a lot more efficient if you read the counter extremely often). For another example; if you use "hibyte only" (and maybe set the PIT frequency to 18.2 Hz) it'd be similar (you could combine an IRQ handler's variable with the PIT's hibyte to get a larger counter), but you'd have a lot less IRQ overhead (because there's a lot less IRQs) and a lot worse precision (~214.55 microsecond precision instead of ~838 nanosecond precision). Alternatively; (if the computer supports them) the ACPI counter, HPET's main counter, the CPU's local APIC timer's counter, and the CPU's TSC (if it's fixed frequency) can all be accessed with a lot less overhead (because none of them use legacy IO ports) and all of these will give you a lot better precision than the PIT. Ideally you'd only use the PIT on ancient computers that don't support any of the better alternatives; and on ancient computers the cost of legacy IO port accesses (in "CPU cycles") will be a lot less (e.g. 3 microseconds is only 75 cycles for an old 25 MHz CPU). Cheers, Brendan |
|
| Page 1 of 1 | All times are UTC - 6 hours |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|