This is an old revision of the document!
This will be a mess at first, it's a scribble pad for me at the moment as I work.
bash 3.0 on AMIX Compiles correctly after I fixed one source code file. AMIX uses deprecated trap designation in /etc/profile, so for CTRL-C to work you need to add a section like this to your /etc/profile:
if [ “$BASH” ] then trap - 2 3 fi
AMIX 2.1 Don't use tar. Use gtar. tar segfaults until you patch to level 2a (2.1c).
When configuring software for compilation you will have better luck specifying host/build/target as m68k-cbm-sysv4 than letting configure guess on its own (typically m68k-unknown-sysv4)
Edit /etc/inet/rc.inet to add default router, not /etc/defaultrouter (ignored by system)
Export CC=/usr/local/bin/gcc as some applications keep trying to use gcc-1.4.2 in /usr/public/bin during compilation
Mounting NFS shares from servers without NFS shares will panic the system. Oops! Don't Do That ™. Fixed in 2a patchlevel.
/usr/include/sys/socket.h, and types.h are too buggy to be used in many situations. Replace with files from 2a patchlevel.
Use sysadm to enable XDM, old method from 2.01/2.03 doesn't work anymore.
Don't install 2a patchdisk, HD hack install method leaves kernel uncompilable with patches. Copy the include files socket.h and types.h only.
Patches break w and netstat (at least) without kernel upgrade.
Adding swap: dd if=/dev/zero of=/tmp/swap bs=1024k count=50 && swap -a /tmp/swap 0 102400
Compilation will fail on large binaries even with 100MB or more of swap. An error like this will result: ld: cc1: libelf error: Memory error: output file space elf_update:. This is due to artificial restrictions imposed by ulimit. Set everything possible to “unlimited”, ie: ulimit -H unlimited, etc. Certain of these users cannot set, if you get this error you must become root and unset all limits. Type ulimit -? to see what you can fiddle with.
collect2.c in gcc-2.95.3 has a bug for AMIX, comment out the SYS_SIGLIST defs. Hope this is right, guessing here. (it compiled after) Damn, compiling gcc-2.95.3 is proving to be really educational in a “FOR CRYING OUT LOUD JUST COMPILE” kind of way. This link will be helpful diagnosing late stage1 compile problems: http://sources.redhat.com/ml/crossgcc/1997/msg00326.html … appears 126.96.36.199 is buggy, wonderful. It may be helpful to symlink /usr/X to /usr/X11 since /usr/X11 appears often on newer systems.
Bonnie_Amix2.1c_A3000D Overall, performance is…really poor. The NFS tests took a really long time. I won't have a good idea just how bad until I get the other tests completed, but I recall various quips and quotes from Usenet and reviews indicating disk performance being slow. There are patches to improve performance, but I think these are for 2.01/2.03. If it's possible to apply them to 2.1c I'll provide results for that as well. On to the results.
Bonnie testing parameters
Bonnie was run with a 100MB test set. For AMIX it was compiled with gcc-188.8.131.52, using CFLAGS=-O2 -m68020 -fomit-frame-pointer.
Key to X axis labels:
OChr: Output a character at a time as fast as possible. OBlk: Output intelligently as fast as possible. RW: “Rewrite test” - Read some data, change it, write it, and read it again, intelligently, as fast as possible. IChr: Read a character at a time as fast as possible. IBlk: Read intelligently as fast as possible.
Bonnie performance on disk
First there's the disk performance using the UFS filesystem. I'm not going to bother testing S5 as it has so many limitations. Plotted are the rates in KB/sec and the average CPU utilization during the test. Image
Bonnie performance on NFS
This was a test of NFS performance. The NFS server was an i686 Debian GNU/Linux 5.0 system with 100Mb NIC writing to a RAID 5. I assure you the bottleneck was not the Linux machine. Plotted are the rates in KB/sec and the average CPU utilization during the test. Image
Performance summary, disk and NFS
This compares the data rates for disk and NFS, and disregards the CPU utilization. Plotted are the rates in KB/sec and the average CPU utilization during the test. Image
I/O on Amix is relatively slow and uses relatively high amounts of CPU power to do the work. NFS is much slower. An advantage of NFS, though, is you can use RAID-backed storage at the other end. There is no such option for disk-based storage on AMIX.
Results for NFS were much tighter across 4 runs than the disk data. The first disk test for IBlk was a bit of an aberration, using far less CPU and having less speed. Probably another process was kicked off by the system during this test and multitasking caused Bonnie to get less CPU time.
This collection of pages is intended to provide some insight as to how Amiga UNIX performs relative to other OSs. Information I would not mind seeing here includes:
Performance of a different OS on the same hardware Performance of newer/better hardware vs “AMIX level” hardware Methodologies to increase Amiga UNIX performance
So, yes, fairly dull. The way I would like to see this laid out is a seperate page for each set of tests. This way, people can easily open results up in a new window (or tabs) for comparison. If you would like to submit your own results, first take a look at the list of tests you should run. You do not have to run all of these, but you should run as many as you can. Next, take a look at my test results and try to get your report to look similar.
The tests are tailored for UNIX systems, but if you can get them to run in AmigaOS (and most of them are sufficiently basic that this should not be an issue) more power to you.
Click here to see the list of tests
Results are split into two categories: AMIX-capable hardware, which by its nature should keep the machines to roughly the same spec; and other hardware, which must be classic Amiga hardware but does not need to be able to run AMIX.
AMIX-capable hardware Amiga UNIX 2.1c on A3000D, run by failure