Re: [ql-developers] Job re-scheduling

[Peter Graf]

Phoebus wrote:

>The problem in using jobs for handling hardware devices is that a job can
>never react to asynchronous hardware events unless it is polling, i.e.
>consuming CPU resources.

Not necessary if you assume intelligent (ie with their own CPU) peripherals.

[Snip]

How should the intelligent peripheral wake up the application running on the QDOS/SMS system other than by the QDOS/SMS scheduler? As long as the scheduler can not react to async hardware events other than in a 20 msec raster, we are stuck at average 10 msec response.

I still have problems to believe that QDOS/SMS is really that limited. Every simple job can cause re-scheduling *immediately*, not only in a 20 msec raster! There may be a way how an interrupt-driven device driver can do that also. Maybe some expert knowledge I lack.

>I may add that my concerns are more or less specific for mid- to high-speed
>local area networking.

Buffering can still be used in a high-speed LAN but what are the limitations on speed
anyway? I doubt it that the ISA bus can do the "theoretical" 100Mbit (like my intel card
uses). IIRC in the case of the iNTEL Etherexpress, the card buffers input and output
packets and then burst-sends them out/in so no loss of frame sync happens.

At the moment I'm concerned about response, not linear throughput. Every simple Linux process on Q40 can do what I'm asking for. Device driver interrupt-driven, of course.

And that's why IIRC even Windows is polling its devices... and also why they were finally
able to use more devices / interrupt (which aren't really used anymore)... and also why
"Legacy" devices are always so much more responsive from polled ones.
maybe a third type of device driver should be devised... one that can act as block or
directory, but which is strictly polled. In any case just one device driver of that type
wouldn't put such a load on the system (especially if the code for it is written to take
advantage of the 040 and 060 high performance extra instructions

The device driver can be more than quick enough without polling. It just can't make the OS re-schedule the jobs immediately, so jobs who were blocking for input can't get activated other than in the 20 msec raster. (Unless I'm wrong, and I still hope I'm wrong.)

All the best
Peter