Peter Graf writes: <> > Hm. I know this is perfectly allright, and I think I even understand the > priciples of background device drivers a bit.
Oops. Should have known ;) However, sometimes the obvious is missed even by experts, so its good to get this out of the way first. > 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. > If my fear is correct, then QDOS/SMS has a principle limitation here that > stems from the 50/60 Hz frame interrupt heritage. > > >Having said that, it will be interesting to see how such a device will > >respond to the copying of a file from the network to a floppy disk ;( > >Perhaps you can fix the floppy driver while youre at it ;) > > 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. Per
