20 Jul
2004
20 Jul
'04
10:02 p.m.
While locking a RT process to a CPU to achieve even lower latencies
might be useful to some
the general userbase wants good latencies on simple UP, non HT-enabled
hardware too.
(AMD is gaining marketshare and we cannot simply expect that good
multimedia performance (aka low latency)
can be achieved only on those SMP/HT boxes where the truth is that
except in the case of really crappy hardware,
those common UP machines are actually capable to delives latencies in
the range of dozen of usecs.
(taking the RTLinux benchmarks as reference).
Of course Linux != RTLinux and we never expect nor pretend Linux to
match the response time of RTLinux but
as said earlier latencies at around 1msec should are doable on decent UP
boxes and this is more than
adequate to run demanding real time audio applications like software
synthesizers, samples, real time effects etc.
The only hope is that the hard work from Ingo, Andrew and all the others
gets soon integrated in the mainstream
2.6 kernel so all Linux users can take run demanding multimedia
applications out of the box without going through
the painful patching,kernel recompiling etc.
Or is this still not realistic at this point ?
(see the old issue with kernel 2.4, low latency patches were too
unclean to make it into the
ufficial kernel tree).
Plus what's very important is that every kernel developer and driver
developer (even thirdparty, especially those
that do closed source stuff like Nvidia etc) takes into account the
latency problems that code paths that run for
too long time (or disable IRQs for too long etc) might create.
While I'm not a kernel expert I assume the premptible kernel alleviates
this problem but I guess it still cannot
completely get rid of low latency-unfriendly routines and drivers.
Perhaps in upcoming Linux kernel/driver programming books this issue
should be stressed out and
mentioned prominently in order to avoid the eternal:
fixing latencies in kernel x.y.z -> new kernel versions with new
drivers/changes/enhancements comes out
-> latencies are bad again -> fix latencies in this new kernel version
..... ( iterate at infinitum)
cheers,
Benno
http://www.linuxsampler.org
Lee Revell wrote:
On Tue, 2004-07-20 at 14:11, Ralf Beck wrote:
Should work. For example, the RTLinux people report excellent results
on SMP systems by binding all RT threads to one CPU and having the Linux
part of the system run on the other. This is just a "softer" version of
that setup. Even if there are cases where IRQs are disabled globally,
it would be an improvement. I suspect you are not getting much of a
response because no one has actually tested it with an audio system.
Lee
it's
an issue for all block IO drivers that do IO completions from IRQ
context and that can do DMA - i.e. every block IO hardware that uses
interrupts. This includes SCSI too. In fact for SCSI it's a norm to have
I renew a question i asked earlier.
To my understanding, on a SMP or hyperthreading system, disabling of
IRQs is always local to one (virtual on HT) cpu.
So would it be possible to get ultralow latency by simply hardlock all irqs
and processes to cpu1 and the irq triggering the audiothread (together with
the audiothread) to cpu 2 using the sched_affinity and irq-affinity
capabilites of the kernel?
This would be an easy to use lowlatency hardware patch for linux audio users
with SMP/HT systems. Anybody knows?
I'm currently thinking about getting a new system and consider a dualsystem if
this worked.