Hi,

some days ago I compiled lmbench for RiscBSD and got the following results.
I added some other computers for comparison: 

                    L M B E N C H  1 . 0   S U M M A R Y
                    ------------------------------------

            Processor, Processes - times in microseconds
            --------------------------------------------
Host                 OS  Mhz    Null    Null  Simple /bin/sh Mmap 2-proc 8-proc
                             Syscall Process Process Process  lat  ctxsw  ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
Strongarm   NetBSD 1.2D  215       5     38K     59K    279K 1763    855   1276
Arm610/33   NetBSD 1.2D   31      80     25K     38K    166K  843    251    390
i586      FreeBSD 2.1-S  100       7      3K     13K     21K  173     29     35
i586       Linux 1.2.13  100       3      3K     24K     73K   84     66     83
pa-risc   HP-UX A.09.01   98      13      3K     10K     20K   97     29     30
sgi         IRIX5.3 5.3  198      11      3K      8K     19K  260     40     38
alpha         OSF1 V3.2  189      15      5K     15K     89K  261     40     46

            *Local* Communication latencies in microseconds
            -----------------------------------------------
Host                 OS  Pipe       UDP    RPC/     TCP    RPC/
                                            UDP             TCP
--------- ------------- ------- ------- ------- ------- -------
Strongarm   NetBSD 1.2D    1839   13888   15810   13986   14424
Arm610/33   NetBSD 1.2D    1669   14104   17791   14783   15887
i586      FreeBSD 2.1-S     115     249     408     297     510
i586       Linux 1.2.13     140      -1     806      -1    1249
pa-risc   HP-UX A.09.01     169     248     759     257     805
sgi         IRIX5.3 5.3     131     313     671     278     641
alpha         OSF1 V3.2     198     709    1109     629     994

            *Local* Communication bandwidths in megabytes/second
            ----------------------------------------------------
Host                 OS Pipe  TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                                  reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
Strongarm   NetBSD 1.2D    2    3      1      4     16      2   36    23
Arm610/33   NetBSD 1.2D    2    1      1      5     10      0   13    23
i586      FreeBSD 2.1-S   18    0     29     50     41     38   65    83
i586       Linux 1.2.13   12    3     13      8     21     20   60    31
pa-risc   HP-UX A.09.01   44   20     44     33     26     32   53    49
sgi         IRIX5.3 5.3   34   22     32     44     32     31   69    66
alpha         OSF1 V3.2   23    7     37     12     38     38   64    79

	    Memory latencies in nanoseconds
            (WARNING - may not be correct, check graphs)
            --------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------   ---  ----   ----    --------    -------
Strongarm   NetBSD 1.2D   214     5    720         740    No L2 cache?
Arm610/33   NetBSD 1.2D    31    61    551         548    No L2 cache?
i586      FreeBSD 2.1-S    99    10    101         180
i586       Linux 1.2.13    99    10    222         321
pa-risc   HP-UX A.09.01    98    10     10         348    No L1 cache?
sgi         IRIX5.3 5.3   197    10     76        1018
alpha         OSF1 V3.2   188    10     53         477


You can see that memory access is not too fast, but this is because of
the lame rpc main board.

It is much worse that context switching, communication latencies and
bandwiths are very bad compared with other systems. Sometimes the Arm610
is faster than the Strongarm, I guess this is because of cache flushing
or even switching off on Strongarm.

But also the Arm610 is not too fast, it is even very slow, and there is
not always the cache flushed or switched off. So my question is: is this
because RiscBSD is not very optimized (so this could become better some
day) or is it because of some other reason?


Peter Teichmann