I am writing some basic timing tests using the hpet channel 0.
I noticed some very different timing results on qemu vs bochs.
Both qemu and bochs report 10,000,000 as the period for the hpet.
In my timing loop, I read the current counter value, add a constant to it (calculated to be 100,000,000 for 1 second), and then wait until the counter value exceeds that. (Not the best because it doesn't account for overflow, but it will do for now).
In qemu, I get delays that look like 1 second.
In bochs, I get delays that look like 0.1 second (I have to change the delay to 10 seconds to get a 1 second delay).
I print the counter value before and after my delay, along with the calculated number of ticks. The before and after values show the correct number of ticks has passed.
The below print shows a few hpet registers, the current/future counter value, then the actual final counter value for the hpet.
Code: Select all
HPET NEEDS 100000000 TICKS FOR 1000 ms
HPET CHANNEL CONFIG IS ffffff00000034
HPET GENERAL CONFIG IS 1
HPET GENERAL COUNTER IS 1439648800/1535764700
HPET GENERAL COUNTER IS 1535806150
Anybody know if this is expected behavior on bochs?
