gregk@cbnewsm.att.com (gregory.p.kochanski) (01/31/91)
As a experimental physicist, I find myself often wanting to do strange things to computers. I have a particular set of hardware that I'd dearly like to run with a unix box, rather than MS-DOS, but it requires some serious speed. Basically, I need to be able to read a single word from some hardware in 50 microseconds or less (and write in the same smount of time). Can any unix do this, perhaps by locking processes into the CPU and allowing some end-run around device driver overheads? That and C++, too?
hartman@ide.com (Robert Hartman) (02/01/91)
In article <1991Jan30.234153.13055@cbnewsm.att.com> gregk@cbnewsm.att.com (gregory.p.kochanski) writes: > ... Basically, I need to be able to read a single word >from some hardware in 50 microseconds or less (and write in the same >smount of time). Can any unix do this, perhaps by locking processes into >the CPU and allowing some end-run around device driver overheads? >That and C++, too? I've never written a device driver, but I have written a device-driver manual. I'm only speculating, but it seems to me that a virtual driver could easily be written to lock down memory and queue all signals until it's done. A driver is privileged, so it may be that the driver can ignore the clock interrupt too, in which case you're home free; once you drop into driver code, the driver may well run to completion. If the driver can't override the clock interrupt, then the user process will do a context switch when it hits. In this case you might still get the results you want by running the application in single-user mode. Running single-user does not guarantee that the process will not time slice, but if it's the only active process when the clock interrupt hits, it will schedule itself to run again with a minimum of delay. I don't know whether this would be good enough for your purposes, but if it's not, then perhaps you could run the time-critical program in the monitor. I know this sort of thing can be done on a Sun. -r