fl@tools.uucp (Frank Lancaster) (05/31/91)
Our R260 runs at 26Mhz. RiscIX does 16000-19500 Dhrystones depending
on screen mode. RISC OS about the same. My old A440 with 30Mhz ARM3
did 17800 Dhrystones in Mode 0. Mode 21 is much faster on the R260
(nearly the same as Mode 20), you can actually use it in RiscIX.
Compared with a SPARC SLC (costs something around 10000-12000 DM in Germany),
the Dhrystones are about the same. But programmes like TeX and METAFONT
run at least twice as fast on the SLC! I think this is mainly due to
the small cache size on the ARM3. The SLC also has a FPU, but it isn't
that fast (a Sparc Station 2 does about 7-8 MFLOPS, a SLC 1-2).
A few points concerning the R260 as a UNIX workstation:
1. I don't like preinstalled UNIX systems on hard disc with NO backup
supplied. What are you supposed to do if you accidently remove the
kernel!? I quickly copied the kernel to floppy disc, and tested booting
from floppy disc. That works, but you still have to specify where your
swap space is and it has to be on a hard disc (at least I didn't find
out if you could specify a floppy disc as swap space).
2. Next I wanted to reconfigure the hard disc with a larger RISC OS section,
as we develope both UNIX and RISC OS software. Hmm, a programme is supplied
to do this, but of course it destroys all data on your hard disc! So you
either need a second hard disc (we didn't have a spare one) or you have
to boot discless without hard disc.
3. Booting without hard disc via ethernet. Well, this wasn't easy.
The R260 isn't supplied with all software required for a discless boot.
But using the *boot command with the undocumented parameter et0(0,0) as
root device revealed that after loading the kernel from floppy disc
the systems tries to boot over ethernet. Well, we configured one of our
SPARC Stations as server and installed all the RISCIX files on it, set up
a swap partition on the SPARC, and rebooted the R260. It worked!
You still have to load the kernel from floppy disc but now you can
reconfigure your hard disc and reinstall the RISCIX system (backed-up on a
remote tape device, you go bananas when backing up to floppy disc)
4. Next I wanted to reconfigure the kernel. On SUN systems you can relink
the kernel after changing and compiling the parameter files, so you
can remove unused device drivers etc. On the R260, as supplied, you can't
relink the kernel. Well, we love adb (the standard UNIX debugger) and
started patching the kernel (more file buffers, yummy!) This is all
undocumented, the contents of the (available at extra cost) programmers
reference manuals aren't even listed anywhere ("Man muss die Katze
im Sack kaufen").
5. On RISC OS I use a module to improve the screen modes on my multisync
monitor (less flicker, larger picture). Alas, reconfiguring the screen
modes is again undocumented. But debugging the kernel is fun, and we
discovered a variable called video_mode which points to the VIDC paramter
table for the current screen mode. The rest is easy, calculate the
parameters for the VIDC, patch the VIDC tables, and reboot! Now I don't
have to twiddle the position controls on my multisync anymore when
switching screen modes and the picture doesn't flicker as much as it used
to.
6. I hope that Acorn will supply the OpenLook GUI with their next UNIX release,
as Motif is quite horrible and the twm window manager is also configured
most horrible (green borders, half wide title bars!) We've started porting
the XView OpenLook package. The OpenLook window manager works with slight
problems, but looks quite nice in colour. The filemgr programme looks far
better than the IXI desktop.
After all this criticism, you may think that I hate this machine. But no, I
actually quite like it. Its the fastest Archimedes around with the best
operating system on it. Only it could be a lot better...
Switching between RISCIX and RISC OS doesn't take long, booting UNIX
without disc checks takes about 1min. GNU emacs is supplied, but not the
newest version. Networking with SUNs works without any problem, overall
performance of UNIX is quite okay, not much swapping and disc access is fast.
Well, this was intended as only a short message about processing speed, but
I hope my experiences were of some interest.
Frank Lancastermark@acorn.co.uk (Mark Taunton) (06/03/91)
In article <FL.91May31100419@pierre.tools.uucp> fl@tools.uucp (Frank Lancaster) writes:
:Our R260 runs at 26Mhz. RiscIX does 16000-19500 Dhrystones depending
:on screen mode. RISC OS about the same. My old A440 with 30Mhz ARM3
:did 17800 Dhrystones in Mode 0.
Yes, although the R260 is faster in general (because the memory bus is
clocked at 12MHz, vs 8MHz on A4xx/R140), Dhrystone all ends up in the
cache so the execution time is directly related to the ARM3's fast
clock rate. BTW, I get better figures on the R260 I use. Which
Dhrystone (1 or 2) is being used?
:A few points concerning the R260 as a UNIX workstation:
:
: 1. I don't like preinstalled UNIX systems on hard disc with NO backup
: supplied. What are you supposed to do if you accidently remove the
: kernel!?
The problem with any other distribution scheme is that it costs more
(=> increased system price) and besides, there are several different
media & formats which people might want to use - we can't support them
all.
It is just not sensible to try to run a UNIX box without *some* form
of backup (even if it is just a large box of floppies) so I really
don't see the problem. You are certainly expected to back the system
up: it's clearly explained in the System Administrator's Guide. Even
so, in the case of the unlikely event you speak of, your supplier
and/or the support service should be able to assist - it's what
they're there for.
: .. I didn't find
: out if you could specify a floppy disc as swap space
You can't: there really isn't enough space on a floppy for the
purpose. Besides, what do you do if the system wants to write to the
swap floppy when you have the file system floppy in the drive? Yes,
doing a RISC OS style floppy disc naming scheme is *possible* but it
doesn't make economic sense for us to put such effort in given the
rarity with which such a thing is needed.
: 2. Next I wanted to reconfigure the hard disc with a larger RISC OS section,
: as we develope both UNIX and RISC OS software. Hmm, a programme is supplied
: to do this, but of course it destroys all data on your hard disc! So you
: either need a second hard disc (we didn't have a spare one) or you have
: to boot discless without hard disc.
Sorry, that's just a fact of life: if you increase the size of the
RISC OS section you will need to reduce the size of the main RISC iX
file system partition. That cannot be done on an existing file system
(and certainly not with the file system mounted), so you need to back
up, do the modification with running from a different root device,
then reload.
: 3. Booting without hard disc via ethernet. Well, this wasn't easy.
: The R260 isn't supplied with all software required for a discless boot.
Indeed. The standard distribution is designed for discfull use, since
the R260 comes with a hard disc. We also sell the R225 discless
workstation, for networked operation, and suitable software is
supplied with that. Crude analogy: if I want an open top car, I don't
expect the manufacturer to supply me with tools and detailed
instructions on removing the lid of my saloon :-)
: [ explains how discless booting can be done ]
: ... It worked!
Congratulations! For people who really do want to run discless, it is
probably better to buy an R225 and upgrade it if required.
: 4. Next I wanted to reconfigure the kernel. On SUN systems you can relink
: the kernel after changing and compiling the parameter files, so you
: can remove unused device drivers etc. On the R260, as supplied, you can't
: relink the kernel. Well, we love adb (the standard UNIX debugger) and
: started patching the kernel (more file buffers, yummy!)
With the RISC iX 1.2 kernel there is little need to remove unused
device drivers: the system automatically reuses most of the memory
they take up. I strongly advise against attempting reconfiguration
patches without documentation: do you *really* know what you are
doing?
In any case, a Kernel Binary Kit is available: it provides all that is
needed to reconfigure the kernel for specific requirements, *and*
explains the limitations on parameters - contact your supplier.
: 5. On RISC OS I use a module to improve the screen modes on my multisync
: monitor (less flicker, larger picture). Alas, reconfiguring the screen
: modes is again undocumented. But debugging the kernel is fun, and we
: discovered a variable called video_mode which points to the VIDC paramter
: table for the current screen mode. The rest is easy, calculate the
: parameters for the VIDC, patch the VIDC tables, and reboot!
AAAAAaaaaaarrrrrgggggggghhhhhh!!!!!!!! Debugging the kernel may be
fun, but we really can't support you if you pull stunts like that!
Reconfiguring the screen modes is undocumented because it's not
something we intend anyone to do. What if your patch goes wrong (or
you don't fully understand what you are modifying), and the kernel
then malfunctions in such a way as to corrupt your filesystem?
:After all this criticism, you may think that I hate this machine. But no, I
:actually quite like it. Its the fastest Archimedes around with the best
:operating system on it. Only it could be a lot better...
:Switching between RISCIX and RISC OS doesn't take long, booting UNIX
:without disc checks takes about 1min. GNU emacs is supplied, but not the
:newest version. Networking with SUNs works without any problem, overall
:performance of UNIX is quite okay, not much swapping and disc access is fast.
Thank you for your comments. Glad you like it.
I hope this wasn't too boring for the many readers not using RISC iX....
--
Mark Taunton Email: mark@acorn.co.uk
Acorn Computers Ltd Phone: (+44) 223 214411
Cambridge, UK Fax: (+44) 223 214382fl@tools.uucp (Frank Lancaster) (06/09/91)
mark@acorn.co.uk (Mark Taunton) writes: > clock rate. BTW, I get better figures on the R260 I use. Which > Dhrystone (1 or 2) is being used? Dhrystone 1.1 > The problem with any other distribution scheme is that it costs more > (=> increased system price) and besides, there are several different > media & formats which people might want to use - we can't support them > all. > Indeed. The standard distribution is designed for discfull use, since > the R260 comes with a hard disc. We also sell the R225 discless > workstation, for networked operation, and suitable software is > supplied with that. Crude analogy: if I want an open top car, I don't > expect the manufacturer to supply me with tools and detailed > instructions on removing the lid of my saloon :-) > With the RISC iX 1.2 kernel there is little need to remove unused > device drivers: the system automatically reuses most of the memory > they take up. I strongly advise against attempting reconfiguration > patches without documentation: do you *really* know what you are > doing? > In any case, a Kernel Binary Kit is available: it provides all that is > needed to reconfigure the kernel for specific requirements, *and* > explains the limitations on parameters - contact your supplier. This actually all refers to my main point. When entering the UNIX market Acorn will have to allow itself to be compared with the leading UNIX workstation distributors (mainly SUN). SUN provides it UNIX software nearly complete. Why distribute a kernel link kit at extra cost? Why supply discless booting software only with discless workstations? There are enough reasons why one could want to boot a workstation that has a disc discless. In the latest price list I have seen that Acorn supplies this again at extra cost! Why supply the programming documentation at extra cost? This is something I could just barely accept with RISC OS as it is mainly targetted at users not at programmers. But in the UNIX world you will not get far with that attitude. > AAAAAaaaaaarrrrrgggggggghhhhhh!!!!!!!! Debugging the kernel may be > fun, but we really can't support you if you pull stunts like that! > Reconfiguring the screen modes is undocumented because it's not > something we intend anyone to do. What if your patch goes wrong (or > you don't fully understand what you are modifying), and the kernel > then malfunctions in such a way as to corrupt your filesystem? Hmmm. I actually think that I know very well what I'm doing. We have a lot of experience with UNIX systems (at least 6 years) and I have enough experience with the VIDC hardware. Acorn may not think so, but reconfiguring the screen modes to give a better picture on a multisync monitor improves the overall evaluation of the R260 a lot. 50Hz monitor modes which cover nearly only half of the screen don't give the machine good PR. Anyway I wasn't trying to change the resolution of the screen modes only their appearance (but changing the actual resolution should also be possible, why use the VIDC hardware in this limited way? RISC OS is actually better designed to cope with the Acrhimedes hardware). I still think that Acorn should make the most out of their hardware. Concentrating on the Britsh market and end-users will lead to stagnating sales in about a years time and nobody in Germany will see the R260 as a serious competitor to the _REAL_ UNIX workstations. Frank Lancaster --------------------------------------------------------- Against the run of the mill, static as it seems We break the surface tension with our wild kinetic dreams, Shapes and lines, of grand designs... -- RUSH
Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) (06/10/91)
I hope Acorn take note of the comments people are making about the R260/UNIX and improve the situation rather than try to defend it. I have seen an R260 demonstrated at Victoria University (New Zealand). I was impressed about how fast it redisplayed under X-windows, but... The supplied software, and documentation, not to mention the monitor, could be improved somwhat. I was expecting better. I would like to see Acorn machines being used here, well maybe next time. -Gavin. -- The main "user" of well brought up, and educated, children is the community at large. So if you really believe in "user pays", charge the correct users - stop overloading parents with financial penalties. ******* These comments have no known correlation with dept. policy! *******