Subject: Linux-Development Digest #290
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Tue, 11 Oct 94 13:13:14 EDT

Linux-Development Digest #290, Volume #2         Tue, 11 Oct 94 13:13:14 EDT

Contents:
  Re: Telnet & ftp freeze! (John Richardson)
  Re: Improving SLIP latency under Linux (Rob Janssen)
  replacements for dos _bios_keyboard calls (Paul Erkkila)
  Re: Could TCP/IP be implemented over SCSI? (Martin Blaschke)
  Re: DOSEMU Questions (386 mode?) (Charles E Meier)
  Re: Linux For Mac (Aaron 'Raz' Wrasman)
  Re: Practical experience with Gravis Ultrasound Max? (Patrick D. Ashmore)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Jeff Kuehn)
  [Q] what is the story with linux.act.* newsgroups (Tim Bass (Network Systems Engineer))
  Re: ext2fs vs. Berkeley FFS (Michael Bischoff)
  /proc/mtab 0.2 for 1.1.52 (Davor Jadrijevic)
  Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Jeff Kuehn)

----------------------------------------------------------------------------

From: [email-masked] (John Richardson)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Telnet & ftp freeze!
Date: 9 Oct 1994 01:05:30 GMT

>
>Right, but introducing a 3000ms latency in the PPP session is not
>really acceptable.
>

Unfortuantely, I think the problem lies elsewhere if you have my 
patch. :(

--
John Richardson

------------------------------

From: [email-masked] (Rob Janssen)
Subject: Re: Improving SLIP latency under Linux
Reply-To: [email-masked]
Date: Sun, 9 Oct 1994 08:55:00 GMT

In <[email-masked]> [email-masked] (Al Longyear) writes:

>If you are the only person using the link and you don't want the
>telnet session to be degraded by ftp, then don't start the ftp
>transfer. (Simple, isn't it?) If you are not the only user then you
>don't have this option. However, consider that the person doing the
>ftp transfer wants the data transferred as fast as possible as
>well. You must consider all of the users, not just one.

It is not like that...
A real example of SLIP line use: I use SLIP links over 14k4 and 28k8 modems
to remotly support networks.  A Linux machine is on the client's network
and has a dialin modem, and from a central site we dial these modems and
can do all kinds of work (telnet, SNMP, remotely running dosemu which accesses
Netware, etc)
Often I want to transfer some upgrade using FTP, and at the same time look
around with telnet.  So I am the person that wants both activities and would
really like the telnet to behave reasonable while the FTP continues in the
background using the remainder of the bandwidth.

>The best solution is to simply choose the priority when you do the
>transmission and then send it in that order.

That only helps when there are as little buffers as possible between the
point where this decision is made and the line.
Although the buffers in the modems are a problem, I don't think they are
the full explanation of 6 second roundtriptimes when an FTP is running.
Probably some frames get queued up in the kernel "waiting to be sent on
the serial line".  That is not good...
I will try to install the new networking stuff that promises to solve
this situation (the systems are now running plain slackware), but it only
helps when the FTP is initiated from a Linux machine.  It not always is.
Peeking in the TCP headers inside the IP routing code (checking for port
numbers, so that 20 and 25 can get a lower priority than 23 even when the
TOS is the same) seems to be the best solution...  (although dirty)

>>How about setting the MTU based on the anticipated amount of interactive
>>traffic, and adjusting it based on the actual amount?  Or is the MTU set 
>>once for a session?

>The maximum value is set once for the session. You could reduce it,
>but increasing it is definitely not a good idea.

The MTU should probably not be changed, but of course TCP can be asked
to send fewer and smaller segments in those cases where the link has problems.
In fact I think the "always use a big window because that performs so
nicely on fast links" may be not optimal.  One could argue that the optimum
window size for a TCP is such that it can just keep sending (i.e. an
ACK comes back just when the sending TCP runs out of send window), and
not much larger than that.  The sending TCP could adapt its send window
accordingly (staying below the negotiated window size).

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: [email-masked] (Paul Erkkila)
Subject: replacements for dos _bios_keyboard calls
Date: Tue, 11 Oct 1994 11:59:12 GMT

        I need a replacement for the MS/Zortech/Borland Dos _bios_keyboard
functions to do a port of some dos code. The two functions that I need 
explicitly are:

_bios_keyboard(KEY_READY) : which returns true if there are any more keystrokes
to process. (chars in the keyboard buffer)

and 

_bios_keyboard(READ) : which does a bios keyboard read.

   I fooled around with ncurses nocrmode; getch; crmode; But it gives me a
SIGSEGV everytime I try it with these calls (do I need to set up a curses
window for these?  I'd rather not..)

I am writing in g++ using the iostreams stuff, so if there are functional 
equivalents to these with cin i'd be a happy camper.

Thanks in advance

-pee

-- 

------------------------------

From: [email-masked] (Martin Blaschke)
Subject: Re: Could TCP/IP be implemented over SCSI?
Date: Fri, 07 Oct 1994 16:57:52 GMT
Reply-To: [email-masked]

In article <ianm.780773861@miles>, Ian McCloghrie writes:

> Ummm... it's certainly be possible.  But make sense?  Last I checked,
> fast/wide scsi 2 cards weren't exactly cheap.  Granted, it's faster
> than ethernet, but how many people really, seriously, need more
> than 10Mbits on their LAN?  Especially at home (the main Linux
> presence).  The cabling for it would be a nightmare (25 pairs, not
> just 2 as in 10baseT, *and* you have to worry about termination).
> 
It is not a question of what you need or what a scsi-controller would could!
This "network-solution" would be for those who ALREADY HAVE these controllers
in their PCs,... And it would be very nice to use them for cheap and fast
networking (nearly as cheap as slip via nullmodem).

> It's a cool idea, and perhaps useful in a Desk-Area-Network concept
> (put an xterminal on your system via scsi and use that as your main
> display, etc).  But it's not well suited as a general LAN technology.

Nobody is talking of GENERAL! Just for cheap and effective fun-networking...
:-))))))

