[linux-audio-dev] Re: [vst-plugins] Plugin server (Re: [vst-plugins] Re: [a bit OT] gcc as a cross compiler for VST?
8 Dec
2002
8 Dec
'02
10:38 a.m.
Kjetil and i have been boring the VST crew to death. so we took it
here :)
you didn't touch much of the cache, did you?
it doesn't matter how fast the actual switch is if each task wipes out
the L1 and L2 cache, forcing a complete refill of the cache, reload of
the TLB, etc. etc. the cost of a context switch is not just a register
store+restore. the cost of it depends on what has happened since the
last context switch.
try your "simple context switch test" with a setup in which each task
writes to about 256kB of memory.
we measured this extensively on LAD a year or two ago. both myself and
abramo and some others did lots of tests. we plotted lots of
curves. the results were acceptable but not encouraging. yes, faster
processors will decrease the time it takes to save and load the
registers. but just as for much DSP code these days, other issues
often dominate over raw CPU speed; the slow downs caused by the TLB
being invalidated as a result of switching address spaces and the
cache invalidation (for the same reason) are dramatic.
because when
running a real-time low-latency audio system, the cost of
context switches is comparatively large. if you've got 1500usecs to
process a chunk of audio data, and you spend 150usecs of it doing
context switches (and the cost may be a lot greater if different tasks
stomp over a lot of the cache), you've just reduced your effective
processor power by 10%.
I dont believe you. I just did a simple context-switching/sockets
test after I sent the last mail. And for doing 2*1024*1024 context
syncronized switches between two programs, my old 750Mzh duron uses 2.78
seconds. That should about 1.3usecs per switch or something. By I'm not talking about jack tasks, I'm talking
about doing a simple plug-in
task inside a standalone program, the way the vst server works.
i don't understand how the vst server works. perhaps you can explain
it.
--p
8 Dec
8 Dec
1:33 p.m.
On Sun, 8 Dec 2002, Paul Davis wrote:
Its just simple one to one process request/processing/answer. No mixing
or synchronising.
--
Kjetil and i have been boring the VST crew to death.
so we took it
here :)
you didn't touch much of the cache, did you?
Eh. No. :)
because
when running a real-time low-latency audio system, the cost of
context switches is comparatively large. if you've got 1500usecs to
process a chunk of audio data, and you spend 150usecs of it doing
context switches (and the cost may be a lot greater if different tasks
stomp over a lot of the cache), you've just reduced your effective
processor power by 10%.
I dont believe you. I just did a simple context-switching/sockets
test after I sent the last mail. And for doing 2*1024*1024 context
syncronized switches between two programs, my old 750Mzh duron uses 2.78
seconds. That should about 1.3usecs per switch or something. By it doesn't matter how fast the actual switch is if
each task wipes out
the L1 and L2 cache, forcing a complete refill of the cache, reload of
the TLB, etc. etc. the cost of a context switch is not just a register
store+restore. the cost of it depends on what has happened since the
last context switch.
try your "simple context switch test" with a setup in which each task
writes to about 256kB of memory.
Yupp, I see. I get a 7 percent penalty compaired to doing
the same just in one process.
we measured this extensively on LAD a year or two ago.
both myself and
abramo and some others did lots of tests. we plotted lots of
curves. the results were acceptable but not encouraging. yes, faster
processors will decrease the time it takes to save and load the
registers. but just as for much DSP code these days, other issues
often dominate over raw CPU speed; the slow downs caused by the TLB
being invalidated as a result of switching address spaces and the
cache invalidation (for the same reason) are dramatic.
Going to dig into the discussion. This was very interesting.
>I'm not talking about jack tasks, I'm
talking about doing a simple
plug-in
task inside a
standalone program, the way the vst server works.
i don't understand how the vst server works. perhaps you can explain
it.
1:42 p.m.
Yupp, I see. I get a 7 percent penalty compaired to
doing
the same just in one process.
right. now try it with 8 different processes, all of them touching
enough (different) data to invalidate a random selection of about 80%
of the cache. or better yet, just take our word for it that the cost
of the context switch is significant.
you also haven't addressed kernel scheduling issues; the context
switch doesn't happen till the kernel has decided what task is going
to run next. if it picks the wrong one, for whatever reason, then
you/we lose. right now, it picks the wrong one too often, even with
SCHED_FIFO+mlockall.
>I'm
not talking about jack tasks, I'm talking about doing a simple
plug-in
task
inside a standalone program, the way the vst server works.
i don't understand how the vst server works. perhaps you can explain
it. 
7:20 p.m.
New subject: [linux-audio-dev] Re: [vst-plugins] Plugin server
On Sun, 8 Dec 2002, Paul Davis wrote:
you also haven't addressed kernel scheduling
issues; the context
switch doesn't happen till the kernel has decided what task is going
to run next. if it picks the wrong one, for whatever reason, then
you/we lose. right now, it picks the wrong one too often, even with
SCHED_FIFO+mlockall.
Btw; have you tried the O(1) scheduler? It has a number of interesting
charasteristics from an audio app developer's pov [1]:
- RT-scheduling is, too, O(1) (less cache use, quicker context
switches...)
- RT-scheduling is separated from non-RT scheduling
- perfect SMP-scalability (no shared run-queue lock)
And of course, as O(1) is under active development (in 2.5, in 2.4-ac
and patches for latest 2.4 kernels), a possible bug in SCHED_FIFO
semantics might receive kernel-hacker interest. ;)
Do you have any simple test cases to reproduce the problem... only
with ardour+jackd or perhaps also simpler setups like jackd+capture_client
or some such?
[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.0/0810.html
--
http://www.eca.cx
Audio software for Linux!
11 Dec
11 Dec
5:12 p.m.
New subject: [linux-audio-dev] Re: [vst-plugins] Plugin server
On Sun, 2002-12-08 at 16:14, Kai Vehmanen wrote:
On Sun, 8 Dec 2002, Paul Davis wrote:
I tried it (using the Con Kolivas patches on top of 2.4.20). I still get
xruns in jackd, although that particular patchset (plus the drm lowlat
patches) seems to keep them to more reasonable values at least in a
short test I just did. I managed to also hang the machine, after running
jackd + qjackconnect + freqtweak + ams for a while I got greedy and
started ardour - created a new session and when I went to connect things
in qjackconnect the machine stopped... it still responds to alt-sysrq-b.
BTW, with latest versions of alsa the hanging problems seems to happen
less frequently so it may be some interaction between alsa and the
kernel (hangs do not seem to happen in 2.4.19).
Besides that, it looks like the O(1) scheduler is less responsive to
user interaction in certain cases. While doing an alsa driver compile
the mouse was freezing for fractions of a second at a time (this was
during the depend phase, actually compiling the modules did not have
that effect).
[anyone out there has a patch to schedutils to make them work with the
O(1) scheduler?, mine just report all tasks as Other]
-- Fernando
you also haven't addressed kernel scheduling
issues; the context
switch doesn't happen till the kernel has decided what task is going
to run next. if it picks the wrong one, for whatever reason, then
you/we lose. right now, it picks the wrong one too often, even with
SCHED_FIFO+mlockall.
Btw; have you tried the O(1) scheduler? It has a number of interesting
charasteristics from an audio app developer's pov [1]:
9 Dec
9 Dec
2:44 a.m.
On Sun, 8 Dec 2002, Paul Davis wrote:
Its just simple one to one process request/processing/answer. No mixing
or synchronising.
in other words, a lot like JACK :) one plugin per JACK client. no real
difference, i would guess.
Really? I thought all jackclient sounddata exchange went thru the jackd
program, to get everything synchronized?
--
>I'm not talking about jack tasks, I'm
talking about doing a simple
plug-in
task
inside a standalone program, the way the vst server works.
i don't understand how the vst server works. perhaps you can explain
it.
7812
days inactive
7815
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Fernando Pablo Lopez-Lezcano -
Kai Vehmanen -
Kjetil S. Matheussen -
Paul Davis