Subject: Linux-Development Digest #410
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:     Wed, 26 Jan 94 18:51:30 EST

Linux-Development Digest #410, Volume #1         Wed, 26 Jan 94 18:51:30 EST

Contents:
  Re: Upper Memory Blocks ?? (ALAN L HIGHTOWER)
  Re: Atari port (Hamish Macdonald)
  Re: Version control systems... ("Eric Jeschke")
  Re: Simple SHORT telnet prog (David Rensin)
  DAC ADC device driver (HENRY WONG)
  Simple SHORT telnet prog (Ed)
  NFS Problem (Michael Finken)
  Re: Which is better? 680x0 or 80x86? (David Kastrup)
  Re: Which is better? 680x0 or 80x86? (Bob Amstadt)
  Re: Which is better? 680x0 or 80x86? (Kai Petzke)
  Re: kmalloc for more then 4096 Bytes ? (Mark Evans)
  Re: kmalloc for more then 4096 Bytes ? (Mark Evans)
  Exabyte 8505 (paul shen)
  write-protected floppies (David Holland)
  mktemp() broken? (Savio Lam)
  Linux HPFS speed (was Re: cluster-07 anf HPFS) (John Paul Morrison)
  Re: Upper Memory Blocks ?? (Kai Petzke)
  Re: Which is better? 680x0 or 80x86? (Alan Braggins)

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

From: alh@engr.engr.uark.edu (ALAN L HIGHTOWER)
Subject: Re: Upper Memory Blocks ??
Date: Tue, 25 Jan 1994 19:05:56 GMT

wpp@marie (Kai Petzke) writes:

>nick@quay.ie (Nick Hilliard) writes:
>
>>Leon Garde (lgarde@scorch.hna.com.au) spoke thus:
>>Linux can inherently sees 16 Megs of memory as 16M consecutive bytes.  UMBs,
>>XMS and EMS and those sort of things are horrible kludges implemented for
>>DOS to try and make some use of the memory above 640K, however
>>inefficiently.
>
>I believe, you misunderstood the post you quoted.  The author was
>speaking about people, who use DOS and Linux, and need a setup,
>which is a good use with DOS.  So they enable BIOS shadowing,
>and they have "DOS=HIGH,UMB" (or something like this) in their
>config.sys.  As a result, they may loose up to 360 kB of memory
>(from 0xa0000 to 0x100000), as they cannot tell their BIOS to
>map these addresses to other addresses.  Ok, they could change
>their BIOS setup every time, they change from DOS to Linux or
>vice versa, but this isn't handy.
>
>If the average Linux box has 8 MB, 360kB is about 4.5 per cent of
>the total available memory.  Why waste it?  Especially people
>with only 4 MB of RAM would like the additional memory (after
>loading the kernel, shell and the update daemon, they only have
>about 2.5 MB left).
>
>The problem seems to be, that the commands for memory mapping
>and unmapping are specific to the chipset.  For example, if you
>selected BIOS shadowing, ROM is written to RAM, and then (I guess,
>at least), the RAM is mapped read-only, so accidental writes won't
>mess up the BIOS.
>
>The second problem is, that all devices are located in the upper
>memory address range.  So you had to specify for your Linux setup,
>which pages (4k each) to use, and which not.  Experimenting with
>these would be like playing with the I option of this dreadfull
>emm386 thing.
>

Boy oh boy ooh boy oh boy...... They just don't teach them like they used too..

Wow, what a misconception.....   The memory between 640 and 1024 has only two
address spaces allocated always...  Thats video memory and BIOS...  
Unfortunately there is nothing you can do about Video mem.. BIOS has less that
64K address space allocated to it, BIOS shadowing is simply moving the BIOS
that is using that address space in to the RAM that is there.  Almost totally
software transparent.

Linux or DOS dosn't care if you enable BIOS shadowing.   Secondly, Linux uses
the address space in that region (except Vid and BIOS) for general memory
pool allocation...  There are NO hardware devices that map into those location
without having a supplied driver, even then, the mapping is not fully 
complete without driver setup...  Linux will work fine reguardless of DOS
designed hardware...  

Even still.... with Video Memory mapped out, BIOS mapped out, there is only
less than 256K left....  That wont do you much good with most Linux apps...

My two cents worth... Alan..


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