> 
> --
> Ian McCloghrie    work: [email-masked]     home: [email-masked]
> 

--
Martin Blaschke

 -------------------------------------------------------------------
 >             E-Mail:   [email-masked]                 <
 -------------------------------------------------------------------

------------------------------

From: [email-masked] (Charles E Meier)
Subject: Re: DOSEMU Questions (386 mode?)
Date: 9 Oct 1994 14:01:12 GMT

In article <[email-masked]>, Rob Janssen <[email-masked]> wrote:
>In <[email-masked]> [email-masked] (Douglas Rankin) writes:
>
>> I know this is probably a dumb question. does dosemu emulate 386 protected
>>mode? If not are there plans to do so?? The reason I am wondering is that
>>I have several dos programs that use Phar Lap dos extender and it won't
>>run becasue it say the chip is in 8086 mode. Is there a way to have it run
>>in 385 mode so I can run thse programs, If so how, any help would
>>be apprecited!! Thanks
>
>It doesn't, and I don't think it will do it any time soon.
>
>However, most dos extenders (I don't know Phar Lap) are also willing to
>live with one of the protected mode interfaces, like DPMI.  This is
>currently being worked on in dosemu.

Phar Lap helped design/develop the DPMI standard.  In fact, when I wanted a 
copy of the DPMI standards docs, I called Phar Lap and they sent them fer free.
Nice folks there.

cem

------------------------------

From: [email-masked] (Aaron 'Raz' Wrasman)
Subject: Re: Linux For Mac
Date: 11 Oct 1994 13:38:08 GMT

In article <[email-masked]> [email-masked] (Alan Braggins) writes:

>    In article <[email-masked]>,
>    Aaron 'Raz' Wrasman <[email-masked]> wrote:
>    >Actually could I get some info on Linux for the Mac also? 
>    Whats to tell?  The Linux FAQ lists no 68k mac ports, 
> 
> Amiga and Atari posrts exist though.
> --
> Alan Braggins  [email-masked]  [email-masked]
> "Any technology distinguishable from magic is insufficiently advanced"
> 

But the FAQ is wrong, someone already mentioned that someone was
porting it. THeir names were mentioned even. I think they were having
problems with I/O because it was hard to get documentation on it. I'll
try to go back and grab the message that said their names. I forgot to
grab it.

Raz

--
  @             Internet:[email-masked], [email-masked] 
 (!=>---        Bitnet:Razron@utkvx, Kaspian@utkvx  Phone# 615-584-8240
 / ) Raz        Usnail:602B Longview Rd Knoxville,TN 37919       

------------------------------

From: [email-masked] (Patrick D. Ashmore)
Subject: Re: Practical experience with Gravis Ultrasound Max?
Date: 10 Oct 1994 09:40:02 GMT

Jon Lasser ([email-masked]) wrote:
: Does anyone have practical experience with the Gravis Ultrasound Max
: under Linux?

I'm currently running Linux 1.1.52 with a Gravis Ultrasound MAX, and it 
works great. 

: I have three primary questions:
: (1) Does the CD-ROM interface for the Panasonic drive work
: properly under Linux (I have a Panasonic 563b drive, which currently
: runs with my Sound Blaster 16).

I have a Mitsumi 2X, which is also a supported drive for the GUS MAX 
interface. It works great under Linux and even the Mitsumi's own DOS 
driver ran fine with the GUS MAX. 

: (2) Are there any general incompatibilities between the board
: and Linux? Any specific known problems?

As of 1.1.35 or so, the MAX was included in Hannu's voxware sound driver 
in the kernel. The first few versions had problems (FTPs would hang while 
I listened to sounds or mods, and then resume once the music stopped). 
But that was quickly fixed, and now I sit back and enjoy music from 
Purple Motion, Skaven, and CC Catch while I hack away. :^)

