Subject: NetBSD 1.4.1 - Clock stops when doing I/O
To: None <port-mac68k@netbsd.org>
From: Donald Lee <donlee_68k@icompute.com>
List: port-mac68k
Date: 01/04/2000 00:41:10
Dear list,
I just recently acquired a Quadra 840AV for $35. (I consider it a steal ;-> )
In theory, it should be faster than my Quadra 610, because it has
an 80 Mhz CPU w/ 40 Mhz bus and the Q610 has a 40 Mhz CPU with a 25 Mhz bus.
Depending on who you ask, the CPU rates on both may be half that, but in
any case, the 840 AV should be faster.
I ran some benchmarks, and the result are disappointing.
I'm running a newly installed NetBSD 1.4.1.
I run the following sophisticated CPU bmark.
#include <stdio.h>
static dummy = 0;
#define MAX 1000000
main()
{
int i;
for ( i = 0 ; i < MAX ; i++ )
funk();
}
int
funk()
{
dummy = 0;
}
This shows that the CPU on the 840 is about 30% faster than the Q610.
I show this with: "time a.out" on each system.
Unfortunately, when I do anything else, like compiles, gzip, etc, I
pretty consistently get poorer performance on the Q840. I figured
this may be due to the relatively low-performance disk in it
(Quantum Fireball 1.2Gb)
So, I wrote a sophisticated I/O bencmark.
mercy$ cat io.c
#include <fcntl.h>
#include <stdio.h>
#define RECSZ 16384
#define NREC 1024
main()
{
int fd;
char buf[RECSZ];
fd = open("dummy", O_RDWR|O_CREAT, 0666);
writem(fd, buf, RECSZ, NREC);
}
writem(int fd, char *buf, int recsz, int nrec)
{
int i;
for (i = 0 ; i < nrec ; i++)
write(fd, buf, recsz);
}
What I saw was that when I built this and ran it on the two
systems side-by-side, the Q610 shows about 40 seconds of wall-time,
and the Q840AV shows only about 9. Unfortunately, the Q840
finishes....
about 20 seconds *after* the Q610.
The upshot is that while this program is running, the real-time/wall-time
clock on the Q840 slows down to about one tenth of its proper speed.
Two questions:
1. Is there something broken on the Q840 that would slow down
the CPU and/or I/O? any options that I should be setting?
2. Why does the clock behave so badly? If this is a known
problem in 1.4.1, will it be fixed in the (soon to be releaed??)
1.4.2?
Thanks in advance,
-dgl-