Eric Valette wrote:
Philippe Gerum wrote:
Never put X in the loop; results cannot be reliable with it and it makes
no sense to interpret them since the user-space X driver can do whatever
it wants to with your hadware, especially when switching back and forth
vt7. So I cannot comment these figures.
May I make the same comment again, publicly this time : for me, one
reason of using a RTAI implementation is having the normal linux
environment including sophisticated X11/KDE, apps. Otherwyse, I would go
for RTEMS or eCos.
So I think making benchmarks with X app running, is relevant (not
obviously the vt switch). Also, for embeded application, using the
framebuffer makes the X server behaves almost like any other linux
driver. Furthermore, the X server indeed performs IO but do not handle
interrupts directly. And if you use this argument, any user space
drivers would also be removed and this includes USB drivers, ...
Please notice we are not ruling out X from fusion, i.e. RTAI not so far
away future. What we are talking about is that X can create huge
latencies by manipulating the hardware directly and at the moment we are
not caring of it. In fact I've a beautiful 2.8 GHz Athlon here that
work with charming jitters in alpha mode, no VT problems, but jumps to
.5 ms as soon as I switch to X mode.
Many times in the past I had to use lower end graphic cards to avoid
such a problem. Copying with X drivers might be a pain. Maybe will end
caring of that too but it is not the most urgent thing I'm minding at
this moment.
Paolo.