From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Atari port
Date: 25 Jan 1994 14:53:39 GMT

>>>>> On 24 Jan 1994 18:42:59 EST,
>>>>> In message <1994Jan24.234259.2931@radar.demon.co.uk>,
>>>>> richard@radar.demon.co.uk (Richard Hodson) wrote:

Richard> Is anyone out there porting Linux to the Atari TT? I heard
Richard> rumour of such a port ages ago, but have seen no
Richard> evidence. The 680x0 mailing list seems very quiet.

I only post to the 680x0 channel when I have something to
say/announce.

I haven't heard from the Atari porters in a long time.

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

From: "Eric Jeschke" <jeschke@cs.indiana.edu>
Subject: Re: Version control systems...
Date: Tue, 25 Jan 1994 13:54:19 -0500

rsmits@xs4all.hacktic.nl (Ron Smits) writes:

: Check out RCS version 5.6a is distributed under the GNU licensing and is
:imho a very robust and easy package to use. Furthermore Emacs completly
:supports it

I use RCS, but wasn't aware of the emacs support.  In what way does it
support RCS?


-- 
Eric Jeschke                      |          Indiana University
jeschke@cs.indiana.edu            |     Computer Science Department
eric%marmot@moose.cs.indiana.edu  |

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

From: rensin@eng.umd.edu (David Rensin)
Subject: Re: Simple SHORT telnet prog
Date: 25 Jan 1994 19:20:33 GMT

In article <1994Jan25.181203.17174@ee.surrey.ac.uk> ee89jje@ee.surrey.ac.uk (Ed) writes:
>I need to get hold of a telnet program that does not have any frills in it,
>just simply asks for an ip address and then conects to it.  I don't need any
>option negotiation, just a plain connection.
>
>Anyone got anything like this?
>
>I'm trying to write my own, but I'm getting rapidly pissed off with trying
>to debug a forked process and also send out WON'T codes to the remote telnet
>daemon.
>
>Please!
>
>Thanks,
>Ed
>--
>Julian Edwards, alias Ed.| J.Edwards@ee.surrey.ac.uk, ee89jje@surrey.ac.uk
>Dept. of Elec. Eng.      | 
>University Of Surrey     | When is a sperm happiest? 
>Guildford. ENGLAND.      |     When it has egg on its face.


The following is a simple client program written in Perl. It first appeared in
the Programming Perl book.


                -dave :-)

=========== CUT HERE =========


#! /usr/local/bin/perl

($them,$port) = @ARGV;
$port = 2345 unless $port;
$them = 'localhost' unless them;

$AF_INET =2;
$SOCK_STREAM = 1;

$SIG{'INT'} = 'dokill';
sub dokill {
        kill 9,$child if $child;
}

$sockaddr = 'S n a4 x8';

chop($hostname = `hostname`);

($name,$aliases,$proto) = getprotobyname('tcp');
($name,$aliases,$port) = getservbyname($port,'tcp')
        unless $port =~ /^\d+$/;;
($name,$aliases,$type,$len,$thisaddr) =
        gethostbyname($hostname);
($name,$aliases,$type,$len,$thataddr) = gethostbyname($them);

$this = pack($sockaddr, $AF_INET, 0, $thisaddr);
$that = pack($sockaddr, $AF_INET, $port, $thataddr);

# MAKE SOCKET FILEHANDLE

if(socket(S, $AF_INET, $SOCK_STREAM, $proto)) {
        print "socket ok\n";
}else{
        die $!;
}

#GIVE THE SOCKET AN ADDRESS

if (bind(S, $this)) {
        print "bind ok\n";
}else{
        die $!;
}


# CALL UP THE SERVER.


if (connect(S,$that)) {
        print "Connect ok\n";
}else{
        die $!;
}



# SET SOCKET TO BE COMMAND BUFFERED.

select(S); $| =1; select(STDOUT);

# AVOID DEADLOCK BY FORKING.


if ($child = fork) {
        while (<STDIN>) {
                print S;
        }
        #sleep 3;
        do dokill();
}else{
        while(<S>) {
                print "REPLY: $_";
        }
}

__________ CUT HERE ____________



Usage: client <host> <port>


        -good luck

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

