> > if you can tolerate occasional few-millisecond delays, the plain
> > kernel may suffice.
>
> this is much too harsh; with the user-level app running RT, and no stupid
> misconfigurations (IDE in PIO, other RT tasks), there won't be "occasional"
> long delays.
Hm, I was vaguely remembering some l-k traffic about nonpreemtible
kernel routines that weren't well bounded in time (and not just IDE-PIO:
list traversal? mm?). If this is not a real issue, great.
> > a benchmark. If the hardware can support timers, can see everything
> > with software; otherwise a storage scope watching stimulus and response
> > will do nicely.
>
> why not just rdtsc in the driver, and again in the app?
You won't see the latency from hardware asserting its request to when
the driver can do a rdtsc, but this might not be so important for
some applications.
Cheers,
Peter Monta pmonta@terayon.com
Terayon Communication Systems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST