AMIX Reinstall

I went through the system and made sure that everything looked like what one would expect:

• both drives have the parity enable jumper set
• the SCSI chain is terminated on both ends

I reset the drive type on the internal drive by using the values the drive reports, repartitioned, copied the cpio image to the drive, and reinstalled.

I also removed the “DS” jumper on the drives which is for delayed start.  Since these drives were from a big disk array, it was unwise to start all of the spindles simultaneously.  Since these are being driven from different power supplies (one internal and one external) it really doesn’t make sense to wait for the first initialization command before spinning up the disk.

Hmm.  Writing 20M to the disk took 6:07 — roughly the same as before.

So it’s time to see if this is a hardware or an OS thing.  I want to install NetBSD anyway, so let’s do that.  I want to get a version that’s in the same time frame as AMIX so that means NetBSD 1.0 or 1.1.  The boot disk isn’t available on the network anymore for 1.0, so 1.1 it is!

I partitioned the disk as described in the instructions.  No problems there.  Copying the miniroot wasn’t an issue either.

Booting was a problem:  There’s a bug in the loadbsd program that comes with 1.1 — it has an illegal instruction and it crashes.  The loadbsd-2.14 version works just fine.

Once I got it booted to the minitroot, I had to get the distribution onto the disks.  NFS wouldn’t work.  And doing an ftp with a wildcard wouldn’t work either.  I had to tar up the packages on the server side and then download them by name and extract them again to get the structure.  No biggie, but something that took a few minutes to figure out.

Download speeds were much better than AMIX over ftp — 186-222K/s

I’ve started installing and the files are getting laid down onto the the filesystem.  It seems about the same pace as the AMIX install…but then I remember that the NetBSD packages are compressed, so there’s a lot of CPU work going on.

So after the system is installed and I reboot its time to do some testing.

Under AMIX, a 100M copy of /dev/zero to /dev/null averaged around 400K/s.  NetBSD is just over 1M/s.  That’s a huge improvement.

20M of /dev/zero to a disk file was 33K/s on AMIX….241K/s on NetBSD.  Reading that same file was 252K/s under AMIX and 355K/s with NetBSD.

So, overall, NetBSD is much faster on the same hardware.

A real world test is running configure for gzip, which is what started me down this path in the first place.  On AMIX it took around 45 minutes (two episodes of Pokemon) to output anything and it would crash shortly thereafter complaining that “rm -f” wasn’t standards compliant.

It took about 8 minutes to get to the first line of output, and then complained that my clock is out of whack.  So I killed it.

The performance is better under NetBSD — do I even keep AMIX?

Advertisement

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.

 

 

 

 

It worked

I got up and it had completed successfully.  I hit CTRL-A-A and shortly thereafter it started prompting me for setup:

I finished that up and brought up X:

Ah, glorious twm in monochrome at 640×400 interlace!

It was slow as hell, though…even for a machine of it’s vintage.  The disk operation s were incredibly sluggish.  Transfers were about 120K/s over FTP to my laptop.

I can’t help but to think that it’s because I was messing with the tracks/cylinders thing.  It should have made a difference, thought because SCSI doesn’t use them — it just uses block number and the drive is free to put it wherever is convenient.

Gonna have to research more.

 

 

 

 

Another shot at AMIX

Since my (former) DH0 is now trashed, I’m going to give this another shot.

I’m going to partition the drive from AmigaDOS using HDToolbox and go from there.  One thing I noticed was that the Cylinder/Heads/Sectors numbers were weird.  I know the drive doesn’t have 1 head and 1261 sectors per track, but apparently that’s what the system reported….or HDToolbox computed from what the drive returned.

The spec sheet for the drive says it has 9 heads…and coincidentally, 1260 divides by 9 evenly — 140.  Using those two numbers, I found a cylinder count which came pretty close to my original disk size.  I think I lost 2M overall.  I also suspect the number is low since this is a DEC-branded drive and I’d wager money that it reports a size that’s actually smaller than the capacity so it would match drives and models that DEC was sourcing so replacing disks in RAID arrays would work as expected.

But let’s be honest.  2G is still freaking huge for 1990/1993.

I repartitioned the drive and added a “AMIX_SOURCE” partition where I copied the cpio file.  So all of my AMIX stuff is on a single drive.  I have an older SCSI chip in the A2091, which is known to have issues when there is more than one device on the bus.  That may be what killed my install the other night, so I’m giving it a shot.

I rebooted and hit ^C to run the rdb command to see if it worked.  My partitions were there:

So I used /etc/profile and restarted the installation.  Then I thought about it…crap, the custom filesystem values didn’t take from HDToolbox.  Another ^C and some fumbling with the rdb command got me where I wanted to be

Even though the script asks for a number from 1-6 for the source drive, it happily took the 0 I have it and decided that the source partition was /dev/dsk/c0d0s4 — which matches the AMIX_SOURCE partition from the output of rdb.

It found my partitions and it was happy with them.

The cpio has started, so I’m going to bed and I’ll see how this shakes out tomorrow.

If I get the same error, I’m going to recopy the cpio file from my source and then onto the hard drive and try it again.

I feel a whole lot safer doing it with the HDtoolbox method.   Although it tends to miss flags.  It looks like the boot partition flags are wrong, but I’m hoping the install will fix it.  It listed as “P0 C0” and it should be “P2 C2”.

We’ll see.

AMIX in the house?

Since I got a good install of AmigaDOS 3.1 on the hard drives and put the bits that I really like, its time to start looking at AMIX.

I was originally going to do it right and make a killer install program, but I’m lazy right now.  It would require a ton of time on an actual AMIX machine…which I don’t have yet.  So I’m going to do the two-disk CPIO hack.  I have been looking around at the files on the root floppy to see if there are other choices and honestly, you can’t do much with 880K and no RAM disk.  I’m still pondering if one could use a miniroot partition as a bootstrap and then get the rest off of the network.

First chore was finding a second hard drive for the machine to install from.  Since it isn’t going to be a permanent addition to the machine, I wanted to find an external one.

So, going through my junk pile I found:

• An external case:  “ClubMac Mighty Mite” with 120M drive
• A 2G narrow SCSI drive (another RZ28M)
• A DB25 to Centronics-style SCSI cable from an old scanner
• A Centronics-style SCSI terminator

Hooray, that should do the trick.

I rebuilt the external drive and hooked it up.

Classy!  The AMIX boot and root floppies make a cameo on the lower right…

I started the download and saturated the 10Mbps link:

And after 1000 seconds, the file was downloaded:

274K/s.  That’s…not bad for a transfer of  this size on this hardware to disk.

Now it’s time to write that giant cpio file to the hard disk.  I grabbed NetBSD’s xstreamtodev and after several minutes of trying AmigaDOS-style flags, I grabbed the source and realized it took unix style.  I ended up using:

xstreamtodev --input=amix_2.1.cpio --device=scsi.device --unit=2 --verbose

since it was on SCSI ID 2.   It asked me if I wanted to write it to DDH0 (which is the RDB name for the first partition on that device), and I said yes.   It’s slowly chugging away copying it to the first partition on that device.  I guess I could have used the –rdb-name DDH0 option to do the same thing.

xstreamtodev failed at 28% so I ran it again and it stopped in the same place.  Hmm.  Then I did the math from the verbose output…starting at block 2822 and finishing at 598435 comes up to just over the size of the cpio file.  The 28% must be the relative position on the disk.  Going to have to see if it installs.

Reboot with boot & root.  Going through the installation, it looks like there are some problems with creating the different partitions.  Things RDB misalignments and whatnot.

So a quick search reveals that the best way to do it is to leave empty space at the beginning of the disk.  Crud.

This worked out after all:  The default partitioning on the external 2G drive split it into two halves.  I overwrote the first half with the cpio image for AMIX.  The other partition was empty.  Good thing I didn’t write straight to the device!

I copied DH0 to DH1 and rebooted from DH1 to make sure it would work.  The LED on the front of the case is somewhat misleading — it is lit on any SCSI access, so I couldn’t tell if the commands were for the internal or external drive.  A quick check showed that SYS: was on the external drive.

I repartitioned thusly:  I deleted the bogus AMIX partitions moved the AmigaDOS partition to around 634M (I want 600M for root, 30M for swap, 2M for boot) and created a Spare partition after the AmigaDOS one.

Moving the partition destroyed it, so now everything has to be copied back to the internal hard drive before I can move on.

After the copy AmiTCP stopped working and the boot failed to make it to workbench.  They license key file must not have been copied.  I image mounted the install disks and after several  re-installs, everything is back to normal.  It kept picking up parts of the old configuration.  Ugh.

Ok, so a reboot into the AMIX install and…AMIX screwed up my AmigaDOS install because the partitions were STILL out of alignment and it couldn’t build the boot partition.  That meant that the 3rd partition of the disk was not UNIX_Boot but…DH0.  It “fixed” the partition type and did a mkfs on my AmigaDOS install.

Dammit.

So I blew away all of the partitions and started another fresh install.  As punishment, AMIX gets 25M less disk space for root.  That will teach it not to mess with me!

After a few minutes of mkfs, the install finally started (22:24):

The internal drive is running substantially harder than under AmigaDOS, it seems.  I also see less activity on the external drive than I see on the internal one.  That’s probably because AMIX does proper buffering and caching.  It’s kind of funny to see the floppy light come on occasionally….I assume it’s when there’s a buffer flush or something.  Maybe updating atime…

Watching the files go by and about 23 minutes in I see a terminfo file for a trs80-100…are you freaking kidding me?  On the plus side, this is far more entertaining that the spinner that Solaris uses.

So both drives light up like crazy and the listing stops for quite some time.  Then the floppy heads move.  I’m starting to get nervous, and then things pick right back up.  This entry was being processed:

 9364 -rw-r--r-- 1 91 sys 5018735 Feb 12 1992 usr/src/X/contrib/clients/xv/docs/xvdocs.ps

(that first number is the cpio entry number…out of 28674.  That’s 5M…or 1.5% of the entire install.  Seems a little bit hefty for documentation!

I’m not going to repeat the Solaris-up-way-too-late fiasco.  It is 1/3 done (via file count) and it’s coming up on 45 minutes. That makes me feel better about the 28% number I got earlier when copying the cpio file to the partition.  Assuming that the files are distributed evenly, I’ve copied more than 30% of the content so I’m probably not truncated.

AMIX in the house?  Not yet.