642 lines
28 KiB
Plaintext
642 lines
28 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: Tue, 11 Oct 94 13:13:14 EDT
|
|
Subject: Linux-Development Digest #290
|
|
|
|
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: jrichard@cs.uml.edu (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: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Sun, 9 Oct 1994 08:55:00 GMT
|
|
|
|
In <longyearCxC2wx.I3A@netcom.com> longyear@netcom.com (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: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: pee@cci.com (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: martin@mawurgl.franken.de (Martin Blaschke)
|
|
Subject: Re: Could TCP/IP be implemented over SCSI?
|
|
Date: Fri, 07 Oct 1994 16:57:52 GMT
|
|
Reply-To: martin@mawurgl.franken.de
|
|
|
|
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: ianm@qualcomm.com home: ian@egbt.org
|
|
>
|
|
|
|
--
|
|
Martin Blaschke
|
|
|
|
-------------------------------------------------------------------
|
|
> E-Mail: martin@mawurgl.franken.de <
|
|
-------------------------------------------------------------------
|
|
|
|
|
|
------------------------------
|
|
|
|
From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
|
|
Subject: Re: DOSEMU Questions (386 mode?)
|
|
Date: 9 Oct 1994 14:01:12 GMT
|
|
|
|
In article <Cx81Az.9IK@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
|
|
>In <36ugt2$id3@DGS.dgsys.com> hitman@dgs.dgsys.com (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: wrasman@duncan.cs.utk.edu (Aaron 'Raz' Wrasman)
|
|
Subject: Re: Linux For Mac
|
|
Date: 11 Oct 1994 13:38:08 GMT
|
|
|
|
In article <ARMB.94Oct10140553@shiva.setanta.demon.co.uk> armb@setanta.demon.co.uk (Alan Braggins) writes:
|
|
|
|
> In article <WRASMAN.94Oct6152442@duncan.cs.utk.edu>,
|
|
> Aaron 'Raz' Wrasman <wrasman@duncan.cs.utk.edu> 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 armb@setanta.demon.co.uk abraggins@cix.compulink.co.uk
|
|
> "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:wrasman@cs.utk.edu, as766@cleveland.freenet.edu
|
|
(!=>--- Bitnet:Razron@utkvx, Kaspian@utkvx Phone# 615-584-8240
|
|
/ ) Raz Usnail:602B Longview Rd Knoxville,TN 37919
|
|
|
|
------------------------------
|
|
|
|
From: pda@procyon.com (Patrick D. Ashmore)
|
|
Subject: Re: Practical experience with Gravis Ultrasound Max?
|
|
Date: 10 Oct 1994 09:40:02 GMT
|
|
|
|
Jon Lasser (jon.lasser%goucher@wb3ffv.ampr.org) 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
|
|
pda@procyon.com Procyon Networking Fayetteville, AR 72701
|
|
Finger for PGP key URL: http://procyon.com/~pda/ +1 501 443 4393
|
|
pda@texas.net pda@sibylline.com publius enigma
|
|
|
|
------------------------------
|
|
|
|
From: kuehn@citadel.scd.ucar.edu (Jeff Kuehn)
|
|
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
|
|
Date: 11 Oct 1994 14:53:42 GMT
|
|
|
|
Rob Janssen (rob@pe1chl.ampr.org) wrote:
|
|
: In <37c8hk$ekl@ncar.ucar.edu> kuehn@citadel.scd.ucar.edu (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: bass@cais.cais.com (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: mbi@math.nat.tu-bs.de (Michael Bischoff)
|
|
Subject: Re: ext2fs vs. Berkeley FFS
|
|
Date: 10 Oct 1994 09:30:37 GMT
|
|
Reply-To: mbi@mo.math.nat.tu-bs.de
|
|
|
|
In article <ADC.94Oct9144148@bach.coe.neu.edu> adc@bach.coe.neu.edu (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: mbi@mo.math.nat.tu-bs.de
|
|
Abt. Mathematische Optimierung or m.bischoff@tu-bs.de
|
|
Inst. Angewandte Mathematik or on.bischoff@zib-berlin.de
|
|
Pockelsstrasse 14 Tel. +49-531-391-7555, Fax: +49-531-391-4577
|
|
38106 Braunschweig Germany
|
|
|
|
------------------------------
|
|
|
|
From: davj@ds5000.irb.hr (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.
|
|
--
|
|
<davor%emard.uucp@ds5000.irb.hr>, <davj@ds5000.irb.hr>
|
|
================ Davor Jadrijevic ====================
|
|
|
|
------------------------------
|
|
|
|
From: kuehn@citadel.scd.ucar.edu (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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
|
|
|
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
|
|
******************************
|