Home arrow Forums
OSDEV Forums  


eosp
User

Junior Osdever
Posts: 6
graphgraph
Karma: 0  
The next step - 2005/04/26 20:33 OK, so I have an IDT set up. Right now, I want to set up my timer interrupt for multitasking. The only problem is that when I change the timer frequency, it also changes the pulses that keep the clock moving. Obviously, this means that I need something to sync my PIT and my clock so that I can set up my own PIT pulserate but have the clock still work.

Does anyone have any advice/code samples to show how to sync these ?

Thanks for the help.
  | | The administrator has disabled public write access.
OSDEV
Community
Advertisement
   
gaf
User

Platinum Osdever
Posts: 153
graph
Karma: 10  
Re: The next step - 2005/04/28 10:28 Hello
I'm not sure if I understood your question correctly..
Is your problem that you don't know how to write a procedure that will update your software clock correctly at any PIT rate ?

If so, try the following:
Code:
 

frequency = [number of interrupts per second]
ticks = 0;
time = 0; // Time in seconds

void UpdateClock()
{
// Add one each time the procedure is called
ticks++;

if(ticks == frequency)
{
// Add one second to your system-time
// Flush the tick-counter
time++:
ticks = 0;
}
}

void ChangeFrequency(new_freq)
{
DisableInterrupts();

// Convert the ticks that were received until now
// freqA = ticksA/s -> s = ticksA/freqA
// freqB = ticksB/s -> s = ticksB/freqB
// ticksA/freqA = ticksB/freqB
// ticksB = (ticksA/freqA)*freqB

ticks = (ticks/frequency)*new_freq;

// Example:
// freqA = 10hz, freqB = 20hz
// ticksA = 3
// -> ticksB = (3/10)*20 = 6

frequency = new_freq;

Enable_Interrupts();
}


regards,
gaf
  | | The administrator has disabled public write access.
anonymous
Visitor

Fresh Osdever
Posts: 0
graphgraph
Karma: 0  
Re: The next step - 2005/04/28 20:09 Exactly. Wow, I didn't expect this kind of instant help on this board, although I can't expect any at all from OSdever.net
  | | The administrator has disabled public write access.
DRF
User

Platinum Osdever
Posts: 123
graphgraph
Karma: 1  
Re: The next step - 2005/04/28 20:19 There are a few of us regulars who check the forum quite often, but it depends on how hard/specilised the question question is as to how long it takes for someone with the right answer to reply.
I hope osdever's forums are sorted out soon, but in the mean while there are still the forums here and at osdev.org.

Daniel
  | | The administrator has disabled public write access.
MrKaktus
User

Junior Osdever
Posts: 12
graphgraph
Karma: 1  
Re: The next step - 2006/04/15 03:38 Hmm but why changing the PIT frequency? Isn't it better to set once (at start) PIT to 100Hz and then update your system time in sheduler (once per 100 sheduler initializations)?

BIOS clock is going he's way anyway isn't it?
  | | The administrator has disabled public write access.
gaf
Visitor
 
Re: The next step - 2006/04/15 09:46 Of course you can uses a fixed interval, but this might mean some overhead in certain situations, as the high frequency (100Hz) that you'd have to choose to meet the requirements of all tasks, is actually not needed most of the time.
Imagine for example that there are only two cpu-bound tasks running on the system (f. ex. SETI & GCC). As resposniveness doesn't really matter in such a case, one would normally assign both tasks a rather long time-slice to reduce the overhead of many task-switches. If the timer frquency is however static, the tasks will still be interrupted all the time, only to get rescheduled again as their qunatum hasn't yet expired.
By changing the timer frequency at run-time, the scheduler can adapt to the current workload of the system: If there are many interactive tasks, it chooses a high frequency and if there are only cpu-bound tasks a lower frequency can be used to avoid unnecessary overhead.
An even better approach would probably be to use a single-shot timer, so that the kernel really only gets interrupted when the whole quantum of the current tasks has expired. From what I know this technique is however rather expensive with the PIT as it takes relativly long to access the device's I/O ports to program the next timer.
BIOS clock is going he's way anyway isn't it?
From what I know the CMOS clock gets its input from the RTC rather than the PIT.

regards,
gaf
  | | The administrator has disabled public write access.
MrKaktus
User

Junior Osdever
Posts: 12
graphgraph
Karma: 1  
Re: The next step - 2006/04/18 06:40 Hmm but sheduler will be turned on by Interrupts, (like they'r name says, they are interrupting ) so the process/task will be resheduled anyway :]. This is "preemptive" sheduling in enlish?
  | | The administrator has disabled public write access.
gaf
User

Platinum Osdever
Posts: 153
graph
Karma: 10  
Re: The next step - 2006/04/18 08:00 A decent scheduler doesn't switch tasks on every interrupt that occures, but only if the task's quantum has expired, or if a tasks with a higher privilege gets unblocked (if a IRQ occures).
The task's quantum just states for how many clock ticks (or time-slices) the task may normally run. Interactive tasks are given a small quantum length, but get scheduled more often, while CPU bound tasks are assigned a longer quantum length to avoid task-switching overhead. It's thus perfectly possible that the schedule may return from a timer interrupt without having switched tasks, provided that the currently running task hasn't yet used its full quantum.
A timer interrupt that doesn't initiate a task-switch is only unnecessary overhead, which is why the scheduler should seek to avoid it. This can be done by choosing a timer frequency that fits to the tasks' behaviour (20-50Hz) but, as the constitution of the tasks running on the system may change in time, it might by necessary to adapt the frequency at run-time.
I myself are by the way planning to use single-shot timers that can be set to meet the tasks whole quantum length. With the local APIC this can be implemented in a very efficient way and it does avoid all unnecessary timer interrupts.

This is "preemptive" sheduling in enlish?

Yep, preemptive means that the kernel may interrupt a task, to schedule some other, at any time. The opposite is cooperative scheduling, where the kernel expects the tasks to return voluntarily after some time. This of course leads to some problems when a malicious tasks refuses to return, or some program just hangs.
Nevertheless cooperative scheduling is still used today in some areas, as for example real-time systems, where tasks can be considered as safe and the overhead, that preemptive scheduling means, wouldn't be acceptable.

cheers,
gaf
  | | The administrator has disabled public write access.

A WebArticles site. Sponsored by Evoleto. Motorola V525 / Business Directory / Delaware Incorporation / Home Made Bazaar