OSDev.org

..

You can do that?? Use the PIT in a reasonable way to trigger a task switch?? If so, may I request information for this?

However... shouldn't it be the other way around? Time sensitive processes would probably like to use a value from the PIT 'cause it (from what I've heard) can be set to trigger much more than the RTC...

By the way, the RTC can be set to trigger an interrupt 8192 times per second.

hmmm ... i'm not sure to follow 100% what you want to do. You will not be able to use IRQ0 directly as a task switch technique: the best you can do is call a task switch mechanism.

I don't really see the advantage of having a separate time-based IRQ to keep system time up to date (it could be done with the same interrupt, just by decrementing a counter and see whether its time to call the other one or not).

Most systems use IRQ0 at 10ms (thus issued 100 times a second), which is a good timebase for task switching, but which gives very little accuracy for time-precision waits.

For those waits (for instance, run a task in 300?s), it is possible to use the local APIC to get a one-shot interrupt at the wished time. Linux has used it, i don't know if it still does. I don't have more info atm.

..

Pype.Clicker wrote: hmmm ... i'm not sure to follow 100% what you want to do. You will not be able to use IRQ0 directly as a task switch technique: the best you can do is call a task switch mechanism.

I don't really see the advantage of having a separate time-based IRQ to keep system time up to date (it could be done with the same interrupt, just by decrementing a counter and see whether its time to call the other one or not).

What Perica probably is going to do is to have the task switch code in the ISR... as I...

I must ask a thing here... I did a simple RTC interrupt program to display a "rolling" cursor and print the time... But the ISR didn't have any update-the-clock-code. Yet, the clock was updated when it should... Have I missinterpreted the information? Does the chip itself keep track of time? Because as I've understood it (from the posts and info) the OS have "to keep system time up to date"...

err, i may need a tech refresh, but yes, i think the RTC keeps its internal time up to date (that's why it's realtime ... it keeps updated even when the PC is down )
I'm not sure it's such a good idea to poll the chip every second, because it may be quite long to do (even just having another periodic interrupt ...) thus another time switching from user to kernel mode, just for reading a chip and storing the value ? better do it on demand or within the IRQ0 interrupt (but not everytime, just when a "IRQ0 internal counter" reached 0)

now, i don't know what frequency you can give to RTC interrupts (note that with an uptime of 4 hours, my Linux box only saw 2 RTC interrupts, probably for cron jobs or sth.), but afaik, the realtime clock doesn't go deeper than seconds. thus it may not have very precise time.

and about the "time accuracy", remember that the delivery of RTC interrupts will be delayed until interrupts that are more prioritary are completed. and *every* interrupt request is prioritary over IRQ8 because IRQ9..15 have the priority of the cascade (IRQ2).
Thus if a disk transfer, a packet receive, a mouse event, etc. is received, you'll get your IRQ8 delayed of a few ms. (not even mentionning CLI parts in your code), while IRQ0 is not delayed by any other IRQ.

What i would suggest is just to compare the "software-computed" time (updated by IRQ0) to the RTC-stored time and see if we're driftin'. According to the (drift amount)/(inter_probes_duration) ratio, adjust the inter_probe_duration (/2 if ratio>THRESHOLD_HI, +1 if ratio <THRESHOLD_LO should give a good result).

According to this site on the RTC <http://www.nondot.org/sabre/os/files/MiscHW/RealtimeClockFAQ.txt> there are two different types of RTC interrupts: one that goes off at a specified time as an "alarm" (probably the two that you've had go off), and one that can go off at certain intervals between 2 and 8192 times per second.

So, although theoretically it could be possible to use this for some kind of preemptive task switching, I agree...philosophically...that it's not the best solution.

- Brandon

Pype.Clicker wrote: err, i may need a tech refresh, but yes, i think the RTC keeps its internal time up to date (that's why it's realtime ... it keeps updated even when the PC is down )

Go RTC! Go RTC!

Pype.Clicker wrote: I'm not sure it's such a good idea to poll the chip every second, because it may be quite long to do (even just having another periodic interrupt ...) thus another time switching from user to kernel mode, just for reading a chip and storing the value ? better do it on demand or within the IRQ0 interrupt (but not everytime, just when a "IRQ0 internal counter" reached 0)

When it reaces zero? When is that? Every second? If so, wouldn't the RTC's Time Update interrupt (see below) be possible to use instead?

Pype.Clicker wrote: now, i don't know what frequency you can give to RTC interrupts (note that with an uptime of 4 hours, my Linux box only saw 2 RTC interrupts, probably for cron jobs or sth.), but afaik, the realtime clock doesn't go deeper than seconds. thus it may not have very precise time.

The periodic interrupt can be set to trigger as high as 8192 times a second.

There is also a Time Update interrupt that can be activated. This trigger every second (when time has been updated).

Pype.Clicker wrote: and about the "time accuracy", remember that the delivery of RTC interrupts will be delayed until interrupts that are more prioritary are completed. and *every* interrupt request is prioritary over IRQ8 because IRQ9..15 have the priority of the cascade (IRQ2).
Thus if a disk transfer, a packet receive, a mouse event, etc. is received, you'll get your IRQ8 delayed of a few ms. (not even mentionning CLI parts in your code), while IRQ0 is not delayed by any other IRQ.

The PIT is what triggers IRQ0? The PIT gives me a head ache...

Pype.Clicker wrote: What i would suggest is just to compare the "software-computed" time (updated by IRQ0) to the RTC-stored time and see if we're driftin'. According to the (drift amount)/(inter_probes_duration) ratio, adjust the inter_probe_duration (/2 if ratio>THRESHOLD_HI, +1 if ratio <THRESHOLD_LO should give a good result).

The first part of this I get. The other I don't. But it seems to be clever...

I apologize if I seem stupid right now... but it was some time ago I thought about operating system stuff so I'm not into that pattern right now... and I'm a bit tired to.

bkilgore wrote: According to this site on the RTC <http://www.nondot.org/sabre/os/files/MiscHW/RealtimeClockFAQ.txt> there are two different types of RTC interrupts: one that goes off at a specified time as an "alarm" (probably the two that you've had go off), and one that can go off at certain intervals between 2 and 8192 times per second.

Actually, it is three... Update-ended Interrupt...

bkilgore wrote: So, although theoretically it could be possible to use this for some kind of preemptive task switching, I agree...philosophically...that it's not the best solution.

- Brandon

Why? *confused*

I'm not sure it's such a good idea to poll the chip every second, because it may be quite long to do (even just having another periodic interrupt ...) thus another time switching from user to kernel mode, just for reading a chip and storing the value ? better do it on demand or within the IRQ0 interrupt (but not everytime, just when a "IRQ0 internal counter" reached 0)

When it reaches zero? When is that? Every second? If so, wouldn't the RTC's Time Update interrupt (see below) be possible to use instead?

1. having the RTC in addition makes more overhead. (back from IRQ to user then again user to kernel then back to user)

2. let's even say you just display time on screen at RTC. because of its low priority, it might not been call when the time update occur, but with a D delay interval. This means your display time isn't just at seconds update, but it may be up to D secs later (D<<1 second, usually ...), while the IRQ0 could possibly rise earlier with a good interrupts management policy.

Pype.Clicker wrote: 1. having the RTC in addition makes more overhead. (back from IRQ to user then again user to kernel then back to user)

I don't understand that user-to-kernel-to-user thing...

Pype.Clicker wrote: 2. let's even say you just display time on screen at RTC. because of its low priority, it might not been call when the time update occur, but with a D delay interval. This means your display time isn't just at seconds update, but it may be up to D secs later (D<<1 second, usually ...), while the IRQ0 could possibly rise earlier with a good interrupts management policy.

Hm... the delay is disturbing... and another thing is that a status register at the RTC must be readed in order to tell it to be ready to fire another interrupt. Hm...

u2k2u2k2u thing.

Programs are running in user-mode, and sometimes entering kernel mode for system calls. On a normal system, programs are more often in user-mode than in kernel mode, so when an interrupt occur, there's a high chance that the system is in user mode.

Let's say one second just elapsed, and you're going to receive both IRQ0 and IRQ8. The IRQ0 comes first and it calls the interrupt (thus switching to kernel mode). The IRQ0 is serviced (let's say we don't swap to another thread for this time, maybe it's the only thread ready in the system). You go back to user mode and continue operations (2 mode switches so far).
Then IRQ8 triggers and traps to kernel mode aswell. There it will read the RTC time and store it in a variable, and return to user mode (4 switches so far).

Compared to a scheme where RealTime is read out of the chip at IRQ0 interrupt, you then have 2 additionnal switches.

Pype.Clicker wrote: u2k2u2k2u thing.

Programs are running in user-mode, and sometimes entering kernel mode for system calls. On a normal system, programs are more often in user-mode than in kernel mode, so when an interrupt occur, there's a high chance that the system is in user mode.

Let's say one second just elapsed, and you're going to receive both IRQ0 and IRQ8. The IRQ0 comes first and it calls the interrupt (thus switching to kernel mode). The IRQ0 is serviced (let's say we don't swap to another thread for this time, maybe it's the only thread ready in the system). You go back to user mode and continue operations (2 mode switches so far).
Then IRQ8 triggers and traps to kernel mode aswell. There it will read the RTC time and store it in a variable, and return to user mode (4 switches so far).

But is I use IRQ8 only, the number of switching is lesser...
However, I think I should use the IRQ0 for the multitasking, system counter and system time... Your arguments have convinced me

Pype.Clicker wrote: Compared to a scheme where RealTime is read out of the chip at IRQ0 interrupt, you then have 2 additionnal switches.

Why are there 2 additional switches??