: (3) I'm currently using a Sound Blaster 16. IsGravis
: Ultrasound Max considered an upgrade from the Sound Blaster? I mean, I
: know that the digital audio is about the same, but is the WaveTable that
: much better?

Well, I'm biased... I had a SB Pro, but after I played with a friend's 
GUS I decided that was for me and went ahead and got the GUS MAX. I don't 
know the specifics on the SB 16, but the fact that the GUS/GUS MAX have 
on-board memory makes it great for a multitasking OS like Linux.

: Frankly, I'm lusting over the board, but I want to make sure that it
: works before I buy it, because I don't know enough to hack the kernel.
: (yet).

I consider it a great investment myself. 

Patrick

--
Patrick D. Ashmore          Network Administrator         1322 W. Cleveland
[email-masked]              Procyon  Networking       Fayetteville,  AR 72701
Finger for PGP key      URL: http://procyon.com/~pda/      +1 501 443 4393
[email-masked]                 [email-masked]            publius  enigma

------------------------------

From: [email-masked] (Jeff Kuehn)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 11 Oct 1994 14:53:42 GMT

Rob Janssen ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Jeff Kuehn) writes:

: >In his last kernel patch announcement, Linus requested information on
: >performance of the recent kernels.  I took it upon myself to gather a few
: >hard numbers in as much as this is possible.  (Lies, Damned Lies, and
: >Benchmarks!) While I consider myself far too skeptical to call Byte
: >Magazine's UNIX Benchmark a "good" benchmark, it seemed like a reasonable
: >place to start for several reasons.

: I have noticed ever since 0.98pl4 that I started with, that performance
: has been dropping.  The only exception is the disk performance, which
: increased because of the clustering.

: In the early days, starting something in X windows was snappy.  Now I
: get a noticable delay.  I still have a copy of Byte-3.1 results of
: 0.98pl4 and indeed it shows a decrease since then.  At that time, my
: system yielded 3.0 and on 1.1.33 it had 2.3
: (not as much decrease as it seems to be.  however, I should also note
: that my fist reaction when running Linux was "boy this is fast", as my
: only frame of reference at that time was SCO XENIX and SCO UNIX running
: on comparable hardware.  over time, one gets used to the speed and wonders
: how it could ever be experienced as "fast" :-)

True.  Linux looks *damn* good compared to most everything else out there
in most regards with two areas excepted:  the scheduler and the system call
overhead.  The reason I chose 1.1.0 as the baseline for these benchmark
numbers was to emphasize how performance of linux has changed over several
releases...  The original baseline was a VAX 11/780, which as you point out,
a decent 486 will beat by a factor of 2.5 or 3.0.

Again, it should be noted that because the filesystem tests ran out of
cache,  they are more indicative of ext2fs/cache performance than the 
device driver performance.

The big question is:  Can we reclaim the losses?

--Jeff Kuehn, NCAR/SCD

------------------------------

From: [email-masked] (Tim Bass (Network Systems Engineer))
Subject: [Q] what is the story with linux.act.* newsgroups
Date: 11 Oct 1994 13:34:44 GMT

Twice, I posted some relevant information to the linux.act.* groups.
The lastest post was directly related to the linux.act.net group, where
I posted the bug fix for lmail.c in the sendmail distribution.  

