Abysmal AMIX Performance

Ugh, AMIX is practically unusable.  I can’t believe that Commodore would ship something this bad.  Oh wait, yes I can.  But, in this case, I’m sure they didn’t.

I downloaded the gzip source from my local ftp server and it transferred at 40K/s which is terrible for a 10Mbs ethernet.  Under AmigaDOS, I was getting 350K/s so this is substantially slower.  1M/s should be the theoretical maximum.

Running the ./configure command took 45 minutes before the first line of output…and then eventually crashed because AMIX’s “rm -f” fails when not given a filename (it’s supposed to succeed, per the POSIX spec).

So I’m curious if this is a hardware issue or just AMIX.  I wouldn’t be surprised if it was a combination of the two, honestly.

A quick check online shows that the maximum speed for Zorro II is around 3.56M/s, so one can’t expect anything faster than that coming over the bus.

I did one of my standard tests:  copy 100M from /dev/zero to /dev/null.  It should be the fastest transfer one can do because its strictly in memory.  That’s more than 10x the memory size, so it should overrun any caching.

bash# time dd if=/dev/zero of=/dev/null bs=1024 count=102400
102400+0 records in
102400+0 records out

real 4:21.0
user 26.3
sys 3:53.4

4:21 is 261 seconds…that works out to around 401.7K/s.   That’s…well, it’s a number.  This transfer may be bound by Zorro II bus speed, but even so, that’s really slow.

The next test is a write from /dev/zero to a file on the disk.  20M is larger than RAM by 2X, so it will overrun any caching.

bash# time dd if=/dev/zero of=/tmp/test.20M bs=1024 count=20480
20480+0 records in
20480+0 records out

real 6:06.1
user 3.5
sys 2:45.1

6:06 is 366 seconds…so we’re talking about 33K/s.  Awful.  Simply awful.

Reading is better…

bash# time dd if=/tmp/test.20M of=/dev/null bs=1024
20480+0 records in
20480+0 records out

real 1:23.3
user 2.7
sys 1:02.0

but 252K/s is still terrible.

This would explain a lot, actually.   A bunch of random reads would be a lot worse than a big long read from the disk.

So one thing I did when I did the install was manually enter the disk parameters, rather than using the drive-supplied values.  SCSI uses block addressing rather than CHS, so it shouldn’t make a difference if the geometry is somewhat out of what.

Well, it might make a difference, now that I think about it.  If what appears to be a logical cylinder from the standpoint of the OS actually straddles two physical cylinders, there’s going to be an increased seek time across the board.  UFS DOES use cylinder information for disk layout, so this is a distinct possibility.

There’s only one way to test this — reinstall the system and run the tests again.