OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Nov 14, 2018 1:23 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: Reading the PIT
PostPosted: Sun Jul 08, 2018 2:37 am 
Offline

Joined: Tue Dec 12, 2017 6:51 am
Posts: 23
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?


Top
 Profile  
 
 Post subject: Re: Reading the PIT
PostPosted: Sun Jul 08, 2018 6:19 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: kzinti, nullplan and 19 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group