18 Dec
2003
18 Dec
'03
8:26 a.m.
John,
First, is your data disk separate from your system disk? If not, this could be part
of your problem. Second, what FS are you using? Ext3 is a bad choice since it puts the
journal in a different location from the file. I would recommend using Reiserfs for your
data partition. XFS might even be better but I haven't seen any tests on it yet.
Ext2 is better than ext3 but still not as good as Reiserfs. Another thing, turn off
syslogd, crond, etc before recording.
Jan
-----Original Message-----
From: "linux-audio-user-bounces(a)music.columbia.edu"
<linux-audio-user-bounces(a)music.columbia.edu> on behalf of "John Anderson"
<ardour(a)semiosix.com>
Sent: 18 Dec 2003 13:21:25 +0200
To: "linux-audio-user(a)music.columbia.edu"
<linux-audio-user(a)music.columbia.edu>
Subject: Re: [linux-audio-user] The trouble with disks
On Thu, 2003-12-18 at 13:09, Robert Jonsson wrote:
Did you put jacks tempfiles on a tmpfs partition ?
I regularily change /tmp to a tmpfs partition in /etc/fstab these days.
none /tmp tmpfs default 0 0
or something like that...
I have mine at /mnt/ramfs, with jack thusly configured. I read somewhere
that ramfs is purely memory based, whereas tmpfs can use disk as backup
if it needs to expand.
bye
John
18 Dec
18 Dec
9:15 a.m.
New subject: [linux-audio-user] The trouble with disks
On Thu, 2003-12-18 at 14:25, eviltwin69(a)cableone.net wrote:
John,
First, is your data disk separate from your system disk? If not,
this could be part of your problem.
The data is on a separate partition, not a separate disk. It may be part
of the problem, but it seems to me not a big part because the pattern of
disk reads and dropouts only happens when I'm playing a session for the
first time. The disk activity pattern is completely different when the
machine is otherwise idling. And unless I go for a raid setup, the
system would still have to read all the audio data off one disk.
Second, what FS are you using?
Reiserfs
Ext2 is better than ext3 but still not as good as
Reiserfs. Another
thing, turn off syslogd, crond, etc before recording.
Recording (one or two tracks at a time, anyway) is OK. It's reading more
than about 3 tracks that seems to cause the trouble. And if the output
from top is anything to go by, it happens because disk reads cause the
cpu to spend too much time waiting on io to prevent the audio buffers
from emptying. I went through a patch a few weeks ago where I killed
off every process that wasn't necessary, and the problem persisted.
bye
John
11:52 a.m.
New subject: [linux-audio-user] The trouble with disks
On Thu, 2003-12-18 at 14:25, eviltwin69(a)cableone.net wrote:
John,
Is it that you must play *this* session one time, or can you play *any*
session one time and then the next session is OK? It would be an interesting
test to run Ardour with some dummy session, experience the problem, run the
dummy session again, experience it's fixed, and then load the session you
are using now and see what happens on the first pass with that session.
It may be audio caching that's fixing things, or possibly it's some part
of Ardour that's not getting loaded until it's needed.
I saw a couple of problems similar to this with Pro Tools before I added
my first 1394 audio drive a few years ago. Never understood why it happened.
John,
First, is your data disk separate from your system disk? If not,
this could be part of your problem.
The data is on a separate partition, not a separate disk. It may be part
of the problem, but it seems to me not a big part because the pattern of
disk reads and dropouts only happens when I'm playing a session for the
first time. The disk activity pattern is completely different when the
machine is otherwise idling. And unless I go for a raid setup, the
system would still have to read all the audio data off one disk. Second, what FS are you using?
Reiserfs
Ext2 is better than ext3 but still not as good as
Reiserfs. Another
thing, turn off syslogd, crond, etc before recording.
Recording (one or two tracks at a time, anyway) is OK. It's reading more
than about 3 tracks that seems to cause the trouble. And if the output
from top is anything to go by, it happens because disk reads cause the
cpu to spend too much time waiting on io to prevent the audio buffers
from emptying. I went through a patch a few weeks ago where I killed
off every process that wasn't necessary, and the problem persisted.
19 Dec
19 Dec
3:24 a.m.
New subject: [linux-audio-user] The trouble with disks
On Thu, 2003-12-18 at 17:47, Mark Knecht wrote:
John,
Is it that you must play *this* session one time, or can you play *any*
session one time and then the next session is OK?
You have to play *this* session one time, and after that it's OK. Same
thing if I load up another session. Same if I rewind to the beginning of
the session from partway through. The first part is fine (reading from
disk cache) and the grrtz comes back after that.
[snip]
I think this is where there are some misconceptions
that we all have
about measuring disk performance WRT audio apps. Logically, if you are
reading back many audio tracks from a drive, and if they all happen to be
located very closely together, then there will be less seek time required to
get the data. However, if they are all scattered over the drive then you
could spend a huge amount of time seeking to actually get very little data
from the drive.
That was my thinking - the read head seeking all over the disk for the
various regions.
A quick calculation: 44.1K samples/second *
24-bits/sample = 132.3K
Bytes/Sec for a mono channel. At only 8 channels you'd barely be over
1MB/Sec in streaming bandwidth. (2MB/Sec if they are stereo.) Certainly your
disk can handle that if the system cooperates.
iostat tells me it's reading < 1Mb/sec. hdparm tells me the disk can do
50Mb/sec. iostat and my ears tell me that whenever there's a dropout,
the system is spending about 6% of it's time in iowait.
I suspect the problem is something else....
What are the other options? I've looked at PCI latencies for card and
drive controller, IRQ ordering (although APIC seems to make this
irrelevant, or at least uncontrollable), OS disk scheduler
(anticipatory, deadline and cfq), tagged queueing (high values almost
guarantee xruns on recording but don't seem to improve playback).
Sheesh, at this rate if I get another dual-processor machine, I'll be
able to run jackd at -p 16 -n 2 :-|
bye
John
9:36 a.m.
New subject: [linux-audio-user] The trouble with disks
On Thu, 2003-12-18 at 23:24, John Anderson wrote:
A dual-processor system won't necessarily change a disk latency problem.
Have you tried running with larger buffers? Sorry but I don't have the
original post. Try -p 2048 -n 2 or -p 1024 -n 2 or -p 512 -n 4/8/16 if
your card accepts it and see what happens. Possibly there is just a
better setting to be using.
Also, have you run Benno's latency test app? It's good at showing
problems like other apps stepping in and causing problems somewhere, and
it can guide you towards the best -p/-n settings.
- Mark
A quick
calculation: 44.1K samples/second * 24-bits/sample = 132.3K
Bytes/Sec for a mono channel. At only 8 channels you'd barely be over
1MB/Sec in streaming bandwidth. (2MB/Sec if they are stereo.) Certainly your
disk can handle that if the system cooperates.
iostat tells me it's reading < 1Mb/sec. hdparm tells me the disk can do
50Mb/sec. iostat and my ears tell me that whenever there's a dropout,
the system is spending about 6% of it's time in iowait.
I suspect the problem is something else....
What are the other options? I've looked at PCI latencies for card and
drive controller, IRQ ordering (although APIC seems to make this
irrelevant, or at least uncontrollable), OS disk scheduler
(anticipatory, deadline and cfq), tagged queueing (high values almost
guarantee xruns on recording but don't seem to improve playback).
Sheesh, at this rate if I get another dual-processor machine, I'll be
able to run jackd at -p 16 -n 2 :-|
12:42 p.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2003-12-19 at 15:34, Mark Knecht wrote:
I had a dual-processor system until it died about 3 weeks ago. It
definitely didn't have this problem, even though it's using physically
the same SCSI controller and disk. Well, it had a 64bit PCI slot for the
controller. OK, I've upgraded to 2.6 since then, in a partially
successful attempt to reduce the extent of the dropouts.
What are the
other options? I've looked at PCI latencies for card and
drive controller, IRQ ordering (although APIC seems to make this
irrelevant, or at least uncontrollable), OS disk scheduler
(anticipatory, deadline and cfq), tagged queueing (high values almost
guarantee xruns on recording but don't seem to improve playback).
Sheesh, at this rate if I get another dual-processor machine, I'll be
able to run jackd at -p 16 -n 2 :-|
A dual-processor system won't necessarily change a disk latency problem. Have you tried running with larger buffers? Sorry but
I don't have the
original post. Try -p 2048 -n 2 or -p 1024 -n 2 or -p 512 -n 4/8/16 if
your card accepts it and see what happens. Possibly there is just a
better setting to be using.
Still happens, but less, at -p 2048 -n 2 which is the largest the card
will accept.
Also, have you run Benno's latency test app?
It's good at showing
problems like other apps stepping in and causing problems somewhere, and
it can guide you towards the best -p/-n settings.
Yip, 0 overruns on all tests at 2x128.
Real headscratcher, innit?
bye
John
1:31 p.m.
New subject: [linux-audio-user] The trouble with disks
Yip, 0 overruns on all tests at 2x128.
Real headscratcher, innit?
bye
John
Very perplexing. I've gone back and reread the whole thread. It certainly
seems like you've done all the basics and then much more to debug this. I
doubt anything I write here is actually the root cause and solution, but we
might as well keep trying.
A few questions did come up for me while reading:
1) When you say '0 overruns' above, how did you determine this? I found when
running this test that I'd sometimes get these 'blips' in the scheduling
time that would come close to the breakpoint, but not actually go over. Do
you see anything like that?
2) You said you tried tmpfs. What version of Jack are you using, and did you
recompile Jack to do that test?
3) How are you starting Jack? In a terminal or using qjackctl. I have not
reported this before, but I seem to see more xruns when using qjackctl than
when running Jack in a terminal with the same settings.
4) What command are you generally using to start Jack?
5) Since APIC is not necessary on a uni-processor, have you tried disabling
it at boot time?
6) Possibly important. You said you had a dual-processor up until a few
weeks ago. I presume that you were using the same sound card in that system?
(Thus eliminating the sound card itself as the culprit.) Were you using the
same hard drive?
7) Have you tried looking at this problem with sessions recorded at
different sample rates? In a conversation with another user the other day he
was telling me he gets more xruns at 44.1K than 48K.
- Mark
2:30 p.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2003-12-19 at 19:28, Mark Knecht wrote:
Thanks
Yip, 0 overruns on all tests at 2x128.
Real headscratcher, innit?
bye
John
Very perplexing. I've gone back and reread the whole thread. It certainly
seems like you've done all the basics and then much more to debug this. I
doubt anything I write here is actually the root cause and solution, but we
might as well keep trying. A few questions did come up for me while reading:
1) When you say '0 overruns' above, how did you determine this? I found when
running this test that I'd sometimes get these 'blips' in the scheduling
time that would come close to the breakpoint, but not actually go over. Do
you see anything like that?
Yeah, there was a pretty regular series of spikes in white. None of them
were closer than, say 10-15% of the total distance.
2) You said you tried tmpfs. What version of Jack are
you using, and did you
recompile Jack to do that test?
0.91.3, I've been updating from CVS every few days since about 3 weeks
ago. That was just before 0.90 IIRC.
3) How are you starting Jack? In a terminal or using
qjackctl. I have not
reported this before, but I seem to see more xruns when using qjackctl than
when running Jack in a terminal with the same settings.
4) What command are you generally using to start Jack?
In a terminal. jackd -R -d alsa -d hw:0 -p 256 -n 3
5) Since APIC is not necessary on a uni-processor,
have you tried disabling
it at boot time?
I tried removing the option and recompiling the kernel when I was
messing around with IRQ priorities. Didn't seem to make much of a
difference so I put it back to APIC and left it there.
6) Possibly important. You said you had a
dual-processor up until a few
weeks ago. I presume that you were using the same sound card in that system?
(Thus eliminating the sound card itself as the culprit.) Were you using the
same hard drive?
Same hard drive, same SCSI controller, same sound card. Only difference
from that point of view is that the SCSI controller used to be in a
64bit PCI slot. But I can't see that making a huge difference because
the throughput from one drive wouldn't even begin to get close to the
throughput limits of a 32 bit slot. Well, I'm guessing here.
7) Have you tried looking at this problem with
sessions recorded at
different sample rates? In a conversation with another user the other day he
was telling me he gets more xruns at 44.1K than 48K.
Only at 48k - that's all I've got.
bye
John
2:51 p.m.
New subject: [linux-audio-user] The trouble with disks
Yeah, there was a pretty regular series of spikes in white. None of them
were closer than, say 10-15% of the total distance.
On the surface of it that sound pretty safe.
0.91.3, I've been updating from CVS every few days since about 3 weeks
ago. That was just before 0.90 IIRC.
I think the point that Jan made in another thread somewhere on this tmpfs
subject (and I may be wrong here so don't take this as gospel) is that since
Jack is now compiled to use a specific FIFO location, if you change the
location in fstab then you *must* recompile Jack to point it to the new
location. I'm just being extra careful in asking you if you actually did
that recompile.
Some command like 'jackd --version' will tell you where it's pointing, and
you can look at the directory and see if the files are there.
4) What command are you generally using to start
Jack?
In a terminal. jackd -R -d alsa -d hw:0 -p 256 -n 3
Same hard drive, same SCSI controller, same sound card. Only difference
from that point of view is that the SCSI controller used to be in a
64bit PCI slot. But I can't see that making a huge difference because
the throughput from one drive wouldn't even begin to get close to the
throughput limits of a 32 bit slot. Well, I'm guessing here.
No, you are right, and others are getting many more tracks than you without
64-bit slots, so unless the SCSI controller itself has an issue being in a
32-bit slot I don't think this is it.
Only at 48k - that's all I've got.
Because that's all the sound card will do? It won't run at 44.1K?
An idea? Have you tried running an 'all software' experiment, or 'almost all
software', to understand whether it's really the disk causing this? What
happens if you load up a CD with Alsaplayer and play it, and then patch in
some Jack clients like freqtreak, tapiir, etc., multiple times to create a
lot of Jack traffic, but little or no hard disk traffic? You can create an
arbitrarily complicated setup to maybe explore whether the problem is with
Jack, or possibly with your motherboard, it's memory usage, other
applications that are running. If these work right, but then a disk based
operation fails, you have more info....
Cheers,
Mark
3:16 p.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2003-12-19 at 20:47, Mark Knecht wrote:
The card is fine at 44.1 - it's a Terratec EWS88MT. I just haven't used
48K for my ardour sessions.
I think the point that Jan made in another thread
somewhere on this tmpfs
subject (and I may be wrong here so don't take this as gospel) is that since
Jack is now compiled to use a specific FIFO location, if you change the
location in fstab then you *must* recompile Jack to point it to the new
location. I'm just being extra careful in asking you if you actually did
that recompile.
Oh, right. Yeah, I did recompile to use the location where I have tmpfs
mounted. And jackd --version gives me the same directory.
Only at 48k -
that's all I've got.
Because that's all the sound card will do? It won't run at 44.1K? An idea? Have you tried running an 'all
software' experiment, or 'almost all
software', to understand whether it's really the disk causing this? What
happens if you load up a CD with Alsaplayer and play it, and then patch in
some Jack clients like freqtreak, tapiir, etc., multiple times to create a
lot of Jack traffic, but little or no hard disk traffic? You can create an
arbitrarily complicated setup to maybe explore whether the problem is with
Jack, or possibly with your motherboard, it's memory usage, other
applications that are running. If these work right, but then a disk based
operation fails, you have more info....
Sounds good, I'll try that.
bye
John
3:26 p.m.
New subject: [linux-audio-user] The trouble with disks
Sounds good, I'll try that.
Good luck. We'll be watching.
And try a quick little session at 44.1K just to see what happens. Record
some audio from Alsaplayer to disk at 44.1K, and then build up a session
with multiple copies and see what happens. It would take long.
Cheers,
Mark
4:03 p.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2003-12-19 at 20:47, Mark Knecht wrote:
An idea? Have you tried running an 'all
software' experiment, or 'almost all
software', to understand whether it's really the disk causing this? What
happens if you load up a CD with Alsaplayer and play it, and then patch in
some Jack clients like freqtreak, tapiir, etc., multiple times to create a
lot of Jack traffic, but little or no hard disk traffic? You can create an
arbitrarily complicated setup to maybe explore whether the problem is with
Jack, or possibly with your motherboard, it's memory usage, other
applications that are running. If these work right, but then a disk based
operation fails, you have more info....
OK, running jackd -n 3 -p 256, a (pre-played ;-) ardour session,
alsaplayer with a CD, freqtweak reading from ardour and alsaplayer and
sending output to the card (two completely different audio streams.
Yuck.), with jack_lsp -c giving
alsa_pcm:capture_1
ardour:bass/in 1
ardour:mekody/in 1
alsa_pcm:capture_2
ardour:bass/in 1
ardour:mekody/in 1
alsa_pcm:capture_3
ardour:Riddimpick/in 1
ardour:Chords/in 1
ardour:Vocal/in 1
ardour:Mouette/in 1
ardour:Chords2/in 1
alsa_pcm:capture_4
ardour:Riddimpick/in 1
ardour:Vocal/in 1
ardour:Mouette/in 1
ardour:Chords2/in 2
alsa_pcm:capture_5
alsa_pcm:capture_6
alsa_pcm:capture_7
alsa_pcm:capture_8
alsa_pcm:capture_9
alsa_pcm:capture_10
alsa_pcm:capture_11
alsa_pcm:capture_12
alsa_pcm:playback_1
alsaplayer-6399:out_1
ardour:Mix/out 1
ardour:auditioner/out 1
alsa_pcm:playback_2
alsaplayer-6399:out_2
ardour:Mix/out 2
ardour:auditioner/out 2
alsa_pcm:playback_3
freqtweak_1:out_1
ardour:Mix/out 1
alsa_pcm:playback_4
freqtweak_1:out_2
ardour:Mix/out 2
alsa_pcm:playback_5
alsa_pcm:playback_6
alsa_pcm:playback_7
alsa_pcm:playback_8
alsa_pcm:playback_9
alsa_pcm:playback_10
ardour:auditioner/out 1
alsa_pcm:playback_1
ardour:auditioner/out 2
alsa_pcm:playback_2
ardour:click/out 1
ardour:stick/in 1
ardour:Mix/in 2
ardour:Mix/in 1
ardour:Violin/out 1
ardour:Mix/in 1
ardour:Violin/out 2
ardour:Mix/in 2
ardour:Viola/out 1
ardour:Mix/in 1
ardour:Viola/out 2
ardour:Mix/in 2
ardour:Chords2/out 1
ardour:Mix/in 1
ardour:Chords2/out 2
ardour:Mix/in 2
ardour:Mouette/out 1
ardour:Mix/in 1
ardour:Mouette/out 2
ardour:Mix/in 2
ardour:Vocal/out 1
ardour:Mix/in 1
ardour:Vocal/out 2
ardour:Mix/in 2
ardour:Chords/out 1
ardour:Mix/in 2
ardour:Mix/in 1
ardour:Riddimpick/out 1
ardour:Mix/in 1
ardour:Riddimpick/out 2
ardour:Mix/in 2
ardour:Durms/out 1
ardour:Mix/in 1
ardour:Durms/out 2
ardour:Mix/in 2
ardour:Mix/in 1
ardour:bass/out 1
ardour:mekody/out 1
ardour:stick/out 1
ardour:Chords2/out 1
ardour:Mouette/out 1
ardour:Durms/out 1
ardour:click/out 1
ardour:Riddimpick/out 1
ardour:Chords/out 1
ardour:Vocal/out 1
ardour:Violin/out 1
ardour:Viola/out 1
ardour:Mix/in 2
ardour:bass/out 1
ardour:mekody/out 2
ardour:stick/out 1
ardour:Chords2/out 2
ardour:Mouette/out 2
ardour:Durms/out 2
ardour:click/out 1
ardour:Chords/out 1
ardour:Riddimpick/out 2
ardour:Violin/out 2
ardour:Vocal/out 2
ardour:Viola/out 2
ardour:Mix/out 1
freqtweak_1:in_1
alsa_pcm:playback_3
alsa_pcm:playback_1
ardour:Mix/out 2
freqtweak_1:in_2
alsa_pcm:playback_4
alsa_pcm:playback_2
ardour:stick/out 1
ardour:Mix/in 1
ardour:Mix/in 2
ardour:mekody/out 1
ardour:Mix/in 1
ardour:mekody/out 2
ardour:Mix/in 2
ardour:bass/out 1
ardour:Mix/in 1
ardour:Mix/in 2
ardour:Viola/in 1
ardour:Chords2/in 1
alsa_pcm:capture_3
ardour:Chords2/in 2
alsa_pcm:capture_4
ardour:Mouette/in 1
alsa_pcm:capture_4
alsa_pcm:capture_3
ardour:Violin/in 1
ardour:Vocal/in 1
alsa_pcm:capture_3
alsa_pcm:capture_4
ardour:Chords/in 1
alsa_pcm:capture_3
ardour:Riddimpick/in 1
alsa_pcm:capture_3
alsa_pcm:capture_4
ardour:Durms/in 1
ardour:Durms/in 2
ardour:stick/in 1
ardour:click/out 1
ardour:mekody/in 1
alsa_pcm:capture_2
alsa_pcm:capture_1
ardour:bass/in 1
alsa_pcm:capture_2
alsa_pcm:capture_1
freqtweak_1:in_1
alsaplayer-6399:out_1
ardour:Mix/out 1
freqtweak_1:out_1
alsa_pcm:playback_3
freqtweak_1:in_2
alsaplayer-6399:out_1
ardour:Mix/out 2
freqtweak_1:out_2
alsa_pcm:playback_4
alsaplayer-6399:out_1
freqtweak_1:in_1
freqtweak_1:in_2
alsa_pcm:playback_1
alsaplayer-6399:out_2
alsa_pcm:playback_2
<Phew> You think that's arbitrarily complicated enough?
and jackd -v output like this
load = 18.0664 max usecs: 960.000, spare = 4373.000
load = 18.4838 max usecs: 1008.000, spare = 4325.000
load = 17.9706 max usecs: 931.000, spare = 4402.000
load = 18.1827 max usecs: 981.000, spare = 4352.000
load = 17.6607 max usecs: 914.000, spare = 4419.000
load = 18.2059 max usecs: 1000.000, spare = 4333.000
load = 18.2535 max usecs: 976.000, spare = 4357.000
load = 18.1086 max usecs: 958.000, spare = 4375.000
load = 17.9798 max usecs: 952.000, spare = 4381.000
load = 18.2811 max usecs: 991.000, spare = 4342.000
load = 18.1036 max usecs: 956.000, spare = 4377.000
and the processor at 100% because qjackconnect went to lala land (seems
to disagree with 2.6 kernels, qjackctl as well), there was 1 xrun in 2
minutes 40 seconds. I'm pretty sure I heard the disk do something around
about then...
So to confirm it, I said find /, and the xruns were popping up 1 every 3
or 4 seconds, and sometimes more often.
This was on vanilla 2.6.0 with Pre-emptible Kernel turned on, for those
who've been asking.
bye
John
5:26 p.m.
New subject: [linux-audio-user] The trouble with disks
John Anderson <ardour(a)semiosix.com> writes:
This was on vanilla 2.6.0 with Pre-emptible Kernel
turned on, for those
who've been asking.
I'm not surprised, -p256 seems a bit too low for reliable operation
with 2.6 on my system. It runs, but not well. Personally, I suspect
some long paths with preemption disabled in the VM code, just a guess.
What happens with a 2.4 kernel patched for low-latency?
--
joq
20 Dec
20 Dec
3:43 a.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2003-12-19 at 23:24, Jack O'Quin wrote:
John Anderson <ardour(a)semiosix.com> writes:
The reason I moved to 2.6 in the first place was that I was having
trouble. But just to refresh my memory, I rebooted to 2.4, patched for
low latency and pre-emptibility, and sure enough, same symptoms. I
didn't forget to echo 1 >/proc/sys/kernel/lowlatency.
bye
John
This was on vanilla 2.6.0 with Pre-emptible
Kernel turned on, for those
who've been asking.
I'm not surprised, -p256 seems a bit too low for reliable operation
with 2.6 on my system. It runs, but not well. Personally, I suspect
some long paths with preemption disabled in the VM code, just a guess.
What happens with a 2.4 kernel patched for low-latency? 
4:15 a.m.
New subject: [linux-audio-user] The trouble with disks
On Sat, Dec 20, 2003 at 09:41:28AM +0200, John Anderson wrote:
On Fri, 2003-12-19 at 23:24, Jack O'Quin wrote:
Hmmm, this is getting weirder! I thought last night that your trouble
may have been caused by this:
- There are known performance problems with the default disk I/O scheduler
which show up when the workload is performing small, random reads and
writes (ie: database loads). Largely fixed in -mm.
http://kerneltrap.org/node/view/1816
But this can't be the case if it happened on 2.4.?? also.
Maybe you could benchmark your hard disk, or swap in another drive?
Hope you can get round this one.
Cheers,
Malcolm Smith
John Anderson <ardour(a)semiosix.com>
writes:
The reason I moved to 2.6 in the first place was that I was having
trouble. But just to refresh my memory, I rebooted to 2.4, patched for
low latency and pre-emptibility, and sure enough, same symptoms. I
didn't forget to echo 1 >/proc/sys/kernel/lowlatency.
This was on vanilla 2.6.0 with Pre-emptible
Kernel turned on, for those
who've been asking.
I'm not surprised, -p256 seems a bit too low for reliable operation
with 2.6 on my system. It runs, but not well. Personally, I suspect
some long paths with preemption disabled in the VM code, just a guess.
What happens with a 2.4 kernel patched for low-latency?
2 Jan
2 Jan
7:12 a.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2003-12-19 at 23:24, Jack O'Quin wrote:
John Anderson <ardour(a)semiosix.com> writes:
I've had some more time to play around with things. Eventually I ended
up going back to 2.4.22 patched for low latency and pre-emption. 2.6.0
and 2.6.0-mm2 would both xrun when I was recording. The 2.4 kernel will
record reliably, but I still get dropouts on disk reads.
What's interesting is that if I'm running jack (0.93.6 now, but the last
few releases as well) with *no* connections (except for the automatic
capture and playback ports on the card, 12 and 10 respectively) and I do
anything that involves a fair amount of disk reading (starting ardour,
or cat some-file.wav >/dev/null), I'll get a bunch of xruns.
jackd -R -d alsa -p 256 -n 3, running as root.
It's been while since this thread was started, so here's a refresher on
the box: Uniprocessor Athlon XP 2200+, 1Gb RAM, 36Gb Ultra3 SCSI
(Adaptec 29160 with Fujitsu MAN3367 drive). MSI K7N2 Delta motherboard.
Terratec EWS88MT soundcard. Using reiserfs as the filesystem.
This is all FYI at this point. I'm going to try to get hold of a fast
IDE disk, to see if the problem is somehow related to the SCSI subsystem
or drivers.
bye
John
This was on vanilla 2.6.0 with Pre-emptible
Kernel turned on, for those
who've been asking.
I'm not surprised, -p256 seems a bit too low for reliable operation
with 2.6 on my system. It runs, but not well. Personally, I suspect
some long paths with preemption disabled in the VM code, just a guess.
What happens with a 2.4 kernel patched for low-latency?
8:50 a.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2004-01-02 at 05:10, John Anderson wrote:
It's been while since this thread was started, so
here's a refresher on
the box: Uniprocessor Athlon XP 2200+, 1Gb RAM, 36Gb Ultra3 SCSI
(Adaptec 29160 with Fujitsu MAN3367 drive). MSI K7N2 Delta motherboard.
Terratec EWS88MT soundcard. Using reiserfs as the filesystem.
This is all FYI at this point. I'm going to try to get hold of a fast
IDE disk, to see if the problem is somehow related to the SCSI subsystem
or drivers.
This may sound strange but there have been reports of problems using
SCSI disk drives. IIRC it had something to do with the Adaptec (29160)
controllers. A really good article on SCSI vs IDE is at
http://www.prorec.com/prorec/articles.nsf/articles/1A37C1C69674D6D786256950…
Some of that article may come as a shock to hard-core SCSI fans ;-) I'm
running - 2.4.22 lowlat/preempt, uniprocessor AthlonXP 1700+, 512MB RAM,
60GB ATA 100 5400rpm Maxtor IDE disk drive (data drive only), AZZA KT3AV
KT133A Socket A motherboard, ST Audio (Hoontech) C-Port DSP2000 on IRQ
10 (not shared, IRQ 9 is unused), reiserfs. I hardly ever get any xruns
on this system so I'm pretty amazed that you're getting them. What does
your interrupt setup look like? I don't remember if we'd already
covered the interrupts before. Do lspci -vvv and make sure that you're
using IRQ 9 or 10 (or possibly 11) and it's not shared.
Jan
9:27 a.m.
New subject: [linux-audio-user] The trouble with disks
Do lspci -vvv and make sure that you're
using IRQ 9 or 10 (or possibly 11) and it's not shared.
I'd been having stability problems recently with one of my machines,
an Athlon 700 on an Abit KT7 RAID board. It would freeze during boot,
so that I'd only get one successful boot in every three or more. I
tried a new hard disc and all kinds of other tweaks, but nothing
improved the situation.
I think what happened is that while moving cards and tweaking the BIOS
to get my soundcard on IRQ 9, I'd screwed up something. I put the
soundcard in the first PCI slot after the AGP, thinking this would
help priority.
But on this motherboard at least, each pair of PCI slots (or the AGP
slot and the first PCI) seem to share an interrupt. So what I've done
is put the soundcard on the second PCI slot below the AGP slot, and
then the ethernet card two slots below that. I then reset the BIOS to
'load failsafe defaults' followed by 'load optimised defaults' and
that seems to have helped stability.
The ethernet card now shares an IRQ with the USB controllers, but
there doesn't seem to be a way around that. lspci now shows:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
(rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133
AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev
10)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
ACPI] (rev 30)
00:08.0 Ethernet controller: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller
00:0f.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24
[CrystalClear SoundFusion Audio Accelerator] (rev 01)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc.
HPT366/368/370/370A/372 (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage XL AGP 2X
(rev 65)
Cheers
Daniel
10:48 a.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2 Jan 2004 13:26:28 -0500
Daniel James <daniel(a)mondodesigno.com> wrote:
I'd been having stability problems recently with
one of my machines,
an Athlon 700 on an Abit KT7 RAID board. It would freeze during boot,
so that I'd only get one successful boot in every three or more. I
tried a new hard disc and all kinds of other tweaks, but nothing
improved the situation.
(snip)
I have one of these boards as well, and had a horrendous time with
lockups and freezes for a while.
The fix for me was to drop the CPU speed down from the 1.2GHz it defaulted
to 900MHz (the only other choice in the BIOS setup - I think I changed the
bus speed from 133MHz to 100). Once I did that, it hasn't locked up
since. One thing here to note is that I don't know with certainty what
the speed of the CPU is in the machine. It came to me second-hand, and
I didn't feel like pulling the fan off the CPU and wiping off the thermal
paste to find out. 900 is still plenty fast, and the machine is now
my wife's photography workstation.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
3 Jan
3 Jan
3:56 a.m.
New subject: [linux-audio-user] The trouble with disks
On Fri, 2004-01-02 at 14:47, Jan Depner wrote:
This may sound strange but there have been reports of
problems using
SCSI disk drives. IIRC it had something to do with the Adaptec (29160)
controllers.
Did some searching on google for this, but I can't find anything that
looks useful. Did some checking on the drive though, and it has claimed
seek times of 5 ms, just a bit slower than the 15000rpm seagate cheetah.
A really good article on SCSI vs IDE is at
http://www.prorec.com/prorec/articles.nsf/articles/1A37C1C69674D6D786256950…
Some of that article may come as a shock to hard-core SCSI fans ;-) I'm
running - 2.4.22 lowlat/preempt, uniprocessor AthlonXP 1700+, 512MB RAM,
60GB ATA 100 5400rpm Maxtor IDE disk drive (data drive only), AZZA KT3AV
KT133A Socket A motherboard, ST Audio (Hoontech) C-Port DSP2000 on IRQ
10 (not shared, IRQ 9 is unused), reiserfs. I hardly ever get any xruns
on this system so I'm pretty amazed that you're getting them. What does
your interrupt setup look like? I don't remember if we'd already
covered the interrupts before. Do lspci -vvv and make sure that you're
using IRQ 9 or 10 (or possibly 11) and it's not shared.
OK, I've argued with the motherboard now, and after several hours I've
convinced it to put the 29160 on IRQ 10, by itself. Previously it was on
RQ 10, sharing with one of the 3 (three!) USB controllers. IRQ 9 seems
to be locked to "acpi" by the motherboard - doesn't handle any
interrupts according to /proc/interrupts though. Still getting the xruns
as often as before, but they sound different - not as long or intense.
Hah. This is the first time I've discussed IRQs in terms of how they
sound ;-)
bye
John
9:30 a.m.
New subject: [linux-audio-user] The trouble with disks
I think you should try to turn acpi off. Where is your sound card in
terms of interrupts? Take a look at:
http://myweb.cableone.net/eviltwin69/Arcana.html#IRQs
If your sound card IRQ is not on 9 then interrupts on your SCSI card are
going to give you xruns since 10 is higher priority than everything else
(unless you can get 0, 1, or 8).
Jan
On Sat, 2004-01-03 at 01:54, John Anderson wrote:
On Fri, 2004-01-02 at 14:47, Jan Depner wrote:
This may sound strange but there have been
reports of problems using
SCSI disk drives. IIRC it had something to do with the Adaptec (29160)
controllers.
Did some searching on google for this, but I can't find anything that
looks useful. Did some checking on the drive though, and it has claimed
seek times of 5 ms, just a bit slower than the 15000rpm seagate cheetah.
A really good article on SCSI vs IDE is at
http://www.prorec.com/prorec/articles.nsf/articles/1A37C1C69674D6D786256950…
Some of that article may come as a shock to hard-core SCSI fans ;-) I'm
running - 2.4.22 lowlat/preempt, uniprocessor AthlonXP 1700+, 512MB RAM,
60GB ATA 100 5400rpm Maxtor IDE disk drive (data drive only), AZZA KT3AV
KT133A Socket A motherboard, ST Audio (Hoontech) C-Port DSP2000 on IRQ
10 (not shared, IRQ 9 is unused), reiserfs. I hardly ever get any xruns
on this system so I'm pretty amazed that you're getting them. What does
your interrupt setup look like? I don't remember if we'd already
covered the interrupts before. Do lspci -vvv and make sure that you're
using IRQ 9 or 10 (or possibly 11) and it's not shared.
OK, I've argued with the motherboard now, and after several hours I've
convinced it to put the 29160 on IRQ 10, by itself. Previously it was on
RQ 10, sharing with one of the 3 (three!) USB controllers. IRQ 9 seems
to be locked to "acpi" by the motherboard - doesn't handle any
interrupts according to /proc/interrupts though. Still getting the xruns
as often as before, but they sound different - not as long or intense.
Hah. This is the first time I've discussed IRQs in terms of how they
sound ;-)
bye
John
3:39 p.m.
New subject: [linux-audio-user] The trouble with disks
On Sat, 2004-01-03 at 15:28, Jan Depner wrote:
I think you should try to turn acpi off. Where is
your sound card in
terms of interrupts? Take a look at:
http://myweb.cableone.net/eviltwin69/Arcana.html#IRQs
Google already found that for me ;-)
If your sound card IRQ is not on 9 then interrupts on
your SCSI card are
going to give you xruns since 10 is higher priority than everything else
(unless you can get 0, 1, or 8).
So now I've manged to convince the mobo to put scsi on 11, and the sound
card on 10 (was on 5). 11 is shared with a usb controller, but it
doesn't seem to get any interrupts - moving the mouse racks up
interrupts one of the other USB controllers (while true; do cat
/proc/interrupts; sleep 0.6; done). Unfortunately the BIOS settings
don't allow me to set the interrupts for onboard devices.
I've also turned acpi off (no harm in trying that again, I guess).
Still getting xruns, doesn't seem to be much different to before. Until
the files are cached, then it's fine, as usual. On the positive side,
did a bunch of recording today, and everything was good (after the usual
preload-to-cache tricks). It's also heartening to know that folks are
running similar spec boxes to mine and not getting xruns.
bye
John
4:34 p.m.
New subject: [linux-audio-user] The trouble with disks
John Anderson wrote on Sat, 03-Jan-2004:
I've also turned acpi off (no harm in trying that
again, I guess).
Still getting xruns, doesn't seem to be much different to before. Until
the files are cached, then it's fine, as usual. On the positive side,
did a bunch of recording today, and everything was good (after the usual
preload-to-cache tricks). It's also heartening to know that folks are
running similar spec boxes to mine and not getting xruns.
I'm assuming (although i don't remember you mentioning it) that
you have configured JACK's tmpdir to be on a tmpfs?
jlc
5:10 p.m.
New subject: [linux-audio-user] The trouble with disks
Aha! I knew I remembered something about Adaptec and the envy24
chipset. Check this out:
http://www.staudio.de/kb/english/conflicts/index.html
Granted, this is the ST Audio card and a 2940 but the chipset is the
same on the audio card and the 29160 is just a faster version of the
29160 (note that there are problems with the on-board SCSI controllers
too). After re-finding this (it's linked on my web site) I would
*definitely* recommend getting a cheap IDE drive for your audio data.
Jan
On Sat, 2004-01-03 at 14:29, Jesse Chappell wrote:
John Anderson wrote on Sat, 03-Jan-2004:
I've also turned acpi off (no harm in trying
that again, I guess).
Still getting xruns, doesn't seem to be much different to before. Until
the files are cached, then it's fine, as usual. On the positive side,
did a bunch of recording today, and everything was good (after the usual
preload-to-cache tricks). It's also heartening to know that folks are
running similar spec boxes to mine and not getting xruns.
I'm assuming (although i don't remember you mentioning it) that
you have configured JACK's tmpdir to be on a tmpfs?
jlc
6:03 p.m.
New subject: [linux-audio-user] The trouble with disks
On Sat, 2004-01-03 at 23:08, Jan Depner wrote:
Aha! I knew I remembered something about Adaptec and
the envy24
chipset. Check this out:
http://www.staudio.de/kb/english/conflicts/index.html
AaaAAAaaaAaArgh!
<mutter mutter>"Reputable" brand names<mutter mutter>
Hmm. Maybe there's something that can be changed in the adaptec driver
that will make it work better in this situation.
Granted, this is the ST Audio card and a 2940 but the
chipset is the
same on the audio card and the 29160 is just a faster version of the
29160 (note that there are problems with the on-board SCSI controllers
too). After re-finding this (it's linked on my web site) I would
*definitely* recommend getting a cheap IDE drive for your audio data.
OK, so, any recommendations (or, um, condemnations?) for an IDE drive?
I'll let y'all know what happens. Many, many thanks for all the help.
bye
John
6:11 p.m.
New subject: [linux-audio-user] The trouble with disks
I've got both Maxtor and Western Digital 5400RPM drives and haven't had
a problem with either. I use IBM drives at work and they're fine too.
Jan
On Sat, 2004-01-03 at 16:00, John Anderson wrote:
On Sat, 2004-01-03 at 23:08, Jan Depner wrote:
Aha! I knew I remembered something about Adaptec
and the envy24
chipset. Check this out:
http://www.staudio.de/kb/english/conflicts/index.html
AaaAAAaaaAaArgh!
<mutter mutter>"Reputable" brand names<mutter mutter>
Hmm. Maybe there's something that can be changed in the adaptec driver
that will make it work better in this situation.
Granted, this is the ST Audio card and a 2940 but
the chipset is the
same on the audio card and the 29160 is just a faster version of the
29160 (note that there are problems with the on-board SCSI controllers
too). After re-finding this (it's linked on my web site) I would
*definitely* recommend getting a cheap IDE drive for your audio data.
OK, so, any recommendations (or, um, condemnations?) for an IDE drive?
I'll let y'all know what happens. Many, many thanks for all the help.
bye
John
5:02 p.m.
New subject: [linux-audio-user] The trouble with disks
On Sat, 2004-01-03 at 13:37, John Anderson wrote:
So now I've manged to convince the mobo to put
scsi on 11, and the sound
card on 10 (was on 5). 11 is shared with a usb controller, but it
doesn't seem to get any interrupts - moving the mouse racks up
interrupts one of the other USB controllers (while true; do cat
/proc/interrupts; sleep 0.6; done). Unfortunately the BIOS settings
don't allow me to set the interrupts for onboard devices.
I've also turned acpi off (no harm in trying that again, I guess).
Still getting xruns, doesn't seem to be much different to before. Until
the files are cached, then it's fine, as usual. On the positive side,
did a bunch of recording today, and everything was good (after the usual
preload-to-cache tricks). It's also heartening to know that folks are
running similar spec boxes to mine and not getting xruns.
I wish I had your setup - it's much faster than mine ;-) What bothers
me is that we're using *very* similar setups and I don't have any
problems with mine. If I were you I would definitely try getting a
cheap IDE drive and using it for data (reiserfs of course). You might
even try two IDE drives and drop the SCSI controller. Also, it sounds
like you're using a USB mouse. I use the little converter from USB to
PS/2 just to avoid USB interrupts. My setup now has ICE1712 [Envy24] on
IRQ 10, nVidia NV6 [Vanta] on IRQ 11 shared with D-Link Ethernet, dual
USB controllers on IRQ 5.
Jan
19 Dec
19 Dec
6:40 p.m.
New subject: [linux-audio-user] The trouble with disks
LOL!!!!!
<SNIP>
alsa_pcm:capture_1
ardour:bass/in 1
ardour:mekody/in 1
<SNIP>
alsaplayer-6399:out_2
alsa_pcm:playback_2
<Phew> You think that's arbitrarily complicated enough?
I cannot even begin to understand what it means! It's beyond arbitrarily
complicated! We just had a Christmas party and I put away a couple of pints,
so I'll save the serious analysis for tomorrow! ;-)
and jackd -v output like this
<SNIP>
and the processor at 100% because qjackconnect went to lala land (seems
to disagree with 2.6 kernels, qjackctl as well), there was 1 xrun in 2
minutes 40 seconds. I'm pretty sure I heard the disk do something around
about then...
So to confirm it, I said find /, and the xruns were popping up 1 every 3
or 4 seconds, and sometimes more often.
So it does really appear to be disk based. Whether it's the disk itself, of
something about the way the disk interferes with other things going on I
don't know, but it's good data.
This was on vanilla 2.6.0 with Pre-emptible Kernel turned on, for those
who've been asking.
Interesting. Were you running 2.6 on your SMP machine 2 weeks ago? Same
revision of the kernel, or are you now using the new 2.6 stable release?
20 Dec
20 Dec
4:05 a.m.
New subject: [linux-audio-user] The trouble with disks
On Sat, 2003-12-20 at 00:36, Mark Knecht wrote:
The next thing to try is to get hold of a fast IDE disk and see if the
problem is related to the SCSI controller (or driver) or the SCSI disk.
2.6.0 stable. Freshly downloaded and compiled for my listening pleasure.
At least that's what I was hoping as I watched the progress meter for
wget...
I was using 2.4.22 with lowlatency patches on the SMP machine. Trouble
started with the uniprocessor, so I tried all sorts of things, including
the pre-emptible patches for 2.4. Then I went to 2.6.0-test9, then
2.6.0-test11, then 2.6.0-test11-mm1, then 2.6.0. Same story with all of
them.
bye
John
So to confirm
it, I said find /, and the xruns were popping up 1 every 3
or 4 seconds, and sometimes more often.
So it does really appear to be disk based. Whether it's the disk itself, of
something about the way the disk interferes with other things going on I
don't know, but it's good data.
This was on vanilla 2.6.0 with Pre-emptible Kernel turned on, for those
who've been asking.
Interesting. Were you running 2.6 on your SMP machine 2 weeks ago? Same
revision of the kernel, or are you now using the new 2.6 stable release? 
12:34 a.m.
New subject: [linux-audio-user] The trouble with disks
>> What are the other options? I've looked
>> at PCI latencies for card and drive
>> controller, IRQ ordering (although APIC
>> seems to make this irrelevant, or at least
>> uncontrollable), OS disk scheduler
>> anticipatory, deadline and cfq), tagged
>> queueing (high values almost guarantee
>> xruns on recording but don't seem to
>> improve playback).
I did many of the tests that you mention above. I finally got to the
point were I bought half a gig of ram (now have approx. 800Megs) and
mounted my "Record Directory" on a tmpfs. I move everything in tmpsf and
only do periodic saves to hard disk of the files that are changed as I go.
I guess the (overly obvious) quesion is, are you running as root? It
sounds like you're savy enough to have thought of that. But I just
thought I would ask (just in case). Running as root can eleviate certain
problems.
Rocco
7658
days inactive
7674
days old
linux-audio-user@lists.linuxaudio.org
29 comments
11 participants
participants (11)
-
Daniel James -
eviltwin69＠cableone.net -
Jack O'Quin -
Jan Depner
-
Jesse Chappell -
Joe Hartley -
John Anderson -
LinuxMedia -
Mark Knecht -
Mark Knecht -
Mr. Spock