From: hwong@ee.ryerson.ca (HENRY WONG)
Subject: DAC ADC device driver
Date: 25 Jan 1994 19:31:54 GMT

        Regarding the Voice capabilities for 386 under UNIX ... 

Does anyone know anything about the AM79C30A DAC ADC chip used in the
audio card in the SUN workstations ?  And is it possible to sue in on
the 386 PC's ?  

                Info regarding device drivers for the DAC ADC would be most
appreciated ...

Thanks in advance.

Henry
hwong@ee.ryerson.ca


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

From: ee89jje@ee.surrey.ac.uk (Ed)
Subject: Simple SHORT telnet prog
Date: Tue, 25 Jan 94 18:12:03 GMT

I need to get hold of a telnet program that does not have any frills in it,
just simply asks for an ip address and then conects to it.  I don't need any
option negotiation, just a plain connection.

Anyone got anything like this?

I'm trying to write my own, but I'm getting rapidly pissed off with trying
to debug a forked process and also send out WON'T codes to the remote telnet
daemon.

Please!

Thanks,
Ed
--
Julian Edwards, alias Ed.| J.Edwards@ee.surrey.ac.uk, ee89jje@surrey.ac.uk
Dept. of Elec. Eng.      | 
University Of Surrey     | When is a sperm happiest? 
Guildford. ENGLAND.      |      When it has egg on its face.

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

From: finken@conware.de (Michael Finken)
Crossposted-To: comp.os.linux.help
Subject: NFS Problem
Date: 25 Jan 1994 18:07:48 GMT

Hi folks,

I've installed Linux 0.99PL14t.  I'm experiencing a strange problem with NFS.
I've mounted a partition from a Sony NeWS (bsd 4.3 derivate) machine.  The
userid and groupid of the directory's owner and the user working on Linux
are the same.  I create a directory on that disk, do a cd into it and a pwd
afterwards.  pwd reports that I'm still in the previous directory.  About a
minute later (probably when the sony machine did a sync), everything is fine
and I can really cd into the new directory.

I do not get any log or console messages on the Sony, concerning NFS problems.
I have no problems with the file systems mounted from a Sun3 with SunOS4.1.1.

Are there any interoperability problems known with other NFS implementations?

Michael


===============================================================================
Michael Finken                                Conware Computer Consulting GmbH
E-Mail: finken@conware.de                     Killisfeldstr. 64
                                              76227 Karlsruhe
                                              Tel.: 0721/9495-0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
WINDOWS...  It's from those who gave us EDLIN...
===============================================================================

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

From: dak@rama.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 25 Jan 1994 20:17:10 GMT

piggy@hilbert.maths.utas.edu.au (La Monte Yarroll) writes:

>bantolph@unm.edu (-=| Bantolph |=-) writes:

>>I am a mechanical engineer and not very knowlegable on the guts of 
>>microprocessors or operating systems so please pardon my ignorance.

>You won't larn nut'n witout ask'n.

>BTW, this topic can spawn religious wars, so tread lightly.  My own
>bias should be clear below.
I'll try not to get into religion, and criticize only obvious falsehoods.


>The one thing needed to support a multi-tasking OS is memory
>management.
Wrong. OS/9 gets along without. MM is necessary for *safe* multitasking
(where (theoretically) only the kernel can crash the system).

>  The 68000 did not have an MMU, but neither did the 80286.
See below.
>The 68010 included some minimal MMU support, and could thus run a fair
>version of Un*x.
The 68010 has no MMU support. What it does, is making the reading
of interrupt etc. registers priviledged operations, so that they can
be trapped in user mode. What it does, too, is to save sufficient
information at a bus fault to either retry an operation, or simulate
success with a specific result. This makes virtual machines possible,
which can even simulate being realtime, or in supervisor mode.

So *if* you have an MMU, you can work with virtual memory (for example)
with an 68010, which was hard to do to impossible for an 68000.

>  The memory segmenting hardware of the 80286 allowed
>some MMU-like operations, and so it was possible to run decent toy
>versions of multi-tasking OS's like COHERENT 3.0.
It has a (although slow) fully segmented MMU. The segments itself,
however, cannot exceed 64k each, so this has not become much of
an issue, especially since Microsoft mostly ignored it.
Also you cannot switch back from MMU (protected) mode to real.
> The 80386 and 68020
>both have real MMUs and so are capable of running full versions of
>Un*x-like OS's.
The 68020 is the 32Bit Microprocessor of the 68xxx family. It has
a more indexed addressing modes, and a few more instructions.
The Registers have been 32Bits in 68000 from the beginning, so not
much change there. The 68020, like 68010, is capable of virtual
Memory support. It has *no* MMU on chip.

