OSDev.org

The Perfect Response Vs Perfect Efficency weighs on a kernel's task scheduler.
A scratch pad of late night work proving, exploring, and asking how to make a scheduler more efficent in its uncompleted too much coffee form, I am going to shake out of my seat into the floor... :-X I think I might pass out btw..

http://mcguire.sytes.net:6080/hfmos/scheduler.txt

Once again there's a problem with your web server.
By the way ther is no perfect response or efficency. It depends on what you want to do. For a real-time systems I guess it would be good to have fast response.

kataklinger wrote: For a real-time systems I guess it would be good to have fast response.

/enage SolarBot

"Real-time" (hard real-time) is about guaranteed maximum response times, not necesserily fast response.

One of the most common misunderstandings when it comes to schedulers. "Real-time" means maximum tolerances. Think audio production, or reactor controll. If you take longer than X to do task Y, you're busted. It doesn't matter if you could do Y faster or not, as long as you never take longer than X.

Usually, a "best try" scheduler (sometimes referred to as soft real-time) that doesn't care about pathologic corner cases can do better - on average - than a hard real-time scheduler, given the same hardware. That's what you would like on your system for casual multimedia, gaming etc.

/disengage SolarBot

"Real-time" (hard real-time) is about guaranteed maximum response times, not necesserily fast response.

Inccorect words I was using.

Addon to Solar's explanation about computers and real-time:

Two categories:

!!! Hard realtime

Hard realtime is a system that guarantees that a certain deadline is going to be made. There's no information on what it does to ensure that, or what sort of average performance will be made, but it makes the deadlines, PERIOD.

If you have a hartmonitor device (pacemaker) that monitors your heart, it MUST trigger re-activation pulses at a given interval and it may not react after a too long period or you're pretty much dead. It may also not do this too quickly, or you'd be dead just the same. Examples of hard realtime systems are heart monitors, pace makers, medical equipment, nuclear power plant software, mars robot software etc.

Soft realtime

A system that needs to maintain a certain performance, but without significant penalties for not making them. The significant penalties are relative, so a penalty of 100000 euros would still fall under insignificant (try to imagine what a nuclear power plant disaster costs - and don't forget new commercials that the rest is safe, people killed, lives affected, places that can't be used anymore, effect on weather, everything).

Examples of these systems are your DVD player, your own computer when it's playing music or such, burning a cd or dvd etc. If these deadlines aren't met, well, that sucks, but your cost is easily fixable and costs between 0.1 and 10 euros plus some time. Nothing is lost.


Mathematically, there are very different requirements between the two types of system. The first needs consistency, the second needs speed. For the first, worst-case optimization is everything, whereas for the second average-case optimization is a lot more important.

Common average-case techniques:
Burst transactions
Caching
Branch prediction
Pipelining
Parameter-dependant execution (so 1*1 is quick)
Swapping

Common worst-case techniques:
Constant execution time optimization (so 1*1 takes as long as 38957*156)
Special checks in compiler to display the effects of code on the pipeline
Deterministic hardware, stuff that does the exact same thing all the time
No swapping
Storage only for initial loading and log storing, not for continuous usage

@Solar:
Thats it! Im going too deep. Im trying to workout a pathologic corner case that is not worth the work. Im not thinking, clearly. I am basing the problem with seconds, which made it seems like a very large problem if we still had processors that were around 100hz or something. ROFL

That is the truth a soft real-time would do much better.
Thanks, Solar.

@Candy
I like it. I actualy like the idea of a soft real-time scheduler. That is the direction that I need to take. You make sense. A hard real-time scheduler has uses more towards serious industrial or medical fields, as a deticated system with deticated hardware for one purpose or a group of purposes.

I simply need what you and Solar described, a soft real-time scheduler. Not a impossible pathological nightmare. LOL :-X
Thanks Candy