690 lines
26 KiB
Plaintext
690 lines
26 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: Thu, 13 Oct 94 23:13:12 EDT
|
||
Subject: Linux-Development Digest #304
|
||
|
||
Linux-Development Digest #304, Volume #2 Thu, 13 Oct 94 23:13:12 EDT
|
||
|
||
Contents:
|
||
Re: ext2fs vs. Berkeley FFS (Kai Petzke)
|
||
Whats the *true* scoop on AHA-2940 drivers?? (Wigs)
|
||
Re: A badly missed feature in gcc (Petteri Stenius)
|
||
Re: We a FAQ: Linux vs. *BSD!!! (Tony Porczyk)
|
||
Re: Contract Software development : Driver for PDMA16 I/O board (David - Morris)
|
||
Re: LINUX Logical volumes (Ken Latta)
|
||
Re: 1.1.53 - fdformat - IOCTL error still there (Ove Ewerlid)
|
||
Re: FTP slowdown under 1.1.52 with hdparm on (John Gotts)
|
||
[Q] What does MTU do in SLIP? (Andrew Robert Ellsworth)
|
||
Re: GCC version i2.5.8p dies with the following code (Laurent Chemla)
|
||
Re: Improving SLIP latency under Linux (John Richardson)
|
||
Re: Serious Bug In The Networking Code (Frank Lofaro)
|
||
Re: Linux For Mac (Spencer Smith)
|
||
Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Dave Perks)
|
||
Re: Filesystem idea (Andrew R. Tefft)
|
||
Re: Question about ext2fs (Ralf Baechle)
|
||
Re: Improving SLIP latency under Linux (Frank Lofaro)
|
||
Re: Linux Mud (Philippe Steindl)
|
||
Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Shaune Beattie)
|
||
Re: Qlogic (Michael Griffith)
|
||
Re: ext2fs vs. Berkeley FFS (Peter Mutsaers)
|
||
|
||
----------------------------------------------------------------------------
|
||
|
||
From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
|
||
Subject: Re: ext2fs vs. Berkeley FFS
|
||
Date: 11 Oct 94 17:02:28 GMT
|
||
|
||
hpa@ahab.eecs.nwu.edu (H. Peter Anvin) writes:
|
||
|
||
>Followup to: <37bpse$ue@newsy.ifm.liu.se>
|
||
>By author: peter@ifm.liu.se (Peter Eriksson)
|
||
>In newsgroup: comp.os.linux.development
|
||
>>
|
||
>> >The icon (for a window manager) for the file could be
|
||
>> >accessed by the following call.
|
||
>>
|
||
>> > fd1 = open("MyDataFile:ICON",O_RDONLY);
|
||
>>
|
||
>> If one were to implement something like this, then it would be much
|
||
>> better to use the "/" character to separate the filename and the subforks...
|
||
>>
|
||
>> Just a little thought.
|
||
>>
|
||
|
||
>And, incidentally, it works without kernel mods!! (A multifork file
|
||
>is *exactly* the same as a directory!)
|
||
|
||
Well. Almost. A multifork file would be something like a directory
|
||
with a "default" file: If you only specify the directory file name,
|
||
you will get the MAIN fork instead ...
|
||
|
||
|
||
|
||
Kai
|
||
--
|
||
Kai Petzke | How fast can computers get?
|
||
Technical University of Berlin |
|
||
Berlin, Germany | Sol 9, of course, on Star Trek.
|
||
wpp@marie.physik.tu-berlin.de |
|
||
|
||
------------------------------
|
||
|
||
From: wiegley@phakt.usc.edu (Wigs)
|
||
Subject: Whats the *true* scoop on AHA-2940 drivers??
|
||
Date: 13 Oct 1994 15:13:33 -0700
|
||
|
||
|
||
I'm trying to figure out whether or not the Adaptec AHA-2940 PCI scsi
|
||
controller is going to be supported under linux anytime soon...
|
||
|
||
I asked about a week ago and I've read the back articles on this thread but
|
||
there isn't a decent answer amongst them. Some posts say Adaptec won't
|
||
release the product info. one post points me to the Project-Map which
|
||
doesn't mention *anything* about *any* adaptec projects (thanks to who ever
|
||
that was, real helpful...)
|
||
|
||
There have been lots of people like myself asking this question so could
|
||
somebody who *knows* the answer please tell me if somebody is currently
|
||
working on a device driver for the AHA-2940?? If somebody is working on it
|
||
how is the progress going? if somebody isn't working on it, why not?
|
||
|
||
Thanks for any info you can give me,
|
||
|
||
- Jeff W.
|
||
|
||
------------------------------
|
||
|
||
From: Petteri.Stenius@cs.hut.fi (Petteri Stenius)
|
||
Subject: Re: A badly missed feature in gcc
|
||
Date: 13 Oct 1994 18:36:18 GMT
|
||
|
||
> David Taylor (ddt@idcube.idsoftware.com) wrote in comp.os.linux.development,
|
||
> article <9409231051.AA08511@idcube.idsoftware.com>:
|
||
> >I wish gcc for Linux could handle // comments.
|
||
>
|
||
|
||
It does. I have made the following change to file
|
||
/usr/lib/gcc-lib/i486-linux/2.5.8/specs
|
||
|
||
*cpp:
|
||
%{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{c++-comments:-lang-c-c++-comments}
|
||
|
||
Now compiling with gcc and option '-c++-comments' does what I want.
|
||
|
||
--
|
||
Petteri Stenius I " My punctuality is well known, when
|
||
Mail : Petteri.Stenius@cs.hut.fi I the revolution takes place, I'll be late
|
||
Tel. : +358-0-492382 I and I'll be shot as a traitor "
|
||
|
||
|
||
------------------------------
|
||
|
||
Crossposted-To: comp.os.386bsd.development,comp.sys.unix
|
||
From: tporczyk@netcom.com (Tony Porczyk)
|
||
Subject: Re: We a FAQ: Linux vs. *BSD!!!
|
||
Date: Thu, 13 Oct 1994 18:13:08 GMT
|
||
|
||
jmonroy@netcom.com (Jesus Monroy Jr) writes:
|
||
|
||
> This is a weekly question.
|
||
> [...]
|
||
> Can we get together and write a single FAQ on this?
|
||
> [...]
|
||
> Do I get a Yeah on this?
|
||
|
||
Outstanding idea.
|
||
|
||
t.
|
||
|
||
------------------------------
|
||
|
||
From: dwm@shell.portal.com (David - Morris)
|
||
Subject: Re: Contract Software development : Driver for PDMA16 I/O board
|
||
Date: 12 Oct 1994 05:12:25 GMT
|
||
|
||
I can't believe you want someone outside of australia for the work,
|
||
but if you do, continue reading.
|
||
|
||
I've been hacking Linux for about a month and am cutting my
|
||
teeth on Linux drivers by extending the alpha level Token Ring
|
||
driver. I have 30+ years of very broad experience in the
|
||
computing field with activities ranging from adding device
|
||
support to IBM OS/MFT to programming device driver level code
|
||
on IBM PC platforms. My experience includes 7 years leading the
|
||
project teams porting IBM mainframe FORTRAN compilers to AIX/ESA
|
||
et al.
|
||
|
||
If you happen to still be interested, I require:
|
||
1) Your assurance that the data rates you require can be
|
||
achieved in the DOS environment using the C driver
|
||
2) $125 per hour (assuming a minimum contract period of
|
||
about a month and minimal difficulties negotiating
|
||
the agreement, regular payment for effort and/or
|
||
pre-payment, etc.)
|
||
3) In addition to card, etc. for testing, suitable data
|
||
generaters with appropriate mechanisms for verification
|
||
of correctness would be required
|
||
4) Complete documentation on the hardware, etc. probably
|
||
including access to the DOS driver code
|
||
before I would consider providing an estimate you might want
|
||
to hold me to. I would be willing to spend a small amount
|
||
of uncompensated time studying the harware documentation, etc.,
|
||
but if you want a fixed price bid, that can only be as a followup
|
||
to a study phase compensated on an hourly basis. The only
|
||
thing I can provide w/o compensation is a set of approximate costs.
|
||
|
||
Should you still be interested, any contract would be with my
|
||
company and might include work performed by my associates who
|
||
though well qualifed with extentsive experience with device
|
||
driver level code on PC hardware do not have unix or linux
|
||
experience.
|
||
|
||
If you wish to discuss this further, you can email or otherwise
|
||
contact me:
|
||
David Morris
|
||
barili systems limited
|
||
10873 W. Estates Drive
|
||
Cupertino, CA 95014
|
||
(408) 366 5050
|
||
|
||
------------------------------
|
||
|
||
From: kdl@scruznet.com (Ken Latta)
|
||
Subject: Re: LINUX Logical volumes
|
||
Date: 12 Oct 1994 05:11:02 GMT
|
||
Reply-To: kdl@scruznet.com
|
||
|
||
|
||
In article 94Oct11134319@zeta.coe.neu.edu, adc@zeta.coe.neu.edu (Albert D. Cahalan) writes:
|
||
>In article <37cltq$2j5@zeus.IntNet.net> jra@zeus.IntNet.net (Jay Ashworth) writes:
|
||
> killianr@beldin.sun.ac.za (Richelo Killian) writes:
|
||
> > Is it posible to create logigal volumes across drives and/or
|
||
> > partitions and then mount a single filesystem on that volume? I know it
|
||
> > can be done on HP-UX, but I want to do it on my LINUX box?
|
||
>
|
||
> To clarify, what I believe you're asking about is the ability to create a
|
||
> logical filesystem/volume which spans physical volumes, i.e. a 3GB
|
||
> filesystem spanning 3 1GB drives.
|
||
>
|
||
[snip]
|
||
|
||
>This sounds like a dangerous mess. If a drive crashes, would you rather
|
||
>lose all your data or 1/3 of your data?
|
||
>--
|
||
>
|
||
>Albert Cahalan
|
||
>adc@meceng.coe.neu.edu
|
||
|
||
|
||
It can certainly create a lot of extra work when a drive crashes. Even as I write this my colleagues are busy restoring humongus amounts of data because, for the second time in as many months, a drive died on our HP-9000. I guess they're getting tired of the all-nighters because this time they built each filesystem on separate spindles instead of striping them across 3 spindles. Another fun aspect of LVM's is trying to maintain an accurate map of logical to physical volumes. In other words, don't bother writing an LVM for Linux on my account. What would be useful is a means to resize, both grow and shrink a partition without destoying the contents.
|
||
|
||
|
||
|
||
Ken Latta
|
||
kdl@scruznet.com
|
||
|
||
|
||
|
||
|
||
|
||
------------------------------
|
||
|
||
From: ewerlid@frej.teknikum.uu.se (Ove Ewerlid)
|
||
Subject: Re: 1.1.53 - fdformat - IOCTL error still there
|
||
Date: 12 Oct 1994 23:18:49 GMT
|
||
|
||
|
||
> For me 1.1.53 does not boot at all.
|
||
> The kernel hangs after the CSLIP message, probably when detecting
|
||
> the ethernet card (ne 2000).
|
||
|
||
We have similar problems with machines equiped with NE2000 cards.
|
||
They boot OK after a hardreset or powerdown but not after a softreset.
|
||
(Some MORE machines with NE2000 cards got this symptom with 1.1.53 ...)
|
||
We've been using linux for more then 2 years and the severity of this
|
||
problem has varied. Judging by Beckers comments in the source code and
|
||
on the net, the NE2000-clones are pretty hard to autodetect properly.
|
||
|
||
We recently had to switch from a NE2000 to a 3C509 in a P90 box
|
||
in order to get it stable in conjunction with heavy disk and net activity.
|
||
Some NE2000 clones seems to be crappy ...
|
||
|
||
------------------------------
|
||
|
||
From: john@linux.reshall.umich.edu (John Gotts)
|
||
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
|
||
Date: 12 Oct 1994 05:15:09 GMT
|
||
|
||
Mark D. Roth (roth@ux4.cso.uiuc.edu) wrote:
|
||
: Here are some figures I got, which I found to be fairly consistant:
|
||
|
||
: multcount user system clock %CPU
|
||
: 0 0.21 20.69 0:46.74 44.7
|
||
: 2 0.34 21.53 0:47.69 45.8
|
||
: 4 0.37 18.75 0:49.94 38.2
|
||
: 8 0.37 11.90 1:10.54 17.3
|
||
: 16 0.29 12.37 1:10.55 17.9
|
||
|
||
: I'd rather have the wall-clock time, personally... :)
|
||
--
|
||
|
||
You might mention what hard drive/controller you are using.
|
||
|
||
--
|
||
John Gotts (jgotts@umich.edu) 73 de N8QDW URL: http://www.umich.edu/~jgotts
|
||
GE -d+ H s+: g-- p? !au a-- w+ v C++++ UL++++ P+>++ L++ 3- E--- N+++ K- !W M--
|
||
V-- -po+(---) Y+ t+ 5 j+ R- G? tv b+ D B- e+ u--- h f+ r n- y? <Linux rules!>
|
||
|
||
------------------------------
|
||
|
||
From: are1@ritz.cec.wustl.edu (Andrew Robert Ellsworth)
|
||
Subject: [Q] What does MTU do in SLIP?
|
||
Date: 11 Oct 1994 12:00:13 -0500
|
||
|
||
|
||
|
||
------------------------------
|
||
|
||
From: laurent@brasil.frmug.fr.net (Laurent Chemla)
|
||
Subject: Re: GCC version i2.5.8p dies with the following code
|
||
Date: 12 Oct 1994 11:10:47 GMT
|
||
|
||
Gary William Flake (flake@scr.siemens.com) wrote:
|
||
|
||
: The code at the bottom of this message crashes gcc i2.5.8p. I am
|
||
: running linux 1.1.45 on a P5/90. It only crashes with -O3 or greater,
|
||
: and only with the i2.5.8p. Every other 2.5.8 that I try doesn't have
|
||
: a problem with it.
|
||
|
||
--
|
||
I've been trying to find out what caused this pentium optimizer to crash,
|
||
and as a result I found it's aborting when trying to shedule the
|
||
instructions the best it can. As soon I get some time to search a little
|
||
more I will, but for now I have to much work to do so.
|
||
|
||
I suspect the problem comes from an interaction between the optimisations
|
||
Intel added and the standard 2.5.8 optimiser. Anyone tried to crash the
|
||
original 2.4.0 from aurora.intel.com the same way ?
|
||
|
||
Laurent.
|
||
--
|
||
Laurent Chemla : chemla@cnam.cnam.fr or laurent@brasil.frmug.fr.net
|
||
Brasil BBS - +33 1 44 67 08 44 - Atari France developpers support
|
||
|
||
------------------------------
|
||
|
||
From: jrichard@cs.uml.edu (John Richardson)
|
||
Subject: Re: Improving SLIP latency under Linux
|
||
Date: 14 Oct 1994 00:06:46 GMT
|
||
|
||
In article <CxMvM9.Kr@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
|
||
>>I'm not sure about this: I don't think my modem has a transmit
|
||
>>buffer (hehe, try getting information from supra! Argh) and
|
||
>>I have a laggy interactive response. I have been in contact
|
||
>>with linux users who have faster modems with no internal buffers
|
||
>>at all who suffer from the same problem.
|
||
>
|
||
>All modems with error correction and compression have a transmit buffer.
|
||
>The only variation between modems may be how large this buffer is.
|
||
>
|
||
|
||
I don't believe this modem has either. I don't know about my supra
|
||
though, I turn off data compression and correction (with the &f0 command).
|
||
|
||
--
|
||
John Richardson
|
||
jrichard@cs.uml.edu
|
||
|
||
|
||
------------------------------
|
||
|
||
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
|
||
From: ftlofaro@unlv.edu (Frank Lofaro)
|
||
Subject: Re: Serious Bug In The Networking Code
|
||
Date: Thu, 13 Oct 94 19:47:06 GMT
|
||
|
||
In article <KETIL.94Oct9183323@lomvi.ii.uib.no> ketil@ii.uib.no writes:
|
||
>
|
||
>There appears to be a serious bug in some of the networking code
|
||
>supplied with linux/slackware, that causes the computer to get
|
||
>'network unreachable' after approximately 3 minutes of perfect
|
||
>functioning. I have no idea what the problem might be, and if
|
||
>somebody tell me where to look, I can try to figure out what versions
|
||
>my drivers etc. are. Here are the configurations I ve gotten this
|
||
>problem with:
|
||
>
|
||
>AMD DX2/66, 8Mb, VLB CL5428 1Mb with either
|
||
>* Etherlink II, kernel 1.1.50 and 1.1.49
|
||
>* SMC Ultra Combo, kernel 1.1.33, 1.1.49, 1.1.50
|
||
> -tried both coax and TP
|
||
>* SMC Ultra something else, also with various kernels
|
||
>
|
||
>AMD 386/40, 12Mb,
|
||
>* SMC Ultra Combo, kernel 1.1.33
|
||
>
|
||
>The 386 works perfectly well with the network with both cards when
|
||
>using older software (Some old SLS distrib. I believe)
|
||
>
|
||
>I would very much like to know what is wrong, and how to fix it.
|
||
>
|
||
>There is also a 'bug' in df, causing a float exception when it cannot
|
||
>access a non-existent NFS-mount.
|
||
>
|
||
>Thanks for any help,
|
||
>--
|
||
>
|
||
> <20> Ketil Malde In real life: ketil@ii.uib.no <20>
|
||
> <20> Nuke The Whales! Pave The Earth! And Honk If You Love Unicorns! <20>
|
||
|
||
Are you running routed? The could cause routes to get dropped and
|
||
thus Network unreachables to occur.
|
||
|
||
------------------------------
|
||
|
||
From: spencera@sisters.uoregon.edu (Spencer Smith)
|
||
Subject: Re: Linux For Mac
|
||
Date: 12 Oct 1994 05:21:08 GMT
|
||
|
||
Oh Please!
|
||
Why not post this to
|
||
alt.i'm.flamebait.bend.over.and.shoot.the.napalm.here?
|
||
Please stick to Linux, an OS for all seasons and all reasons.
|
||
|
||
Spencer A. Smith
|
||
(Man or Myth?)
|
||
|
||
------------------------------
|
||
|
||
From: dperks@gandalf.ca (Dave Perks)
|
||
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
|
||
Date: 11 Oct 1994 18:18:03 -0400
|
||
|
||
kuehn@citadel.scd.ucar.edu (Jeff Kuehn) writes:
|
||
|
||
>The results aren't particularly good.
|
||
|
||
>As several have mentioned previously,
|
||
>this is probably the fault of the process table handling and scheduling
|
||
>algorithms. This needs to be fixed BADLY.
|
||
|
||
^ no, it needs to be fixed WELL :-)
|
||
|
||
--
|
||
Dave Perks | dperks@gandalf.ca | 73230.2156@compuserve.com
|
||
Gandalf Data Limited | TEL 1-613-723-6500 x8765 |---------------------------
|
||
Nepean, Ontario, Canada | FAX 1-613-226-1717 | Soren Kierkegaard says
|
||
"Life can only be understood backwards; but it must be lived forwards."
|
||
|
||
------------------------------
|
||
|
||
From: teffta@erie.ge.com (Andrew R. Tefft)
|
||
Subject: Re: Filesystem idea
|
||
Reply-To: teffta@erie.ge.com
|
||
Date: Thu, 13 Oct 1994 17:17:18 GMT
|
||
|
||
In article <37d4la$g54@news.doit.wisc.edu>, schave@PROBLEM_WITH_INEWS_GATEWAY_FILE (Jeffrey Charles Schave) writes:
|
||
>Riku Saikkonen (riku.saikkonen@compart.fi) wrote:
|
||
>> space... What I'm suggesting is some sort of 'temp file' attribute that
|
||
>> would keep the file on disk until space runs low. Then, when the disk
|
||
>> space is almost 0, it would start deleting the temp files to free space.
|
||
>
|
||
>I don't think that a new file system is necessary for this. An easy
|
||
>way to accomplish this is to write a shell script run every night,day
|
||
>,whatever(via cron). This script could check the amount of free space
|
||
>left on the drive, and if necessary, destroy any .o files.
|
||
|
||
I agree, because either you're going to slow down all file allocation
|
||
in seeking out and destroying these 'temporary' files when necessary,
|
||
or you're going to end up having some kind of daemon to basically do this
|
||
anyway.
|
||
|
||
|
||
--
|
||
|
||
Andy Tefft - new, expanded .sig - teffta@erie.ge.com
|
||
|
||
|
||
|
||
------------------------------
|
||
|
||
From: ralf@resi.waldorf-gmbh.de (Ralf Baechle)
|
||
Crossposted-To: comp.os.linux.help
|
||
Subject: Re: Question about ext2fs
|
||
Date: 13 Oct 1994 17:08:14 GMT
|
||
|
||
In article <1994Oct11.150318.28373@news.cs.indiana.edu>, "Eric Jeschke" <jeschke@cs.indiana.edu> writes:
|
||
|> Can someone with some knowledge of the ext2fs internals tell me
|
||
|> how intensive the disk activity is to certain blocks like the
|
||
|> superblock and inode bitmap blocks? extfs is working fine, but
|
||
|> I'm afraid I have a poor quality disk (Seagate) that is not able
|
||
|> to handle the intense repeated disk activity to these blocks.
|
||
|
||
Neither read nor write activity does normally have a relation to the
|
||
number of errors on a disk, since heads never touch the disk surface
|
||
during normal operation.
|
||
|
||
Is is normal that sometimes a new bad bad block appears on a hard disk.
|
||
Especially on SCSI disks it is easy to map them out. But if the number
|
||
of bad blocks increases strongly in a short period of time, you really
|
||
should exchange your harddisk against a new one. Since most harddisks
|
||
have very long warranty this is even free in most situations.
|
||
|
||
|> I am slowly developing bad blocks on various inode bitmap blocks
|
||
|> (and now the superblock). The kernel complains about getting a
|
||
|> "short read" on those blocks. I am able to map them out successfully
|
||
|> using the -L option with ext2fs and the system recovers admirably,
|
||
|> but sooner or later the problem recurs with another block. The
|
||
|> latest victim is the superblock on the root partition. I am able
|
||
|> to e2fsck the partition using the -b 8193 option and averything seems
|
||
|> fine, however the system fails to mount it at bootup even though
|
||
|> I added sb=8193 to the mount options in /etc/fstab for /.
|
||
|>
|
||
|> How can I successfully boot from this partition now?
|
||
|
||
I've recently made some experiences with about the same situation. Result:
|
||
make a Backup. Throw your harddisk away. Don't waste your time with trying
|
||
to boot.
|
||
|
||
Ralf
|
||
|
||
------------------------------
|
||
|
||
From: ftlofaro@unlv.edu (Frank Lofaro)
|
||
Subject: Re: Improving SLIP latency under Linux
|
||
Date: Thu, 13 Oct 94 19:55:28 GMT
|
||
|
||
In article <longyearCxF420.9L0@netcom.com> longyear@netcom.com (Al Longyear) writes:
|
||
>rob@pe1chl.ampr.org (Rob Janssen) writes:
|
||
>
|
||
>>>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...
|
||
>
|
||
>Rob,
|
||
>
|
||
>New frames are merged into the list of frames bound for the SLIP/PPP/
|
||
>PLIP link in order based upon their priority. Each new frame is
|
||
>inserted into the list in sequence. They are not simply tacked on to
|
||
>the end of the list.
|
||
>
|
||
>So, yes, it is a very good solution to implement and use the
|
||
>IP_TOS. All higher priority frames will be sent before lower priority
|
||
>frames are sent.
|
||
>
|
||
>For this to work the best, you need to implement IP_TOS on both sides
|
||
>of the link. If you are doing an ftp transfer to read a large file,
|
||
>then it the remote side (the one running ftpd) which is doing the
|
||
>majority of the transmission. Their frames need to have a background
|
||
>(7) priority. The wu-ftpd process has had this implemented for some
|
||
>time. Unfortunately, not all implementations of TCP/IP support this
|
||
>logic. The BSD 4.3 code did not. I believe that it is in place for
|
||
>the BSD 4.4 code.
|
||
>
|
||
|
||
You could take care of the other side's ftp and background type
|
||
processes from hogging the link by only offering a tiny TCP window when
|
||
turnaround time gets too high. Yeah, it can hurt throughput, but
|
||
interactive performance is more important. E.g. it is better to have
|
||
an ftp take 10 minutes and your link be comfortable than to have the ftp
|
||
take 5 minutes during which you tear out your hair because the link is
|
||
sucking mud.
|
||
|
||
|
||
------------------------------
|
||
|
||
From: ilg@imp.ch (Philippe Steindl)
|
||
Subject: Re: Linux Mud
|
||
Date: 11 Oct 1994 17:17:38 GMT
|
||
|
||
Hullo,
|
||
|
||
just to add, that the MudOS Drivers compile out of the box on a linux system.
|
||
|
||
Philippe
|
||
|
||
------------------------------
|
||
|
||
From: sdgb1@cus.cam.ac.uk (Shaune Beattie)
|
||
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
|
||
Date: 13 Oct 1994 20:46:20 GMT
|
||
|
||
Hmm, think something might have gone wrong with your benchmarks... (the
|
||
concurrent shell scripts that is). After reading your post I downloaded
|
||
the byte benchmarks and ran them myself.
|
||
1) Before I get flamed I am *NOT* posting this as a childish 'my machine
|
||
is faster than yours thing' but rather that I believe something to be
|
||
wrong with the ones you posted.
|
||
Ok, the bechmarks were run on a P90-512k cache 16Meg PCI micronics mb
|
||
conner 540M EIDE hd running kernel version 1.1.53. Both the kernel and
|
||
the benchmarks were compiled using the pentium gcc with as much
|
||
optimisation as possible. (nb. if anyone is interested i will post the
|
||
benchmarks for 486 optimised code to show the gain in using the pentium
|
||
gcc, in fact surpisingly little).
|
||
I indexed the results against the results you posted for the 1.1.0 kernel
|
||
for comparrision.
|
||
|
||
INDEX VALUES
|
||
TEST BASELINE RESULT INDEX
|
||
|
||
Arithmetic Test (type = double) 5069.5 11922.9 2.4
|
||
Dhrystone 2 without register variables 56103.3 129726.8 2.3
|
||
Execl Throughput Test 60.8 82.2 1.4
|
||
File Copy (10 seconds) 1310.0 1974.0 1.5
|
||
File Copy (30 seconds) 919.0 1865.0 2.0
|
||
File Read (10 seconds) 117181.0 224933.0 1.9
|
||
File Read (30 seconds) 117335.0 230322.0 2.0
|
||
File Write (10 seconds) 13856.0 10039.0 0.7
|
||
File Write (30 seconds) 13643.0 15055.0 1.1
|
||
Pipe-based Context Switching Test 8197.6 8683.4 1.1
|
||
Process Creation Test 112.1 176.8 1.6
|
||
Shell scripts (1 concurrent) 81.1 160.9 2.0
|
||
Shell scripts (2 concurrent) 1.0 84.3 84.3
|
||
Shell scripts (4 concurrent) 1.0 41.0 41.0
|
||
Shell scripts (8 concurrent) 1.0 20.0 20.0
|
||
=========
|
||
SUM of 15 items 165.2
|
||
AVERAGE 11.0
|
||
|
||
|
||
ok, first off, obviously most of the tests are faster by ~2 times...
|
||
(would have expected slightly more... but thats benchmarks for you :)
|
||
the sole reason I'm posting this is to draw your attention to the Shell
|
||
scripts 2,4,8... a factor of 2 is to be expected... but there is *NO* way
|
||
my machine is 80 times faster than yours... I really think something
|
||
might have gone astray there. Just that if you are spending time
|
||
comparing kernel speeds (a task I don't envy after only running the
|
||
benchmark 3/4 times) then it might be wise to look into this.
|
||
|
||
-----------------------------------------------------------------------------
|
||
|Snail: |Email: (choose one of) |Tel: +44(0)223 501878 |
|
||
|Shaune Beattie |sdgb1@cam.ac.uk |(From 13/10/94) |
|
||
|St. Catharine's College |shaune@beattie.demon.co.uk |Thought for the day... |
|
||
|Cambridge CB2 1RL |root@beattie.demon.co.uk |I need a better sig :) |
|
||
-----------------------------------------------------------------------------
|
||
|
||
------------------------------
|
||
|
||
From: grif@corsa.ucr.edu (Michael Griffith)
|
||
Subject: Re: Qlogic
|
||
Date: 11 Oct 1994 17:26:32 GMT
|
||
|
||
In article <37d099$fng@crl2.crl.com>, Tillman Bussey <tab@crl.com> wrote:
|
||
>Has there been any development for the Qlogic VL SCSI controller? If so, which
|
||
>version, and where can I find it.
|
||
>
|
||
>Please send email.
|
||
>
|
||
>Thanks!
|
||
|
||
Try out:
|
||
|
||
ftp://cs.ucr.edu/pub/linux/qlogic/stable
|
||
|
||
--
|
||
Michael A. Griffith (grif@cs.ucr.edu)
|
||
Department of Computer Science
|
||
University of California, Riverside
|
||
|
||
|
||
------------------------------
|
||
|
||
From: plm@atcmp.nl (Peter Mutsaers)
|
||
Subject: Re: ext2fs vs. Berkeley FFS
|
||
Date: Wed, 12 Oct 1994 22:46:23 GMT
|
||
|
||
>> On 11 Oct 1994 18:10:55 GMT, basile@rosser.serma.cea.fr (Basile
|
||
>> STARYNKEVITCH) said:
|
||
|
||
Albert> 3: File managers will open them as directory trees,
|
||
Albert> because that is what they are, NOT record type files. --
|
||
|
||
BS> I agree on that.
|
||
|
||
BS> However, i would like to say (with other people) that this is the Unix
|
||
BS> way of doing. This is not neccesarily a good thing. The Unix plain
|
||
BS> byte-stream file paradigm is outdated for todays needs.
|
||
|
||
Outdated? Why? In all 25 years of Unix's existance there have been
|
||
other operating systems (in fact I think the majority of them) that do
|
||
not treat files as a plain byte-stream, but that bloat the kernel with
|
||
all kinds of knowledge of the internals of the file.
|
||
|
||
Unix's idea of plain byte-streams has been very successful and
|
||
provides a lot of flexibility because assumptions on the contents of
|
||
files are put into user space. I see no recent developments whatsoever
|
||
that have changed such needs and have outdated this paradigm.
|
||
--
|
||
Peter Mutsaers | AT Computing bv, P.O. Box 1428,
|
||
plm@atcmp.nl | 6501 BK Nijmegen, The Netherlands
|
||
tel. work: +31 (0)80 527248 |
|
||
tel. home: +31 (0)3405 71093 | "... En..., doet ie het al?"
|
||
|
||
------------------------------
|
||
|
||
|
||
** 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
|
||
******************************
|