[comp.unix.microport] RAM disk

david@daisy.UUCP (David Schachter) (04/07/88)

If the following has been answered recently, just give me a reference and I'll
go away.

With the recent discussion of problems running 9600 bps without losing char-
acters, someone bemoaned the inability to define in-memory filesystems.  Is
there really no Unix driver to define in-memory simulated disk?  For some
applications, such a facility would yield a substantial speed improvement
without the need to alter the application for better memory buffering.

					-- David Schachter,
					   soon-to-be SCO or Microport customer

Bandwidth waste: My company and I have different opinions.

dyer@spdcc.COM (Steve Dyer) (04/08/88)

In article <1010@daisy.UUCP>, david@daisy.UUCP (David Schachter) writes:
> With the recent discussion of problems running 9600 bps without losing char-
> acters, someone bemoaned the inability to define in-memory filesystems.  Is
> there really no Unix driver to define in-memory simulated disk?  For some
> applications, such a facility would yield a substantial speed improvement
> without the need to alter the application for better memory buffering.

XENIX 2.2 and above has a RAM disk driver, although I have never bothered
to use it; at least on XENIX 386, it's far more effective to give all your
memory to the paging system.  I could imagine that certain specific applications
might benefit from using some of the memory as a RAM disk, and perhaps a XENIX
286 system with just plain too much memory, given a certain application
demand, could show a benefit.  The nice thing about XENIX is you can try it
with and without a RAM disk and make up your own mind.

Needless to say, none of this deserves to be mentioned in the same breath
as losing characters at 9600 baud.  Neither XENIX 286 or XENIX 386 loses
characters no matter how hard its disks are pushed.  I run 4 dumb serial
lines under XENIX 386, one at 9600, one at 19.2kb, and the other two at
2400 baud.  Even with all of them active, I've never had any problem.
If Microport drops characters, it's because of problems in their kernel
(undoubtedly too frequent or inappropriate spl() calls sprinkled throughout)
and not because the disk is getting banged on.  I'd pressure them to get
their drivers cleaned up; from what I've heard, it wouldn't surprise me if
a RAM disk driver from them would show the same problems!

-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyer

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/08/88)

RAMdisk is supported in SCO Xenix. You have a device and can use it for
either a filesystem or a raw device. Outside of playing with it a little
when I got my upgrade I haven'y used it.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

pajari@grads.cs.ubc.ca (George Pajari) (04/09/88)

In article <1010@daisy.UUCP>, david@daisy.UUCP (David Schachter) writes:
>> With the recent discussion of problems running 9600 bps without losing char-
>> ... someone bemoaned the inability to define in-memory filesystems.  Is
>> there really no Unix driver to define in-memory simulated disk?

Driver Design Labs sells RAM-DISK drivers for SCO XENIX, IBM XENIX, (soon
Microport) and will port the driver to almost any machine given a good 
excuse (i.e. an order).

In <802@spdcc.COM> from: dyer@spdcc.COM (Steve Dyer)...
> XENIX 2.2 and above has a RAM disk driver, although I have never bothered
> to use it...

The 2.2 RAM disk driver suffers from several limitation which have been
addressed by the Driver Design Labs product:

With 2.2 the RAM disk size must be one of 16K, 32K, 64K, 128K, 256K, 
512K, 1M, 2M, 4M, 8M...  With the Driver Design Labs driver the RAM disk 
can be any size (in increments of 1K).

With 2.2 permanent RAM disks can only be resized or removed by rebooting
the machine.  With the Driver Design Labs driver the RAM disk can be 
created or removed at any time

With 2.2 the RAM disk is allocated at the next available memory location
leading to memory fragmentation.  With the Driver Design Labs driver the 
memory is allocated adjacent to previous RAM disks or at the high end of 
memory (whichever minimizes fragmentation).

In addition the Driver Design Labs driver comes with menu based utilities
to create and remove ram disks (avoids the need for a manual, although a
40 pages manual is included) and a utility which displays memory
utilisation graphically so that intelligent decisions can be made
regarding the allocation of memory.

All that aside, Steve's comments are correct...memory is usually best used
for buffers or by processes...but sometimes RAM disks can help (but probably
not when the problem is dropping characters with uucp).

George Pajari
(when not at UBC trying to finish an M.Sc. degree, programmer for
Driver Design Labs, (604) 926-UNIX)

wen-king@cit-vlsi.Caltech.Edu (Wen-King Su) (04/09/88)

In article <1962@ubc-cs.UUCP> pajari@grads.cs.ubc.ca (George Pajari) writes:
>
<Driver Design Labs sells RAM-DISK drivers for SCO XENIX, IBM XENIX, (soon
>Microport) and will port the driver to almost any machine given a good 
<excuse (i.e. an order).
>