The 68030 is basically 68020+Paging MMU, about what the 80386 tries
to be. Forget about Unix and such below 68030. Although 68020 will
work fine with MMUs, they are not as standardized as on-chip ones.
Of course I have worked with 68020, and even 68000-Unixes, but they
come together with the computer and *really* cost.

>On-chip cache, fast bus, and high clock speed all make most things go
>faster, but they are just icing.  You can run a full-fledged Un*x on
>a 386SX16, or a 10Mhz 68010--you just have to spend a little more time
>waiting.

You cannot on 68010 alone, since it has no MMU.

>[I'm so proud of myself--I didn't use the phrase "Evil Intel" once! :-]
Yes, but you cheered Motorola in regions where this would seem doubtful.

Still, I'd prefer a Motorola, if it was as abundantly supported.
-- 
 David Kastrup        dak@pool.informatik.rwth-aachen.de          
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

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

From: bob@amscons.amscons.com (Bob Amstadt)
Subject: Re: Which is better? 680x0 or 80x86?
Date: Wed, 26 Jan 1994 00:18:03 GMT

In <2i3l44$75o@tyana.denkart.be> gc@tyana.denkart.be (Geert Coelmont) writes:
>One small remark: MMU is needed for multiUSERing, NOT for multiTASKing.

Not correct.  An MMU is not needed for multiuser nor multitasking systems.
It is however needed for virtual memory.  A MMU only provides a way to
map non-contiguous or unordered physical pages of memory into into
a more convenient logical mapping of memory.  MMU's also provide a
mechanism to assign a privilege level to each page of memory.  Although
this feature is also duplicated in the 80*86 (>= 286) segments.  The MMU
also provides a means for the CPU to mark certain logical pages as
"not available".  This is how virtual memory paging is implemented.

Multi-user and multi-tasking systems have been implemented on the 286
even though it has no MMU.  Although the 64k limit on segment size
makes it difficult to port programs that were written to operate in
large (> 64k) non-segmented memory systems.
-- 
Bob Amstadt
bob@amscons.com

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

From: wpp@marie (Kai Petzke)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 26 Jan 1994 00:53:10 GMT

rob@pe1chl.ampr.org (Rob Janssen) writes:

>In <2i1va2$63f@diemen.utas.edu.au> piggy@hilbert.maths.utas.edu.au (La Monte Yarroll) writes:

>>Compiler writers like CPU's with lots of interchangable registers, but
>>that's because it makes register allocation easier--this has little to
>>do with multi-tasking.

>In fact, lots of registers is a disadvantage to multitasking, as you will
>have to swap them all on a task switch...

And more important: upon system calls, you have to save the registers,
too, because the system call could force a task switch (example: call
to read(), with no data available).  Typically, system calls occur much
more often than task switchs.

For function calls, you have to save registers, too.  SPARC hardware
works around this by arranging registers in kind of a "stack".  At
any given time, you see 3 blocks of 8 registers each of these stack.
Uppon a function call, the stack window moves by 16 registers.  So 8
registers are shared between the calling and the called function, and
can be used to transfer arguments and return values.  8 registers are
local to each function.

Typically, this "stack" has a big number of registers on chip (like
256).  If that runs full, it has to be saved to real memory, though.
-- 
Kai Petzke <wpp@marie.physik.tu-berlin.de>
Advertisement by Microsoft in a well-known German magazine:
        If you don't like our programmes, then make your own ones.
However, they expect you to use Microsoft products for this -:)

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

From: evansmp@mb48025.aston.ac.uk (Mark Evans)
Subject: Re: kmalloc for more then 4096 Bytes ?
Date: Tue, 25 Jan 1994 20:38:49 GMT

Matthias Urlichs (urlichs@smurf.noris.de) wrote:

: BSD networking uses buffer chains ("mbufs") to work around this, but Linux
: networking has different ideas -- and fitting a different buffering scheme
: into the networking code is a lot more difficult than just grabbing the
: BSD networking code and stuffing it into Linux whole (more or less).

