To: Paul Davis <paul@linuxaudiosystems.com>
Cc: Con Kolivas <kernel@kolivas.org>, linux <linux-kernel@vger.kernel.org>,
       Ingo Molnar <mingo@elte.hu>, rlrevell@joe-job.com,
       CK Kernel <ck@vds.kolivas.org>, utz <utz@s2y4n2c.de>,
       Andrew Morton <akpm@osdl.org>, alexn@dsv.su.se,
       Rui Nuno Capela <rncbc@rncbc.org>
Subject: Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt
 scheduling
References: <200501201542.j0KFgOwo019109@localhost.localdomain>
From: "Jack O'Quin" <joq@io.com>
Date: Thu, 20 Jan 2005 10:47:38 -0600
In-Reply-To: <200501201542.j0KFgOwo019109@localhost.localdomain> (Paul
 Davis's message of "Thu, 20 Jan 2005 10:42:24 -0500")
Message-ID: <87y8eo9hed.fsf@sulphur.joq.us>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture,
 linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1772
Lines: 38

Paul Davis <paul@linuxaudiosystems.com> writes:

>>That's discouraging about reiserfs.  Is it version 3 or 4?  Earlier
>>versions showed good realtime responsiveness for audio testers.  It
>>had a reputation for working much better at lower latency than ext3.
>
> over on #ardour last week, we saw appalling performance from
> reiserfs. a 120GB filesystem with 11GB of space failed to be able to
> deliver enough read/write speed to keep up with a 16 track
> session. When the filesystem was cleared to provide 36GB of space,
> things improved. The actual recording takes place using writes of
> 256kB, and no more than a few hundred MB was being written during the
> failed tests.
>
> everything i read about reiser suggests it is unsuitable for audio
> work: it is optimized around the common case of filesystems with many
> small files. the filesystems where we record audio is typically filled
> with a relatively small number of very, very large files.

I was not speaking of its disk performance, but rather of low-latency
CPU performance.  In 2.4 with the low-latency patches, reiserfs did
that fairly well.

I know its design is not focused on streaming large blocks of data to
disk.  But, when you're recording clicks every 20 seconds, disk
throughput is definitely a secondary consideration.

Looks like we need to do another study to determine which filesystem
works best for multi-track audio recording and playback.  XFS looks
promising, but only if they get the latency right.  Any experience
with that?
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/