I sometimes encounter situations where Pd (0.35/Linux) spontaneusly starts eating all available CPU, and I have to wait until I can get a keystroke in edgewise to kill it. While this is going on,
watchdog: signaling pd...
is printed repeatedly in the terminal, but apparently this watchdog is unsuccessful. Is it supposed to turn off DSP or something?
Ben
On Thu, 7 Nov 2002, Ben Saylor wrote:
I sometimes encounter situations where Pd (0.35/Linux) spontaneusly starts eating all available CPU, and I have to wait until I can get a keystroke in edgewise to kill it. While this is going on,
watchdog: signaling pd...
is printed repeatedly in the terminal, but apparently this watchdog is unsuccessful. Is it supposed to turn off DSP or something?
I never looked at the code but I think the signal is handled by the engine dropping some synthesis cycles which is usually enough to give you a chance to kill it or send some message that hopefully kill the task. Turning the DSP off may not be a good choice in general.
Maurizio Umberto Puxeddu.
Hi, Ben Saylor hat gesagt: // Ben Saylor wrote:
I sometimes encounter situations where Pd (0.35/Linux) spontaneusly starts eating all available CPU, and I have to wait until I can get a keystroke in edgewise to kill it. While this is going on,
watchdog: signaling pd...
is printed repeatedly in the terminal, but apparently this watchdog is unsuccessful. Is it supposed to turn off DSP or something?
You're running pd with "-rt"? Then Pd gets a very high priority, which is good for latency, but might make your system unusable, if for example you have an indefinie loop in your patch ("bang~" and "until" are great for such loops) or something else goes wrong. To prevent this, PD has a watchdog process running, that has an even higher priority, but does nothing most of the time. I does however check, that the rest of Pd is running by "ping" messages. If no messages arrive for a certain time, the watchdog concludes, that something is very wrong and even tries to kill Pd.
see src/s_inter.c:
/* To prevent lockup, we fork off a watchdog process with higher real-time priority than ours. The GUI has to send a stream of ping messages to the watchdog THROUGH the Pd process which has to pick them up from the GUI and forward them. If any of these things aren't happening the watchdog starts sending "stop" and "cont" signals to the Pd process to make it timeshare with the rest of the system. (Version 0.33P2 : if there's no GUI, the watchdog pinging is done from the scheduler idle routine in this process instead.) */
ciao
Frank Barknecht _ ______footils.org__
It's supposed to put Pd to sleep for a short time by sending it a "HUP" signal that Pd should duly catch and go to sleep for 30 msec. The hope is that that would be an adequate amount of time for the rest of the system to sort of run minimally... if that wasn't done you'd never get your machine back.
There's another problem that I've been unable to resolve which is why the CPU usage mysteriously goes up on P4s (there have been postings about this but I don't have a P4 handy to try things on...) It has to do with the P4s throwing floating exceptions at rude times.
cheers Miller
On Thu, Nov 07, 2002 at 12:12:57AM -0600, Ben Saylor wrote:
I sometimes encounter situations where Pd (0.35/Linux) spontaneusly starts eating all available CPU, and I have to wait until I can get a keystroke in edgewise to kill it. While this is going on,
watchdog: signaling pd...
is printed repeatedly in the terminal, but apparently this watchdog is unsuccessful. Is it supposed to turn off DSP or something?
Ben
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi, Miller Puckette hat gesagt: // Miller Puckette wrote:
There's another problem that I've been unable to resolve which is why the CPU usage mysteriously goes up on P4s (there have been postings about this but I don't have a P4 handy to try things on...) It has to do with the P4s throwing floating exceptions at rude times.
Richard Dobson once wrote this on csound-list:
This can be handled in the source code either by adding a
similar small value inside the filter loop (bottom of
butter.c):
do {
t = *in++ - a[4] * a[6] - a[5] * a[7];
t += 0.000000001; /* prevent underflow */
y = t * a[1] + a[2] * a[6] + a[3] * a[7];
....
or using the macro widely disseminated via the music-dsp list:
#define IS_DENORMAL(f) (((*(unsigned int*)&f)&0x7f800000)==0)
used:
t = *in++ - a[4] * a[6] - a[5] * a[7];
if (IS_DENORMAL(t))
t = 0.0f;
y = t * a[1] + a[2] * a[6] + a[3] * a[7];
though that assumes 32bit floats, and will presumably need
fiddling for doubles. I get the impression this is
Pentium-specific - it may then also be possible to tell the
FPU not to raise denormal exceptions, or replace the default
handling with something else, or whatever....
Maybe this helps.
ciao
Frank Barknecht _ ______footils.org__
On Thu, Nov 07, 2002 at 07:31:48AM -0800, Miller Puckette wrote:
It's supposed to put Pd to sleep for a short time by sending it a "HUP" signal that Pd should duly catch and go to sleep for 30 msec. The hope is that that would be an adequate amount of time for the rest of the system to sort of run minimally... if that wasn't done you'd never get your machine back.
Ok. It does let me eventually get to the terminal to kill Pd, but just barely :) Would it be a better solution (or even possible) to force Pd to turn off DSP, or maybe lower its priority by a lot? Pd didn't respond when I tried to turn off DSP (using ctl-.), so I had to kill it and lost the changes I'd made to my patch.
There's another problem that I've been unable to resolve which is why the CPU usage mysteriously goes up on P4s (there have been postings about this but I don't have a P4 handy to try things on...) It has to do with the P4s throwing floating exceptions at rude times.
This happens to me on an Athlon XP 1800. But so far only with largeish patches that use several externs and plugins, so maybe one of them is the cause.
Thanks, Ben
I am pretty sure I was getting a similar effect on an PowerPC 604e/linux-ppc. I was using pd -rt on 4 Mac 8600s , and everything would work fine for a while. Then the machines would basically freeze, they were pingable, but I couldn't do anything and the sound playback would stop. And this is with pd playing back a few samples with no filtering or effects, so it shouldn't be using much CPU.
Its easy to reproduce, if you'd like some info on it.
.hc
On Thu, 7 Nov 2002, Miller Puckette wrote:
It's supposed to put Pd to sleep for a short time by sending it a "HUP" signal that Pd should duly catch and go to sleep for 30 msec. The hope is that that would be an adequate amount of time for the rest of the system to sort of run minimally... if that wasn't done you'd never get your machine back.
There's another problem that I've been unable to resolve which is why the CPU usage mysteriously goes up on P4s (there have been postings about this but I don't have a P4 handy to try things on...) It has to do with the P4s throwing floating exceptions at rude times.
cheers Miller
On Thu, Nov 07, 2002 at 12:12:57AM -0600, Ben Saylor wrote:
I sometimes encounter situations where Pd (0.35/Linux) spontaneusly starts eating all available CPU, and I have to wait until I can get a keystroke in edgewise to kill it. While this is going on,
watchdog: signaling pd...
is printed repeatedly in the terminal, but apparently this watchdog is unsuccessful. Is it supposed to turn off DSP or something?
Ben
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
zen
\
\
\[D[D[D[D
-
Ben Saylor -
Frank Barknecht -
Hans-Christoph Steiner -
Maurizio Umberto Puxeddu -
Miller Puckette