I have thought about getting a portable 386 box to run UNIX on, but I
didn't want to have to ballance a spinning hard disk on my laps.
Reading about RAM-DISK drivers gave me an idea about building a
transportable, shake-able, kick-able, virtually indestructible :-) UNIX
box, whose root partition resides on a ROM-DISK.  Given that there
exists a working RAM-DISK driver, it should be pretty simple to modify
the dirver to treat a block of ROM as a disk.  User who wants to build
a ROM-DISK can first create a RAM-DISK, copy all the necessary files
into the RAM-DISK partition, then burn the content of the RAM-DISK into
ROM.  Does anyone know whether UNIX can be booted off a ROM disk?  Does
Driver Design Labs plan to provide ROM-DISK drivers?  Personally, I
have never touched a 386 box, so I do not know whether any of this
makes sense.

/*------------------------------------------------------------------------*\
| Wen-King Su  wen-king@vlsi.caltech.edu  Caltech Corp of Cosmic Engineers |
\*------------------------------------------------------------------------*/

zeeff@b-tech.UUCP (Jon Zeeff) (04/09/88)

Some time back I wrote and posted a ram disk driver for uport '286.  I'll
send a copy to anyone who wants it.

--Jon
-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu

dyer@spdcc.COM (Steve Dyer) (04/10/88)

In article <6052@cit-vax.Caltech.Edu>, wen-king@cit-vlsi.Caltech.Edu (Wen-King Su) writes:
> Reading about RAM-DISK drivers gave me an idea about building a
> transportable, shake-able, kick-able, virtually indestructible :-) UNIX
> box, whose root partition resides on a ROM-DISK.  Given that there
> exists a working RAM-DISK driver, it should be pretty simple to modify
> the dirver to treat a block of ROM as a disk.  User who wants to build
> a ROM-DISK can first create a RAM-DISK, copy all the necessary files
> into the RAM-DISK partition, then burn the content of the RAM-DISK into ROM.  

HP sells a portable UNIX lunchbox called the "Integral PC" which provides
most of the UNIX utilities in ROM.  It struck me as a niche product, although
it's certainly "proof of concept".  Whether the market demands a ROM/nv-RAM
UNIX box is a different question.  I have waxed effusive here on the same
concept successfully implemented on the much simpler MSDOS environment, the
Toshiba T1000, a machine which comes with drive C: (DOS itself and all its
utilities) in ROM, a 3.5" 720K floppy as drive A:, and optionally, a 768K
non-volatile RAM card which can be configured as drive D:.  With the combination
of ROM and non-volatile RAM, once can effectively ignore the floppy for many
tasks.  HP also sells a diskless portable not-quite-clone PC with similar
features (but for a lot more money than the T1000.)

-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyer

pajari@grads.cs.ubc.ca (George Pajari) (04/10/88)

From ubc-cs!uw-beaver!mit-eddie!bbn!oberon!cit-vax!cit-vlsi!wen-king Sat Apr  9 15:52:18 PDT 1988
Article 393 of comp.unix.microport:
Path: ubc-cs!uw-beaver!mit-eddie!bbn!oberon!cit-vax!cit-vlsi!wen-king
>From: wen-king@cit-vlsi.Caltech.Edu (Wen-King Su)
Newsgroups: comp.unix.microport,comp.unix.xenix
Subject: ROM disk [ was Re: RAM disk ]
Date: 9 Apr 88 05:11:30 GMT
References: <1010@daisy.UUCP> <802@spdcc.COM> <1962@ubc-cs.UUCP>
Sender: news@cit-vax.Caltech.Edu
Organization: California Institute of Technology
Lines: 24
Xref: ubc-cs comp.unix.microport:393 comp.unix.xenix:1769

Article <6052@cit-vax.Caltech.Edu> by wen-king@cit-vlsi.UUCP (Wen-King Su)
> Reading about RAM-DISK drivers gave me an idea about building a
> ...virtually indestructible :-) UNIX box, whose root resides on a ROM-DISK.
> ....  Does anyone know whether UNIX can be booted off a ROM disk?  Does
> Driver Design Labs plan to provide ROM-DISK drivers?

(a) with some mods it certainly is possible to put UNIX in ROM...it has been
    done several times...most recently by HP with their Integral personal
    computer which has a relatively full System V UNIX + utilities + root
    partition in ROM.  If you are looking for a virtually indestructible 
    UNIX box (including built-ink ThinkJet printer) check this one out.

    It was also done in the days of Version 6 and minimal UNIX (which ran 
    on 64Kb PDP-11 computers) when some University (I forget which/whom) put 
    most of the kernel in ROM and ran with only floppies on a PDP-11/03.

(b) Driver Design Labs will write driver for any device for any (reasonable)
    O/S for anybody...given enough reason (i.e. $$$).  So far no one has
    asked for ROM-DISKs...but we're willing.

George Pajari (part-time M.Sc. student, part-time device driver writer)

friedl@vsi.UUCP (Stephen J. Friedl) (04/10/88)

In article <6052@cit-vax.Caltech.Edu>, wen-king@cit-vlsi.Caltech.Edu  \
      (Wen-King Su) writes:
< I have thought about getting a portable 386 box to run UNIX on, but I
< didn't want to have to ballance a spinning hard disk on my laps.
< Reading about RAM-DISK drivers gave me an idea about building a
< transportable, shake-able, kick-able, virtually indestructible :-) UNIX
< box, whose root partition resides on a ROM-DISK.