It is not too difficult to write code which uses buffer chains. (even variable
length buffers).
The advantage is that fragment reassembly is quite a bit easier.
Checksumming is not so easy.

NFS still appears to be a problem, I think it uses a fiddle of some sort to
call the socket routines from kernel space.

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

From: evansmp@mb48025.aston.ac.uk (Mark Evans)
Subject: Re: kmalloc for more then 4096 Bytes ?
Date: Tue, 25 Jan 1994 20:44:27 GMT

Alan Cox (iiitac@swan.pyr) wrote:
: In article <2i1ild$5dh@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
: >
: >BSD networking uses buffer chains ("mbufs") to work around this, but Linux
: >networking has different ideas -- and fitting a different buffering scheme
: >into the networking code is a lot more difficult than just grabbing the
: >BSD networking code and stuffing it into Linux whole (more or less).

: The BSD mbuf code is inefficient in many cases and can end up doing a lot
: of allocations it doesn't need to. When its backed by a fast fixed mbuf 

Dosn't BSD code use fixed size buffers?

: block cache its not so bad, but Linux has a unified memory management scheme.
: MBufs also play havoc with DMA device drivers.

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

From: pshen@junction.gic.com (paul shen)
Crossposted-To: comp.os.linux,comp.os.linux.help,comp.os.linux.misc
Subject: Exabyte 8505
Date: 25 Jan 94 10:55:49

Does anyone know how to make ExaByte 8505 work on linux? I can write
and read with the existing device st0/nst0. But I can not read tape
which written by SUN, in which I think the block size is not 512
bytes. Also how can I create few different devices which will allow me
to write onto tape with different formats, such as 8500 or 8505 format.

Thanks,
Paul
--
/********************************************************/
/*      Paul Shen,                                      */
/*      General Instrument                              */
/*      6262 Lusk Blvd, San Diego, Ca 92121             */
/*      (619) 535-2556  (office)                        */
/*      (619) 453-5238  (home)                          */
/*      (619) 625-7959  (fax)                           */
/*      email:  pshen@image.mit.edu                     */
/*              pshen@junction.gic.com                  */
/*              pshen@gi.com                            */
/********************************************************/

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

Subject: write-protected floppies
From: dholland@husc7.harvard.edu (David Holland)
Date: 24 Jan 94 21:38:59


I just discovered (the hard way, of course) that msdosfs, at least,
does not check the physical disk to see if it's write-protected when
it mounts.

Nothing got clobbered (the disk WAS write-protected, after all) but
after the adventure the kernel had a different idea of what was on the
disk than the disk did.

This is a serious problem, because the writes typically won't actually
fail until update runs sync, at which point the user process that
tried to change something is long gone.

This is with a straight pl14 kernel. 

--
   - David A. Holland             | Nobody ever went broke underestimating
     dholland@husc.harvard.edu    | the intelligence of the American public.

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

From: lam836@cs.cuhk.hk (Savio Lam)
Subject: mktemp() broken?
Reply-To: lam836@cs.cuhk.hk
Date: Sun, 23 Jan 1994 13:43:19 GMT

Hello all,

        I am trying to compile cshar (the shell archive generator)
version 2.0 (patchlevel 3) under Linux. Both findsrc and makekit triggers
a segmentation fault. I've found out that the problem occurs when mktemp()
is called. Does anyone have any idea?

Configuration:
Linux0.99pl14
gcc 2.4.5
libc 4.4.4
486DX2-66, 8M RAM.


        Thanks for any info.

Regards,
Savio Lam.

--
###############################################################################
#                                 |        _                                  #
# ------------------------------- |      _| |_                                #
# Lam Lai Yin, Savio              |     |_   _|                               #
#                                 |       | |                                 #
# Internet: lam836@cs.cuhk.hk     |     /     \     Can't live with DOS?      #
# Department of Computer Science  |    |  DOS  |                              #
# Chinese University of Hong Kong |    |       |    Try Linux...              #
# ------------------------------- |    |       |                              #
#                                 |  ^^^^^^^^^^^^^                            #
###############################################################################


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

From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
Subject: Linux HPFS speed (was Re: cluster-07 anf HPFS)
Date: Tue, 25 Jan 1994 19:43:37 GMT

