Subject: Re: [linux-audio-dev] more numbers for multichannel playback
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 05 2000 - 08:11:01 EEST
>This looks kind of weird to me... The time it takes to read n bytes
>for T tracks should be something like
>
> avg_seek_time * T + n * T / avg_transfer_rate
>
>but the above suggests that something completely different is taking
>place...
Yes, the amount of memory used by the process was growing (the lack of
munmap to release pages), and so the the VM system was having a hard
time keeping up. I fixed this. It stops the address space growth, but
at a considerable price in terms of my design - it destroys it.
>Are your files by any chance heavily fragmented? (And do note that
No. All my tests are done on totally unfragmented files.
>The chunks (should roughly equal your disk write size, unless ext2 is
>being nasty) have to exactly match and coincide with the read size (ie
>you can't use any other size than 256 kB), or you'll get a lot more
>seek overhead as soon as the read-ahead fails to keep track of the
>mess.
trying to match the "disk write size" makes little difference. all
disk i/o is done in units of the filesystem block size, whether you
like it or not, plus the kernel always does NkB read-ahead whether you
ask for it or not, with N = 64 by default (can be set globally via
/proc/sys/<something>, or in 2.3.52 and above with madvise(2-not!)).
>I'm very positive that your drive can do a lot better than this, as
>the performance of my old 5.1 GB 5400 rpm IDE drive could cope with
>16 tracks of 44.1 kHz stereo using the same buffer size. Somewhere
>above 70% of the average transfer rate is where you should begin to
>expect problems - although you may have to dump ext2fs to get there.
I am actually deeply troubled by my inability to get more than about
10-15MB/sec from my nominally 80MB/sec drives. I don't expect 80, but
I do expect at least 40. I've tried (with no success) to find a
standard benchmark to make sure I'm not missing some obvious stuff,
but when I use the following program with a block size of <anything
above 256kB> i basically get 10MB/sec. This seems wrong, very wrong.
#include <stdio.h>
#include <asm/msr.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <sys/stat.h>
#include <sys/time.h>
#define MSEC_LIMIT 5000
main (int argc, char *argv[])
{
int fd;
unsigned long now;
unsigned long then;
off_t location;
char *buf;
int n;
struct stat statbuf;
size_t bufsize;
size_t file_size;
FILE *foo;
size_t data_read;
struct timeval start;
struct timeval end;
float total;
size_t times[MSEC_LIMIT];
bufsize = atoi (argv[2]);
if ((fd = open (argv[1], O_RDONLY)) < 0) {
fprintf (stderr, "cannot open %s (%s)\n",
argv[1], strerror (errno));
return -1;
}
fstat (fd, &statbuf);
file_size = statbuf.st_size - bufsize;
buf = (char *) malloc (bufsize);
memset (times, 0, sizeof (times));
if (mlock (buf, bufsize) == 0) {
printf ("Buffer locked\n");
}
data_read = 0;
gettimeofday (&start, 0);
while (1) {
size_t msecs;
size_t nread;
rdtscl (then);
if ((nread = read (fd, buf, bufsize)) < 0) {
fprintf (stderr, "read failed (%s)\n",
strerror (errno));
break;
}
if (nread == 0) {
break;
}
rdtscl (now);
data_read += nread;
msecs = (size_t) ((float) (now - then) / 450000.0f);
if (msecs < MSEC_LIMIT) {
times[msecs]++;
} else {
fprintf (stderr, "OOR: %u\n", msecs);
}
}
gettimeofday (&end, 0);
total =
(float) (((end.tv_sec * 1000000) + end.tv_usec) -
((start.tv_sec * 1000000) + start.tv_usec)) /
1000000.0f;
printf ("Time per MB = %.3f; MB/sec = %.3f\n",
total / ((float) data_read / 1048576.0f),
((float) data_read / 1048576.0f) / total);
foo = fopen ("readtimes", "w");
for (n = 0; n < sizeof(times)/sizeof(times[0]); n++) {
fprintf (foo, "%d %d\n", n, times[n]);
}
fclose (foo);
close (fd);
exit (0);
}
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 07:57:43 EEST