Path: utzoo!attcan!uunet!munnari!otc!metro!ditsyda!evans
From: evans@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: RAM disk in extd memory (IBM)
Summary: Yes, using 386 protected mode
Message-ID: <1045@ditsyda.oz>
Date: 11 Jan 89 13:48:13 GMT
References: <3580016@hpindda.HP.COM> <3580017@hpindda.HP.COM>
Organization: CSIRO DIT Sydney, Australia
Lines: 40

In article <3580017@hpindda.HP.COM> huilin@hpindda.HP.COM (Hui Lin Lim) writes:
>I believe that the 286 version of software should work but a
>version written specifically for the 386 should be much more
>efficient since the 386 does not have to reset when switching
>from protected to real mode.  Please note that I am speaking NOT

My 386 protected mode port (to be posted in a few weeks) of course avoids
the switching. The routine em_xfer() to handle extended memory is no
longer necessary - the RAM disk just uses phys_copy().

The efficiency gain is not very important: i/o times for 10M done with one
128K file in 8 blocks of 16 repeated 80 times (cache should be irrelevant):

           protected    unprotected

read:       13.1 sec      22.4 sec
write:      13.3 sec      22.6 sec

i.e. about 777000 bytes/sec protected and 464000 unprotected. Compared with
the processor limitation of 20M/sec (at 20MHz) and the RAM limitation of
9.5M/sec (on my machine), these times are uniformly awful, so time would
be better spent improving FS. DOS gets around 4M/sec on this test.

The main reason FS is slow is it breaks up large blocks into 1K blocks for
the drivers, when it would be better to do the opposite.

Assuming the difference in the times is from switching overhead (an
overestimate), and 10K blocks to give the 10M (an underestimate), the
switching overhead is 0.93 millisec. This is more important, since
interrupts are disabled for this time plus the copy time of 0.1 millisec
(more on AT's) so serial interrupts will be lost around 9600 baud.

There were CPU bugs which killed my original version of the protected mode
phys_copy(). The string instructions didn't work right across 64K
boundaries, using a 16 bit code segment with adress size prefixes to get
at a 32 bit data segment Using a 32 bit code segment sidestepped the bugs.
Does anyone know about the official 386 bug list or if I can get I free
new CPU? (Mail only on this.)
-- 
Bruce Evans		evans@ditsyda.oz.au
D