Re: Multitasking during disc access (was: Re: MiNT scheduling)

[Johan Klockars <rand@cd.chalmers.se>]

> > |> Now what made me think that each slice was 20 milliseconds? I'm sure I
> > |> read that somewhere, but I forget where.
> > 
> > That's right.  Although MiNT uses the 200Hz timer, it only runs the
> > scheduler every fourth tick.
> 
> To be percise every VBl.

Actually, that's not right.

MiNT only runs the scheduler from inside the VBI (which is normally at
50-70Hz, depending on graphics mode) and on return from OS calls, but it
doesn't run it _every_ VBI.

What the VBI handler does is to check 'proc_clock' and if that has reached
zero, the processor is not in supervisor mode, there's no floppy access
taking place and there's no kernel call in progress, _then_ it reschedules.

'proc_clock' itself is decreased by a routine on the normal GEMDOS timer
chain (0x400), which is still handled by the original code at 50Hz.
(IIRC the things on this chain are called every 4th 200Hz interrupt.)

The SLICES value is what 'proc_clock' is normally initialized to for each
new process that gets scheduled.


A SLICES value of 1 would ideally mean that task switches would occur
50 times per second. The fact that the value is normally only set and checked
during the VBI, which is not necessarily in synch with that 50Hz, means that
the interval will vary, though.
Anyway, as has been noted here, if not too many tasks are executable
this will give reasonable response times. On the other hand it will slow
down the computer.

A SLICES value of 4 would mean about 12.5 task switches per second, which
will cause very bad response time with only a few tasks.

That the normal MultiTOS does busy waiting will of course not help matters.


To make things really nice, we should have support for realtime priorities
and have the task responsible for I/O on a reasonably high priority level.
If all busy wait loops were removed too, things would be really zippy most
of the time.

I think Fenix will be something to look forward to.  ;-)

(What an unbelievably inefficient mess that low level MiNT stuff is!)

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)