Per wrote:
Thanks for confirming my suspicion. So at least I know that this is a principal limitation of QDOS/SMS, and I'm not the only one who is aware. Or maybe we are both wrong??> The issue I'm dealing with is the latency time until an external interrupt can > (indirectly) cause re-scheduling of the user-mode jobs, so a high-priority job > blocking for I/O resumes. I am not concerned about sequential throughput > but response. <> > For a simple example, imagine you have a usermode job that implements TCP echo. > No matter how fast and elegant the implementation of the ISR and the buffering, > if QDOS/SMS can only re-schedule jobs after event (A) or (B), the TCP echo > response will need between 0 and 20 milisec., average 10 milisec - and this > is slow on usual ethernet LAN's.There doesnt seem to be any system facility to cater for this sort of thing. For anything that requires a guaranteed response time less than the resolution provided by the 50/60 Hz frame, you may need to put something in your ISR, ie it should be part of the driver, not the application.
I don't ask for a *guaranteed* response time less than 10 msec. That would obviously need to be handled within an ISR, not a usermode job anyway.
I think about an *average* response time of about 1 msec or less, depending on system load. Just as other operating systems like Linux and eCos (sometimes even Windows) provide. If QDOS/SMS forces me to integrate the application into the ISR to achieve that goal, it has a principal (and quite severe) shortcoming for use on LAN's.
I see only two possible solutions for QDOS/SMS:
(1) A higher rate for the frame intterrupt (disadvantage: higher system load)
(2) A new facility (maybe via the IOSS) so an ISR can indirectly cause a job re-schedule after the linked list of ISR's has been handled. (The case that the ISR has interrupted the scheduler may not be easy to handle, but it *can* be handled, as other small operating systems like eCos show.) Please note that not many ISR calls are meant to cause entering the scheduler. This has to happen "seldom", e.g. upon completion of an I/O task.
The strange thing about QDOS/SMS seem that a much quicker average response time can be achieved by implementing everything within jobs. Example:
Imagine I poll an ethernet card for data within job "A". Imagine the system has a low load. This is usually the case if most other jobs are suspended, e.g. waiting for I/O, or have a low priority. Job "B" is a high priority job, suspended waiting for data from the network.
Then job "A" will *usually* be active when the last byte of input data from the network has been received. Job "A" can, directly (or indirectly e.g. by the IOSS), release the suspended job "B", and the scheduler will *ususally* activate job "B" *immediately*. Job "B" will process the data, put some response into some send buffer and will be suspended again. This way I easily have an average response time of less than 1 ms an fast systems like Q40/Q60 (already tested practically).
Do you see what I mean? A simple job can cause *immediate* job re-scheduling. A properly implemented device driver can not (as it seems).
Can please some QDOS/SMS expert tell me I'm wrong ?!?
SMSQ/E IDE driver seems just "quick and dirty" implementation, the only reason I can see was to save work. The advantage was that Thierry could later implement his CDROM driver without much worry about interaction with SMSQ/E harddisk access on the same controller ;-)> The SMSQ/E IDE driver (principle: interrupts off) could even make copying > to harddisk interesting. 8-O I have often wondered why. There cant be any physical reason for it such as processing speed or controllers, as other systems - even Msdos - seem to manage much better in this field.
All the best
Peter
