PIT Question

[srg_13]

Currently in my operating system, I have a integer that is incremented whenever the PIT is triggered. The PIT fires 100 times every second. What will happen to my OS when the number becomes too large? Will it crash, or will I just not be able to do the 5 second timer test :p?

I was just wondering. Is there any way to fix this so that it will never overfow? I could reset it after a while, but this would cause the delay function to break.

What can I do? It doesn't matter at the moment, because I don't have any reason to have my OS running for a year or so, but possibly in the future this could become a problem if I port a web server over.

Thanks,

-Stephen

[elaverick]

According to this tutorial - http://www.osdever.net/bkerndev/Docs/pit.htm the timer should wrap around to 0 which is pretty much going to break any delay function anyway. Personally I can't see how that's going to happen as the PIT has no knowledge of the variable used to store the tick count. I had wondered about this myself.

[B.E]

you could just increase the size of the counter to 64 bits

[Pype.Clicker]

Will it crash, or will I just not be able to do the 5 second timer test :p?

I was just wondering. Is there any way to fix this so that it will never overfow? I could reset it after a while, but this would cause the delay function to break.

What can I do? It doesn't matter at the moment, because I don't have any reason to have my OS running for a year or so, but possibly in the future this could become a problem if I port a web server over.

Typically, you don't want the counter that counts 1/100 seconds to be used for long time ranges. E.g. every 100 IRQs, you will increment the 'real time' (year, day-of-year, hour-of-day ...) and that's what you'll use if you need e.g. to have something executed every week on sunday at 1:00 AM ...

[Brendan]

Hi,

Typically, you don't want the counter that counts 1/100 seconds to be used for long time ranges. E.g. every 100 IRQs, you will increment the 'real time' (year, day-of-year, hour-of-day ...) and that's what you'll use if you need e.g. to have something executed every week on sunday at 1:00 AM ...

From my own personal perspective, a single "master counter" is a much more elegant solution.

The idea would be for this master counter to be fine grained enough to be used for the smallest possible time periods but also have enough range to span thousands of years.

This is entirely possible using a 64 bit integer. For example, if one "tick" equals one micro second then the master timer has a range of (roughly) 584 thousand years.

In this case the same "master counter" could be used by the scheduler or for measuring very small time delays and time measurements, and still be suitable for working with calendars, etc.

I'd suggest reading the time and date from the real time clock during boot and using this to initialize the master counter. Then for each PIT IRQ you'd add K to the master counter, where K depends on the frequency of the PIT timer.

Once you've got a master counter, use the same "time format" everywhere - the scheduler, the native file systems, the real time clock, etc so that you don't need to convert from one format to another.

Consider something like this code:

Code: Select all

#define DAY  (24 * 60 * 60 *1000000)

int main() {
    clock_t start_time;
    struct tm *calendar;

    start_time = clock();

    for (;;) {

        calendar = localtime(&start_time);
        if( (calendar->tm_mday == 1) && (calendar->tm_mon == 0) ) {
            printf("Happy new year!\n");
        }

        do_the_work();
        printf("That took %d micro seconds\n", clock() - start_time);

        start_time += DAY;
        sleep( start_time - clock() );
     }
}

Here, it doesn't matter if the "do_the_work()" function takes less than a second to complete or if it takes three hours, it will still be started again at exactly the right time (e.g. not 50 mS too early or too late) each day and won't be effected by drift.

Now try writing it so that it's POSIX compatible, without turning it into a mess or losing it's accuracy....


Cheers,

Brendan