In article <1994Jan25.013606.5944@news.eng.convex.com>,
Chris Smith <csmith@convex.com> wrote:
>   From: rob@pe1chl.ampr.org (Rob Janssen)
>   Date: Sun, 23 Jan 1994 14:21:30 GMT
>
>   >used in hpfs_fs.c is defined differently than the one cluster-07
>   >patches the kernel with.
>
>   true
>
>   >Any hints.
>
>   modify the hpfs routines to comply with the different breada...
>
>Yeah.  I believe (not tested) all that's needed is to replace the
>breada call with a similar bread.  
>
>[ I think our news server ate an earlier reply from me saying to use
>four bread's.  If that posting got out somehow, ignore it. ]

One disturbing thing about HPFS is that it is *slow*.
I don't think the cluster patches will help on IDE drivers will they?

I compared read speed for HPFS (since it is read only in Linux) with
the speed for FAT and ext2.

These are very rough numbers.

/disk/c is a 30 meg DOS FAT partition on a Quantum IDE drive (LPS240 I think)
/disk/d is a 200 meg HPFS disk on the Quantum
/tmp    is ext2fs mounted on a Maxtor 7345A IDE drive.

both the drives are good quality and pretty similar in performance.

since HPFS is readonly, I tested it with an existing file.

FAT, 1st IDE drive:

ls -l /disk/c/doom/doom1.wad
-rwxr-xr-x   1 root     root      4274218 Dec 15 17:01 /disk/c/doom/doom1.wad*

/sbin/frag /disk/c/doom/doom1.wad

/disk/c/doom/doom1.wad: Invalid argument
   0%  /disk/c/doom/doom1.wad  (0 block(s), 0 fragment(s), largest 0)

OK, looks like frag doesn't work on FAT drives.

time dd if=/disk/c/doom/doom1.wad of=/dev/null bs=4k

result:
1043+1 records in
1043+1 records out
0.01user 2.77system 0:07.99elapsed 34%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

--> 522 kB/s (not impressive but I don't have any IDE patches applied)

HPFS, 1st IDE drive:

hpfs is read only and I didn't feel like booting OS/2 to use the same file.

ls -l /disk/d/tmp/macawa15.avi 
-rwxr-xr-x   1 root     root      1888880 Apr 22  1993 /disk/d/tmp/macawa15.avi*

note, this file is SMALLER

/sbin/frag /disk/d/tmp/macawa15.avi 
   0%  /disk/d/tmp/macawa15.avi  (1845 block(s), 6 fragment(s), largest 692)

doesn't look too bad

time dd if=macawa15.avi of=/dev/null bs=2k
922+1 records in
922+1 records out
0.04user 19.34system 0:22.32elapsed 86%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

I tried this a few times with different block sizes, and 4k blocks didn't
help. 1 or 2k seemed better.


--> 83 kB/s (ugh!!)
 

ext2fs, on 2nd IDE drive

ls -l /tmp/doom1.wad
-rwxr-xr-x   1 root     root      4274218 Jan 25 11:17 doom1.wad*

/sbin/frag /tmp/doom1.wad
   2%  doom1.wad  (4175 block(s), 105 fragment(s), largest 256)

a little bit fragmented, shouldn't throw anything far off though.

time dd if=doom1.wad of=/dev/null bs=8k
521+1 records in
521+1 records out
0.03user 2.95system 0:05.71elapsed 52%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

--> 731 kB/s

Notes: 

I ran each of the "time dd" sequences several times for each, tried differed
block sizes, and selected the best. On the first few runs for each,
the times would be longer and %CPU would be higher, then after several
tries the cache or something would kick in. I don't know why caching
wouldn't show up on the second run; it took several tries before
times would drop a couple of seconds and and %CPU would drop by 10 or 20
points.

Anyway Linux's cache should benefit each filesystem similarly.  The
DOS and HPFS partitions were on a drive with a 256k cache.  I don't
think the Maxtor drive the ext2 partition was on had that big a cache
(64k or 128).  The point wasn't to show which drive was better, but to
show that HPFS (Linux) suffers from poor reading speed. (Write speed
is irrelevant at this point anyway). Crude test or not, it's safe to
say HPFS linux is an order of magnitude slower. (I'm still glad to
have it though!)



-- 
==========================================================================
BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- 
jmorriso@bogomips.ee.ubc.ca                       jmorriso@rflab.ee.ubc.ca 
==========================================================================

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

From: wpp@marie (Kai Petzke)
Subject: Re: Upper Memory Blocks ??
Date: 26 Jan 1994 01:19:01 GMT

alh@engr.engr.uark.edu (ALAN L HIGHTOWER) writes:

>wpp@marie (Kai Petzke) writes:

[...]

>Boy oh boy ooh boy oh boy...... They just don't teach them like they used too..

Maybe, the misconception is with you:

>Wow, what a misconception.....   The memory between 640 and 1024 has only two
>address spaces allocated always...

Wrong.  You may have:
- BIOS ROM
- VGA BIOS ROM
- Video RAM of your color card
- Video RAM for your second b/w card
- SCSI hardware BIOS RAM
- Ethernet card RAM
- etc., etc.

>Thats video memory and BIOS...  
>Unfortunately there is nothing you can do about Video mem.. BIOS has less that
>64K address space allocated to it,

I think (can't find out without rebootign), BIOS is 32 k on my system, and
VGA BIOS is 64 k.

>BIOS shadowing is simply moving the BIOS
>that is using that address space in to the RAM that is there.  Almost totally
>software transparent.

It is totally transparent.  The move is done from ROM to RAM at the
same addresses.  Afterwards, the RAM is set readonly by the hardware,
so it is out of the use for Linux without unlocking the memory (by
issueing commands to the CHIPSET).

>Linux or DOS dosn't care if you enable BIOS shadowing.   Secondly, Linux uses
>the address space in that region (except Vid and BIOS) for general memory
>pool allocation...

It definitely does *NOT*.  This is exactly the meaning of the message
"384k reserved".

>There are NO hardware devices that map into those location
>without having a supplied driver,

There are, namely the BIOS ROM's on adapter card.  Their mapping
is independant of drivers (some drivers even use these ROMs to
autodect the cards, take a look at the seagate driver in
drivers/scsi/seagate.c, especially at the values in the array
"seagate_bases").  Often, the mapping is dependant on jumpers
(= hardware configuration).

>even then, the mapping is not fully 
>complete without driver setup...  Linux will work fine reguardless of DOS
>designed hardware...  

>Even still.... with Video Memory mapped out, BIOS mapped out, there is only
>less than 256K left....  That wont do you much good with most Linux apps...

>My two cents worth... Alan..

-- 
Kai Petzke <wpp@marie.physik.tu-berlin.de>
Advertisement by Microsoft in a well-known German magazine:
        If you don't like our programmes, then make your own ones.
However, they expect you to use Microsoft products for this -:)

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

From: armb@setanta.demon.co.uk (Alan Braggins)
Subject: Re: Which is better? 680x0 or 80x86?
Date: Tue, 25 Jan 1994 11:17:55 GMT

In article <2i14so$a4a@draco.unm.edu> bantolph@unm.edu (-=| Bantolph |=-) writes:
>   with a few questions. Which is a better processor for running a UN*X
>   like operating system on, the Motorola 680x0 series or the Intel 80x86
>   series? I have heard a few people complain about 68000's not being able
>   to multitask well so they switched to Intel chips. Is there any truth 
>   to this?

No. The only people I can think of who might be counted as switching
from 680x0 to 80x86 are Sun, who replaced the 680x0 with RISC (Sparc) in
their own machines, but now support Solaris on 80x86.

HP moved to RISC (HP-PA), Apollo moved to RISC/got bought by HP, Apple
are moving to PowerPC, Commodore no longer do UNIX and are rumoured to
be moving towards RISC (probably HP-PA) for high end future Amigas.

Windows NT (which is multi-tasking, though not that Unix-like) is
designed to be portable, unlike earlier 80x86 only MS systems. A 680x0
port is possible (or so someone at Microsoft talking about the
technical feasibility of an Amiga port) (though not necessarily
likely).

The advantage of 80x86 based systems is that PC clones are relatively
cheap and plentiful.
--
Alan Braggins  armb@setanta.demon.co.uk  abraggins@cix.compulink.co.uk
"Any technology distinguishable from magic is insufficiently advanced"

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


** 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
******************************