None of my posts ever made it to the 'big net in the sky'.  As a very
active linux person, I'm getting a sinking feeling about the way
the linux.act.* groups are being moderated or managed.  Before I
react, can somewhat send me some info on these groups?  Do I need
a club membership card to get in the clubhouse?

------------------------------

From: [email-masked] (Michael Bischoff)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 10 Oct 1994 09:30:37 GMT
Reply-To: [email-masked]

In article <[email-masked]> [email-masked] (Albert D. Cahalan) writes:
   I think 3 or 4 bits could be spared for extended attributes like this:

   0  flat file (default)
   1  NEW record file
   2  Mac file
   3  NT file
   4  OS/2 file
   5  DOS executable
   6  Windows executable
   7  etc.
Hi,
this would be against the philosophy of UNIX: less is more!
The success and flexibility of UNIX is due to the fact that
all I/O is done through files: ordinary files, hard disks, printers
are all accessable through the same open() and write() calls.
The mess of DOS is that you need special programs if you want
to read A: as entire image.

          Michael
--
EOI
============================================================================
Michael Bischoff                e-mail: [email-masked]
Abt. Mathematische Optimierung    or    [email-masked]
Inst. Angewandte Mathematik       or    [email-masked]
Pockelsstrasse 14               Tel. +49-531-391-7555, Fax: +49-531-391-4577
38106 Braunschweig              Germany

------------------------------

From: [email-masked] (Davor Jadrijevic)
Subject: /proc/mtab 0.2 for 1.1.52
Date: 9 Oct 1994 14:10:39 GMT

HI

This is a up-to-date /proc/mtab release for kernel 1.1.52 with a minor
bug fix and more cleanup. I didn't have tested if it would
compile with every kernel config, so please inform me or better
send patches.

the stuff is uploaded at sunsite under the name procfs-0.2-1.1.52.tgz

d.
--
<[email-masked]>, <[email-masked]>
================ Davor Jadrijevic ====================

------------------------------

From: [email-masked] (Jeff Kuehn)
Subject: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 10 Oct 1994 20:35:00 GMT

Hi All!

In his last kernel patch announcement, Linus requested information on
performance of the recent kernels.  I took it upon myself to gather a few
hard numbers in as much as this is possible.  (Lies, Damned Lies, and
Benchmarks!) While I consider myself far too skeptical to call Byte
Magazine's UNIX Benchmark a "good" benchmark, it seemed like a reasonable
place to start for several reasons.

        1. it contains tests which are intended to measure the performance
           of several critical operating system services (although you're
           welcome to dabate this with the folks at Byte Magazine -- not
           me).

        2. it is widely used to compare performance of small UNIX systems
           and should a magazine such as Byte ever choose to do a
           comprehensive review of Linux we can expect that it will
           include such a benchmark.

        3. the benchmark contains several convenient awk scripts for post
           processing the timings.  Which allowed me to select a single
           patch level as my "base", and report all the number as a ratio
           to that base performance.

The results aren't particularly good.  Version 1.1pl0 returned the best
overall performance of all the patch levels, so I used it as the base
against which I did all of the comparisions.  The current patch level
(1.1.52) was second to worst of all those I tested, having slipped by over
10% off the best value.  For grins, I also ran the same thing on the
SPARCstation I have at work for comparison...