A number of DOS laptops (some Toshibas, at least) put the OS in
ROM, and HP came out with a Unix-in-ROM portable a couple of years
ago.  I have no idea how it went...

-- 
Steve Friedl   V-Systems, Inc.   "Yes, I'm jeff@unh's brother"
friedl@vsi.com  {backbones}!vsi.com!friedl  attmail!vsi!friedl

steve@nuchat.UUCP (Steve Nuchia) (04/10/88)

From article <802@spdcc.COM>, by dyer@spdcc.UUCP:
> Needless to say, none of this deserves to be mentioned in the same breath
> as losing characters at 9600 baud.  [...]

true

> If Microport drops characters, it's because of problems in their kernel

true

> (undoubtedly too frequent or inappropriate spl() calls sprinkled throughout)

Surprisingly enough, this is apparently false.  Not the their mask
scheme makes any sense, just that it isn't the immediate cause of
this particular problem.

Seems their serial driver is ignoring input in favor of output when
it has a choice.  Given the short fifo on these stupid serial chips
(what is it, one, maybe two frames?) that is a major loss.

Prove it to yourself: run kermit (or some other telecom/terminal
emulation) on a loopback.  At speeds that it can handle well
on off-site links it drops character on a loopback.  Why? not
because the interrupts are comming at twice the rate - it can
handle two off-site links.  Its because of the strong temporal
coincidence between the two ports.  outgoing port finishes sending
and incoming port finishes receiving simultaneously.  both interrupt.
outgoing port wins, gets another charcter to write, and the
incoming frame gets lost.  The driver probably would work
if they hadn't also screwed up and spent too much time under
an spl().       sigh.

-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947

alan@coplex.UUCP (Alan Bunch) (04/11/88)

In article <1962@ubc-cs.UUCP> pajari@grads.cs.ubc.ca (George Pajari) writes:
>In article <1010@daisy.UUCP>, david@daisy.UUCP (David Schachter) writes:
>>> With the recent discussion of problems running 9600 bps without losing char-
>>> ... someone bemoaned the inability to define in-memory filesystems.  Is
>>> there really no Unix driver to define in-memory simulated disk?
>
>Driver Design Labs sells RAM-DISK drivers for SCO XENIX, IBM XENIX, (soon
>Microport) and will port the driver to almost any machine given a good 
                ^^^^ ^^^^                                  ^^^^^ ^ ^^^^
>excuse (i.e. an order).
^^^^^^^ ^^^^^^^^^^^^^^^             [ the rest doesnt apply here ]
>
>George Pajari
>(when not at UBC trying to finish an M.Sc. degree, programmer for
>Driver Design Labs, (604) 926-UNIX)

Hello there Driver Design !  If a good excuse to port or create drivers is an 
order then I think what I would like to order is one working serial driver and
one working HD driver for ST506 and -*RLL*- drives.  Please code this for 
Micro Port and any time in the next 4-6 weeks would be optimum (?) but  I 
would be willing to wait 3-4 months ( this should beat out MicroPort by a
programmers lifetime) for something that works.  

[ minor MircoPort flame over ]
[ start personal option ]

I for one think that any hot shot programer or unix company that wants to
develope and market these after market drivers to the MicroPort user base
has a real winnner and money maker.  I would pay for a working driver, how
much I am not sure but I am sure that it would be in the 50-100 range.  
I am unsure if that price would support the development of this idea.  If
it would them there is at least a small chunck of change to be made.  
If I had the expertese to write drivers I would have already done so.  

Please no flames if I have missed something as I am unsure if all of the
resources are available for the venture.  Just post constructive things
that I missed and mabe some smart cookie will put right up it and all 
us MircoPort people can get that long awaited vacation in the land or 
working device drivers.

If (something constructive to add? == 0 ) {
	Press <F> | <f> now....
else 
	cat flames > /dev/null
}

alan@coplex.UUCP (Alan Bunch) (04/11/88)

A misprotected .signature file caused this not be be #included,
so sorry for the goof !

Alan Bunch  ( yes as in bananas )          | Hack till   |Your favorite
      gatech--\                            | you crack ! |goes here !
UUCP: mit-eddie!bloom-beacon!coplex!alan   |-------------|--------------------
                                           |This opinion |This segment reserved
                                           |             |for useful data !
DISCLAMER: Opinions expressed are rented.  |  for rent.  |

sl@van-bc.UUCP (pri=-10 Stuart Lynne) (04/15/88)

In article <403@coplex.UUCP> alan@coplex.UUCP (Alan Bunch) writes:

>order then I think what I would like to order is one working serial driver and
>one working HD driver for ST506 and -*RLL*- drives.  Please code this for 
>Micro Port and any time in the next 4-6 weeks would be optimum (?) but  I 

Of course if your in a rush you could even just order it today from SCO :-)

Their serial drivers work quite well. And they support RLL now. And their
phone support is unbelievable (at least to someone who is used to certain
other suppliers of Unix for the 386).

For the first time in years I'm contemplating paying money for support.
Usually it's not worth it. SCO's seems to be.

-- 
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532