From: Benno Senoner <sbenno@gardena.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, pbd@op.net
Subject: hdrbench 0.1, high performance multitrack HD recording/playback benchmark released
Date:	Sat, 15 Apr 2000 15:53:09 +0200

Hi,

I finally I finished my multitrack HD recording/playback benchmark.

http://www.linuxdj.com/hdrbench

for filesystem developers: this util could be useful to compare different
filesystems on the same hardware since this app really stresses the disk, 
both seek performance and disk throughput are needed at the same time.
(plus both read and writes occur simultaneously)

The goal is to provide an easy to use benchmark which tries to reproduce
real-world conditions when doing heavyduty multitrack HD recording/playback.
Plus provide a skeleton of code, how to do HDR in an efficient way.

Basically it plays back N tracks from disk while recording M tracks to the
disk. That means a total of N+M tracks are processed  simultanesoulsy by the
app. To achieve best performance a 2 thread model is used:  the audio thread
which runs with highest priority (SCHED_FIFO), which communicates with a disk
butler thread using lock free FIFOs  (ringbuffers, see ringbuffer.h ). The disk
thread runs at lower priority and is responsible to  keep the inputtrack
buffers as full as possible while keeping the outputtrack buffers as empty as
possible. 
The program stops with an error if more than 80% of the total buffersize gets available in one of the buffers. 
I did choose this because we want a HIGH DEGREE of reliability.


You can analyze the results graphically:
for example  this pic
http://www.linuxdj.com/hdrbench/graph-18-18.gif

shows the buffer usage when reading about 18 streams from disk while writing 18
more streams to the disk.
Each stream has a datarate of about (44100*4bytes) 180Kbytes/sec , the total IO
datarate is 6.3MB/sec.
This is about the maximum I can get out using 1MB (holds 4-5secs of audio) of
buffer per track.

I am not doing any for of inode preallocation, that means all the output files
are generated on the fly.
As you can see there are quite large peaks in the graph, probably caused by
write buffer flushing, metadata updates or inode allocation.

Paul, seems that you can get a quite high number of tracks , without being
forced to do disk preallocation. I have not tested how many tracks you can do
when doing preallocation, but I suspect that this number is not significantly
higher (a few tracks more). But maybe you can keep the max buffer usage down.
 

When you look at my page you can see that the mixed read and write is the most
stressful one, from a filesystem latency POV.
Reading many tracks while writing only a few ones or 
writing many tracks while reading only a few ones , doesn't cause as much
stress as when doing 50% / 50%  read/writes.
I can't say why this does happen, since I am not a filesystem expert. 

Anyway, please play with the benchmark, and let me know how well (bad) it
performs on your hardware, and if you find a faster algorithm than mine, which
can pump more tracks through you linux box. :-)

anyone with 10000rpm UW2 SCSI disks willing to test it ?
Paul can you test it when you get some time ? *
(the code is written in C++ , supports both OSS and ALSA and stereo and mono
operation, therefore it should be easy to get it working on the Hammerfall (but
you have to change the NUMFRAGMENTS #defines in  hdrbench.cpp ))

comments, suggestions, ideas ?

Benno.