This pointed out a problem endemic to all of the patch levels I tested
(1.0.9 to 1.1.52).  Specifically, my Linux box (486dx2/66-256Kb cache,
16MB ram, AHA1742scsi, ext2 filesystems) was consisently faster than the
SPARCstation in every area except one:  Concurrent users (simulated by
running multiple concurrent shell scripts.  On SunOS, doubling the number
of concurrent scripts, halved the number of loop iterations which could
complete within the given period of time.  For Linux on the other hand,
running one user allowed about 80 iterations to occur within the time
limit, whereas when running two users, Linux could not complete a single
iteration.  Note the SunOS line in the table below... for SunOS Sh1 == 0.2
and Sh2 == 11.3, this is not an indicator of how good SunOS is, but rather
how weak Linux is in this area.  As several have mentioned previously,
this is probably the fault of the process table handling and scheduling
algorithms.  This needs to be fixed BADLY.

Also worthy of note are the following:

        1.  Process creation performance has dropped 30%.

        2.  System call overhead has doubled.

        3.  Filesystem read and write performance has dropped between
            20%-40%.  Note that since the I/O benchmarks ran almost
            entirely in cache,  I consider this to reflect performance of
            the ext2 filesystem/buffer cache more than the lower level
            device drivers, Which (Eric's?) benchmarks have shown to have
            improved significantly.

        4.  Pipe overhead performance has dropped 50%.

        5.  Execl is faster in 1.0.9

        6.  And of course, the scheduler sucks mud.

and on the brighter side:
        
        7.  File copy performance is up over 1.1.0 having reached a peak
            during 1.1.10-1.1.40 and dropped off again after that.

        8.  Scheduling of single users has improved over 1.1.0, having
            reached a peak somewhere around 1.1.40

        9.  While the size of the kernel source has ballooned over the
            last several months, I'm happy to report that the size of a
            kernel has changed very little over that period.  I think this
            reflects all of the new drivers rather than a bloating of
            existing drivers.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The headers in the table below refer to the various tests in the Byte
Magazine UNIX Benchmark as follows.

Versn   linux kernel version            Ari     Arithmetic Test (type=double)
Dry     Dhrystone 2 w/o register vars   Exc     Execl Throughput Test
FC1     File Copy  (10 seconds)         FC3     File Copy  (30 seconds)
FR1     File Read  (10 seconds)         FR3     File Read  (30 seconds)
FW1     File Write (10 seconds)         FW3     File Write (30 seconds)
Pip     Pipe-based Context Switch Test  PCT     Process Creation Test
Sh1     Shell scripts (1 concurrent)    Sh2     Shell scripts (2 concurrent)
Sh4     Shell scripts (4 concurrent)    Sh8     Shell scripts (8 concurrent)
Sys     System Call Overhead Test       SUM     Sum of all of the previous

The numbers in the table, represent the ratio of test(pl)/test(1.1.0),
Bigger numbers indicate better performance.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Versn |Ari|Dry|Exc|FC1|FC3|FR1|FR3|FW1|FW3|Pip|PCT|Sh1| Sh2|Sh4|Sh8|Sys|SUM
1.0.09|1. |1. |1.1| .9|1. |1. |1. | .9|1. | .5| .7|1. | 1. |1. |1. | .5|14.6
1.1.00|1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. | 1. |1. |1. |1. |16. 
1.1.01|1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. | 1. |1. |1. |1. |15.9
1.1.02|1. |1. |1. | .9|1. |1. |1. |1. |1. | .6| .7|1. | 1. |1. |1. | .5|14.7
1.1.03|1. |1. |1. | .8|1. |1. |1. | .6| .9| .6| .7|1. | 1. |1. |1. | .5|14. 
1.1.04|1. |1. | .9| .8|1. |1. |1. | .6| .9| .9|1. | .9| 1. |1. |1. |1. |15.1
1.1.05|1. |1. | .9| .8|1. |1. |1. | .6| .9| .8|1. |1. | 1. |1. |1. |1. |15.1
1.1.10|1. |1. | .9|1.1|1.3|1. |1. | .6| .9| .9|1. |1. | 1. |1. |1. |1. |15.6
1.1.15|1. |1. | .9|1.1|1.3|1. |1. | .6| .9| .9|1. |1. | 1. |1. |1. |1. |15.6
1.1.20|1. |1. | .9|1.1|1.3| .8| .9| .6| .8| .8|1. |1. | 1. |1. |1. |1. |15.1
1.1.25|1. |1. | .9|1.1|1.3| .9| .9| .6| .9| .9|1. |1. | 1. |1. |1. |1. |15.4
1.1.30|1. |1. | .9|1.1|1.3| .9| .9| .6| .9| .7|1. |1. | 1. |1. |1. |1. |15.3
1.1.35|1. |1. | .9|1.1|1.3| .9| .9| .6| .9| .9|1. |1. | 1. |1. |1. |1. |15.4
1.1.40|1. |1. |1. |1.1|1.3| .8| .8| .6| .8| .7|1. |1.2| 1. |1. |1. | .9|15.1
1.1.45|1. |1. |1. |1.1|1.3| .9| .9| .6| .9| .8|1. |1.1| 1. |1. |1. |1. |15.4
1.1.50|1. |1. |1. |1.1|1.2| .8| .9| .6| .9| .7|1. |1.1| 1. |1. |1. | .9|15.3
1.1.51|1. |1. |1. |1.1|1.2| .8| .8| .6| .9| .7|1. |1.1| 1. |1. |1. | .9|15.2
1.1.52|1. |1. |1. |1.1|1.2| .8| .8| .6| .8| .5| .7|1.1| 1. |1. |1. | .5|14.1

SunOS | .5| .4| .2| .8|1.1| .1| .1| .1| .1| .2| .4| .2|11.3|5.9|3. | .2|24.4

Here's the run for SunOS (result and index column) as compared to Linux
1.1.0 (the baseline column)  (note, lps==loops/sec, lpm==loops/min)  in
all cases bigger numbers indicate better performance).

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

  BYTE UNIX Benchmarks (Version 3.11)
  System -- citadel (SunOS)
  Start Benchmark Run: Mon Oct 10 10:58:32 MDT 1994
   1 interactive users.
Arithmetic Test (type = double)            2508.2 lps   (10 secs, 6 samples)
Dhrystone 2 without register variables    23116.3 lps   (10 secs, 6 samples)
Execl Throughput Test                         9.2 lps   (9 secs, 6 samples)
File Read  (10 seconds)                    7472.0 KBps  (10 secs, 6 samples)
File Write (10 seconds)                    1200.0 KBps  (10 secs, 6 samples)
File Copy  (10 seconds)                    1003.0 KBps  (10 secs, 6 samples)
File Read  (30 seconds)                    7649.0 KBps  (30 secs, 6 samples)
File Write (30 seconds)                    1133.0 KBps  (30 secs, 6 samples)
File Copy  (30 seconds)                     997.0 KBps  (30 secs, 6 samples)
Shell scripts (1 concurrent)                 19.6 lpm   (60 secs, 3 samples)
Shell scripts (2 concurrent)                 11.3 lpm   (60 secs, 3 samples)
Shell scripts (4 concurrent)                  5.9 lpm   (60 secs, 3 samples)
Shell scripts (8 concurrent)                  3.0 lpm   (60 secs, 3 samples)
System Call Overhead Test                  5219.9 lps   (10 secs, 6 samples)
Pipe-based Context Switching Test          1334.7 lps   (10 secs, 6 samples)
Process Creation Test                        48.3 lps   (10 secs, 6 samples)

                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Arithmetic Test (type = double)               5069.5     2508.2        0.5
Dhrystone 2 without register variables       56103.3    23116.3        0.4
Execl Throughput Test                           60.8        9.2        0.2
File Copy  (10 seconds)                       1310.0     1003.0        0.8
File Copy  (30 seconds)                        919.0      997.0        1.1
File Read  (10 seconds)                     117181.0     7472.0        0.1
File Read  (30 seconds)                     117335.0     7649.0        0.1
File Write (10 seconds)                      13856.0     1200.0        0.1
File Write (30 seconds)                      13643.0     1133.0        0.1
Pipe-based Context Switching Test             8197.6     1334.7        0.2
Process Creation Test                          112.1       48.3        0.4
Shell scripts (1 concurrent)                    81.1       19.6        0.2
Shell scripts (2 concurrent)                     1.0       11.3       11.3
Shell scripts (4 concurrent)                     1.0        5.9        5.9
Shell scripts (8 concurrent)                     1.0        3.0        3.0
System Call Overhead Test                    31574.7     5219.9        0.2
                                                                 =========
     SUM of 16 items                                                  24.4
     AVERAGE                                                           1.5

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Final Notes:

The Arithmetic and Dhrystone Benchmarks were included both as a sanity
check and to provide a basis for speed comparison with the SPARCstation
IPC running SunOS 4.1.3U1 shown in the last line.  The remaining tests
were included as the member-tests of the Byte benchmark which focused on
critical system services, with the intention of providing an initial guess
of how kernel performance has varied over several levels of revision.

You'll note that I haven't run the Benchmark for every patch level... Each
run takes about an hour for good results.  If you ask nicely (and I don't
get flamed too heavily for posting "Lies, Damned Lies, and Benchmarks")
I'll run additional patch levels on request.  If there are other
benchmarks you want me to run, go ahead and send them... comparing results
will be easier if we run everything on one machine whenever possible.  If
you want to try the Byte benchmark suite yourself, you can pick it up off
ftp.uu.net.

Jeff Kuehn
Scientific Computing Division
National Center For Atmospheric Research
Boulder, Colorado  USA

------------------------------

** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************