pete@wlbr.EATON.COM (Pete Lyall) (01/01/70)
In article <1585@tekgen.TEK.COM> jonh@tekgen.UUCP (Jon Howell) writes: > >You're right, Pete--we'd LOVE that cache! Also, that nice effect of open key- >board during disk access. Also, does that mean the chars show on the screen, >or are just read? Keyboard 'lockout' is ususally caused by the way the floppy controller is set up and used. As delivered, the standard RS controller (and most of the clones) are programmed to actually HALT the 6809 during data xfer.. the only thing that gets the 6809 out of the loop is a NMI (non-maskable interrupt), if I recall correctly. Most hard disk and ramdisk drivers don't suffer from this malady, which is to say that you get full typoe ahead (up to the limits of your terminal driver's input buffer). Also, the echoing is handled by SCF, so you won't see the characters echoed until an I$read or I$readln is done... actually this is quite nice.. it shows you the characters as it uses them, not all at once (when you type them). -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
mckay@ea.ecn.purdue.edu (Dwight D Mckay) (01/01/70)
The Microware release of OS9 for the Atari ST has variable read-caching for floppies. It makes a big difference in speed. If I remember correctly you can set the cache to be between 32 and 128K in size. (My manuals are at home, sigh...) This release of OS9 also comes with a RAM disk. A meg. of memory is nice to work with! I'm glad I sold the Coco... --Dwight Mckay, ECN Workstation Software Support [arpanet: mckay@ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay] [Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561]
ww0n+@andrew.cmu.edu (Walter Lloyd Wimer, III) (08/04/87)
A perusal of *The Rainbow* shows that everyone and his brother is
selling 512K RAM upgrades for the CoCo 3. The prices range from
about $70 to $130. Some include GIME chip specs, RAMdisk programs,
RAM test programs, etc. Some advertise boards with gold-plated pins
and "fast, reliable 120 ns RAMs." Some don't even mention the access
time for their RAMs.
I know about the flaw in the GIME timing which makes 120 ns access
RAMs the best choice for the CoCo 3. I know you must be careful not
to push the board too far into the socket, lest the pins short out
against the tops of the capacitors. I've also heard that a fan may
be a worthwhile investment.
When I upgraded my original CoCo to 64K I shopped around and bought
the cheapest 4164's I could find: $4.85 a peice when the going rate
was $6.95 or more. These turned out to be high-quality 150 ns Motorola
chips which worked fine. I was very happy. I'm a little more wary
about the CoCo 3, though, since a satelite board and the GIME timing
problem are involved. Does anyone have a few words of wisdom for
someone who wants to upgrade to a 512K system? Good/bad experiences
with any of the common mail-order sources? Are the $70 boards just as
good as the $130 boards, or do you get what you pay for? Right now
I'm thinking of buying one in the $100 range.
Thanks for any advice.
Walt Wimer
Carnegie Mellon University
Internet: ww0n+@andrew.cmu.edu
Bitnet: ww0n+%andrew.cmu.edu@cmuccmva
UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!ww0nbaxter@milano.UUCP (08/04/87)
I have had a Performance Peripheral board (see Rainbow ad) for several months now, and it hasn't given me one lick of trouble (I use my CoCo3 several hours a day with the memory acting mostly as cache for a Wini disk, and it gets heavily exercised, so I'm sure the entire memory is good!). It appears to be professionally designed (i.e., solder mask in appropriate places, etc.) and appears to (still) be the lowest cost. I will grudgingly admit that the designer is a friend of mine, but I bought the board as a customer. -- -- Ira Baxter Microelectronics and Computer Technology Corporation / STP (512) 338-3795 3500 West Balcones Center Drive, Austin, Texas 78759
harmon@abvax.icd.ab.com (Larry Harmon) (08/04/87)
I bought a ram expansion board from Frank Hogg Laboratory about 6 months ago for $50 with no RAM. I populated the board with cheap 150ns, mixed manufacturer 256k chips and have had no (0) problems. The board came fully socketed, with caps and some terminating resisters installed. It is a well made board. Larry Harmon
pete@wlbr.EATON.COM (Pete Lyall) (08/05/87)
In article <5013@milano.UUCP> baxter@milano.UUCP writes: >I have had a Performance Peripheral board ...... >...... with the memory acting mostly as cache for a Wini >disk, Ira, Disk Cache, eh?? Can you elaborate on how it is implemented?? Is it only cached on the read side (writes go directly do disk for file system hardening)? Also, is the cache memory usurping precious system address space (probably not, if you're using the board...).. If not, how is it getting the memory for the cache allocated to the driver?? I believe that an OS9 F$srqmem will respond to a device driver's request with SYSTEM memory. You have my full attention.. I'd like to hack a similar goody into the GIMIX.. Pete -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
baxter@milano.UUCP (08/06/87)
In article <1107@wlbr.EATON.COM>, pete@wlbr.EATON.COM (Pete Lyall) writes: > Disk Cache, eh?? Can you elaborate on how it is implemented?? Is > it only cached on the read side (writes go directly do disk for > file system hardening)? Also, is the cache memory usurping precious > system address space (probably not, if you're using the board...).. If > not, how is it getting the memory for the cache allocated to the > driver?? I believe that an OS9 F$srqmem will respond to a device > driver's request with SYSTEM memory. You have my full attention.. I'd > like to hack a similar goody into the GIMIX.. > The cache is a really dandy replacement for a RAM disk. The major advantages are that you: a) Need not load up a RAM disk before you start using it b) Don't have copy files from other disks when you discover you need them c) Don't have think about what you do next d) Don't have to worry about losing a whole day's work because of a power blink. How does it work, you say? The cache is both a read- and write- buffering cache. I run it with about 300kb of the 512kb dedicated to the cache, so the last 1200 sectors (LRU: least recently used) are retained (which means practically everything I do). Read requests are first tested against the cache; if it has it, no disk I/O occurs. Whether a read occurs or not, the fetched sector is made "most-recently-used" (MRU), which is a hueristic indication of the likelyhood it will be needed again later. Sectors which have not been referenced implicitly age as other sectors are made MRU; the oldest sector is called the LRU. Writes to disk go instead to the cache unless it is full and the oldest stuff in it is dirty; in that case, the oldest dirty stuff is forced to disk and the new dirty stuff is dropped into the cache to maintain the MRU property. Writing to the disk is done in "segments", i.e., all dirty disk blocks with sequentially increasing sector numbers, up to a cylinder boundary, starting with the oldest dirty disk block, are written, so one seek gets rid of a lot of dirty stuff, really quickly. Both the floppy content and the Wini content are intermixable in the cache. It is great fun to work on the floppy: initially, there's lots of seeks... and they gradually fade away, as the "floppy" gets faster and faster. The cache is almost (within inches!) big enough to hold the entire content of two floppy disks without doing any I/O; in practice, it holds everything you work with. Who needs a hard disk (:-})? It even speeds up a hard disk system, radically in the case of lots of random I/O, and by a factor of about two when a process insists on reading one big file sequentially and writing another sequential file at the same time. When a 20 second "no disk requests to the OS" fuse expires, the cache dumps the oldest dirty segment, marks all the sectors in that segment as clean (retaining them in the cache), and continues doing that until everything in the cache is clean or a disk I/O request happens from an application or the OS, at which point the 20 second fuse is re-enabled. The effect of this is that the operators think time (or pure compute time of an application) is used to keep the file system up to date. The fuse almost always ensures that the cache contents are clean in any practical situation, which means writes are always virtually instantaneous. In 9 months of use, I have lost only a little bit... that's because I debug inside the OS and let programs run away once in awhile. In normal use, only a power fail before the 20 second fuse can get you, so it is really quite reliable. You can also force the cache to flush all the dirty stuff for a particular disk with a special system call (CC:DUMPBUFFERS) or a command interpreter DISMOUNT command. (This allows programs or users to express their paranoia about particular data). The DISMOUNT command is necessary when you switch floppy disks, or are about to turn off the machine and don't want to wait 20 seconds. When fuse-flushing, the disk head can jump about quite a bit if you have done lots of writes to random places on the disk recently, but this time is free anyway, and the idea is that it is most important to get rid of the oldest (i.e., most-probably-useless) stuff. The DUMPBUFFERS/DISMOUNT flush is different than the fuse-flush in that dirty segments are dumped in lowest-sector-number-to-highest order, which means the disk heads DON'T jump around... they simply sweep across the disk in cylinder-increasing order, dumping data as fast as the machine can write. It takes about 15 seconds to dump 300Kb of dirty cache to the Wini doing this; 160Kb of dirty floppy takes more like a minute, but it is done with verify (2 passes over every sector), and this NEVER happens in practice. Cache code does usurp precious system address space... about 1kb. Seems like a small price to pay for the performance it buys. There is zero effect on the max size of a user program; mine can be as large as $FE00 bytes in size. You do need to give it a lot of RAM (as I said earlier, I give it 300Kb), but I can still run two 65Kb processes, which is about all I can personally figure out how to use at one time anyway (i.e., some nasty compile in the background, running screen editor in the foreground). Now that your tongue is hanging on the floor I'm going to stomp on it. The bad news is that this cache is implemented for a little known operating system call SDOS, not OS/9, which I happen to like partly because I am the author of it; it is not commercially available on CoCos right now. Some other interesting quirks of the CoCo3 implementation of SDOS: a) Talks to any SCSI-compatible Wini (Up to 250 Mb) (two at once, if you want) b) It does provide a RAM disk, but I NEVER use (can't seem to find ANY advantages, but I couldn't resist implementing it; only took two pages of assembly code). c) It knows how to do decent floppy I/O: I can use the screen editor even when SDOS is flushing to the floppy, as it doesn't lock out the processor to disk I/O. Yes, it does this with the standard Radio Shack controller. d) Floppy I/O is fast: about 6Kb/second continuous read rate. Writes are ALWAYS verified, but are still pretty fast (1/2 the read rate), because the write process for a segment does WRITE/.../WRITE then VERIFY/.../VERIFY e) Floppy disk sizes of 170Kb, 360Kb, and 720Kb are all supported. The cache supports all of this junk. -- -- Ira Baxter Microelectronics and Computer Technology Corporation / STP (512) 338-3795 3500 West Balcones Center Drive, Austin, Texas 78759
pete@wlbr.EATON.COM (Pete Lyall) (08/07/87)
Ira -
Well .. you certainly *did* have my tongue hanging out, and you
certainly did stomp on it with the SDOS shot!
I did receive a promotional copy of SDOS and some literature a few
years back when I was an active coco'ist, but never bothered to call
in for the authorization codes because I was busy hacking all my old
Flex stuff over to OS9, and figured the last thing I needed was yet
another OS - no offense intended.. I did read the manuals, and was
suitably impressed. Perhaps it was my loss.
Are there any probabilities that this will be ported over to OS9-dom?
Personally, I rarely use the coco3, but I know there's a lot of folks
who'd just drool to get a product like that installed! The DMC
controller is allegedly also barking up that tree, but with
considerably smaller cache area (~8K).
Thanks for the detailed description.. it spawned a few more questions
though..
How do you time stamp your LRU/MRU sectors?? Do you keep a separate
data structure aside for disk/LSN/TIME, and update with a 6 byte time
packet? Do you keep this list sorted?
Also - what *is* the scoop on SDOS...? Available later on the CC3?
What platforms support it now?
Also - nice touch on the floppy I/O.. care to brag about your
technique (nudge.. nudge..)?
--
Pete Lyall
Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)jonh@tekgen.TEK.COM (Jon Howell) (08/09/87)
You're right, Pete--we'd LOVE that cache! Also, that nice effect of open key- board during disk access. Also, does that mean the chars show on the screen, or are just read? Jon -- ___ __ , __ __ _ , , __ , , ___ __ | |_ | |_ / / \ |\ /| |_\ | | | |_ | -- It's good for your | |_ |_ |_ \__ \_/ | V | | \_/ | |_ * health!
baxter@milano.UUCP (08/10/87)
In article <1109@wlbr.EATON.COM>, pete@wlbr.EATON.COM (Pete Lyall) writes: > > Are there any probabilities that this will be ported over to OS9-dom? Not in the short term. > ... The DMC > controller is allegedly also barking up that tree, but with > considerably smaller cache area (~8K). SDOS has always had a cache of 2-4Kb. It works reasonably well, but isn't anywhere the performance of the big cache we have been talking about. > How do you time stamp your LRU/MRU sectors?? Do you keep a separate > data structure aside for disk/LSN/TIME, and update with a 6 byte time > packet? Do you keep this list sorted? TIME STAMP? That's crazy. All you need is a relative time ordering, which a linked list does beautifully. > Also - what *is* the scoop on SDOS...? Available later on the CC3? > What platforms support it now? SDOS is available on CoCo2 standalone, CoCo2 with extended memory card (but a CoCo3 is cheaper than the pair), and sometime later on CC3. There are versions which run on SSB Cheiftans/VARs and EXORbus equipment, as well as several you-never-heard-ofs. > Also - nice touch on the floppy I/O.. care to brag about your > technique (nudge.. nudge..)? No. -- -- Ira Baxter Microelectronics and Computer Technology Corporation / STP (512) 338-3795 3500 West Balcones Center Drive, Austin, Texas 78759
jonh@tekgen.UUCP (08/15/87)
+>You're right, Pete--we'd LOVE that cache! Also, that nice effect of open key- +>board during disk access. Also, does that mean the chars show on the screen, +>or are just read? *Keyboard 'lockout' is ususally caused by the way the floppy controller *is set up and used. As delivered, the standard RS controller (and most *of the clones) are programmed to actually HALT the 6809 during data *xfer.. the only thing that gets the 6809 out of the loop is a NMI *(non-maskable interrupt), if I recall correctly. So, what does this mean? Can Level II read keyboard ahead well? Can the ACIA also be read ahead? (I will write a BBS when I get my copy of LII) Jon ---- --- -- ___ __ , __ __ _ , , __ , , ___ __ | |_ | |_ / / \ |\ /| |_\ | | | |_ | -- It's good for your | |_ |_ |_ \__ \_/ | V | | \_/ | |_ * health!
df1b+@andrew.cmu.edu (David R. Fulmer) (08/17/87)
In article <1607@tekgen.TEK.COM> jonh@tekgen.TEK.COM (Jon Howell) writes: >So, what does this mean? Can Level II read keyboard ahead well? Can the ACIA >also be read ahead? (I will write a BBS when I get my copy of LII) Well, I just bought a multipak for the CoCo III, and I have no problems using type-ahead at 19200 baud over the RS232 pak (as /T2). When I was using my Y-cable the interrupts from the RS232 pak got through and messed things up, giving me error #244 I believe (read error). The multipak doesn't pass the FIRQ signal though, so the problem is eliminated. I'm running around now trying to find R.S. stores that still have a RS232 pak or two lying around. I want to get 2-3 more! Dave Fulmer df1b+@andrew.cmu.edu (arpa) df1b+%andrew.cmu.edu@cmccvma (bitnet) ...!seismo!andrew.cmu.edu!df1b+
pete@wlbr.EATON.COM (Pete Lyall) (08/18/87)
Regarding coco3 level II and keyboard type ahead...
It's better than the cocoII, but disk access still whomps the
keyboard. Your best solutions here are:
a) Get a hard disk (most controllers buffer at the sector level, and
use simple loops to transfer the code into ram)
b) Get a Sardis (or Disto.. new) floppy controller.
c) Run completely out of RAM based modules (an option, but not
recommended).
--
Pete Lyall
Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)jimomura@lsuc.UUCP (08/18/87)
In article <1607@tekgen.TEK.COM> jonh@tekgen.UUCP (Jon Howell) writes: >+>You're right, Pete--we'd LOVE that cache! Also, that nice effect of open key- >+>board during disk access. Also, does that mean the chars show on the screen, >+>or are just read? >*Keyboard 'lockout' is ususally caused by the way the floppy controller >*is set up and used. As delivered, the standard RS controller (and most >*of the clones) are programmed to actually HALT the 6809 during data >*xfer.. the only thing that gets the 6809 out of the loop is a NMI >*(non-maskable interrupt), if I recall correctly. >So, what does this mean? Can Level II read keyboard ahead well? Can the ACIA >also be read ahead? (I will write a BBS when I get my copy of LII) Well, I have to disagree with the trend here. I don't like full cache for OS-9 systems. There are a *lot* of different approaches to speed and system integrity. Full read/write cache adds speed but at substantial risk of data loss and file corruption in the case of power failure or other hardware flakey failure. Thanks guys, but no thanks. Data integrity is too important for me to risk that. Read cache--which was done by TLM on the Atari ST OS-9 port was, in my opinion, the best compromise. Keep in mind that OS-9 allows you to *preload* object files. This is much more efficient than cache. Secondly, for datafiles, it's faster to throw intermediate files and reasonably small files into a RAM disk. If a file won't fit in, say a 512K RAM disk, a cache isn't likely to help that much either. A RAM disk has most of the same problems for data integrity as a cache, but at least you have an inherently better chance of retaining the "old copy" intact even if you lose the copy in RAM disk. A partially updated disk copy when the power goes down (or other "bad crash") is generally worthless. Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
blarson@castor.usc.edu (Bob Larson) (08/18/87)
In article <1997@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > Well, I have to disagree with the trend here. I don't like full >cache for OS-9 systems. There are a *lot* of different approaches to >speed and system integrity. Full read/write cache adds speed but at >substantial risk of data loss and file corruption in the case of power >failure or other hardware flakey failure. Thanks guys, but no thanks. >Data integrity is too important for me to risk that. Read cache--which >was done by TLM on the Atari ST OS-9 port was, in my opinion, the >best compromise. Keep in mind that OS-9 allows you to *preload* >object files. This is much more efficient than cache. Secondly, >for datafiles, it's faster to throw intermediate files and reasonably >small files into a RAM disk. If a file won't fit in, say a 512K RAM >disk, a cache isn't likely to help that much either. A RAM disk has >most of the same problems for data integrity as a cache, but at least >you have an inherently better chance of retaining the "old copy" intact >even if you lose the copy in RAM disk. A partially updated disk copy >when the power goes down (or other "bad crash") is generally worthless. The chance of data lost between writing a properly designed disk cache and the flush to real disk should be extremly small. If I were designing one from scratch to go in a new OS, I would have the write to disk cache automaticly schedule the disk write with lower priority than a normal disk read. If the write had not completed in a reasonable about of time (10 sec or so) the priority should be raised. (Disk writes would happen when the disk would otherwise be idle unless the disk was being heavily used.) Explicit tempory files would be a nice idea to add to disk cache. They should only be written to the physical disk if there isn't enogh room in the cache. (Hopefully in such a way the space would be automaticly recovered on a reboot after a crash.) I consider ram disks a horrible cluge. They can only be used for explicitly temporary files or copies of perminant files. They do not automaticly change their contents based on what is being done. My ram disk on my qt+ is a source of problems: it's big enough to get in the way of memory intensive programs, but not big enough to hold the temporary files created by the c compiler on some programs. (I use a 128kbyte ram disk -- 512 kbytes ram on my system.) Bob Larson Arpa: Blarson@Ecla.Usc.Edu Uucp: {sdcrdcf,seismo!cit-vax}!oberon!castor!blarson "How well do we use our freedom to choose the illusions we create?" -- Timbuk3
rph@chp.UUCP (08/20/87)
In article <1997@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > Well, I have to disagree with the trend here. I don't like full >cache for OS-9 systems. There are a *lot* of different approaches to >speed and system integrity. Full read/write cache adds speed but at >substantial risk of data loss and file corruption in the case of power >failure or other hardware flakey failure. Thanks guys, but no thanks. >Data integrity is too important for me to risk that. Read cache--which >was done by TLM on the Atari ST OS-9 port was, in my opinion, the >best compromise. Keep in mind that OS-9 allows you to *preload* >object files. This is much more efficient than cache. Secondly, >for datafiles, it's faster to throw intermediate files and reasonably >small files into a RAM disk. If a file won't fit in, say a 512K RAM >disk, a cache isn't likely to help that much either. A RAM disk has >most of the same problems for data integrity as a cache, but at least >you have an inherently better chance of retaining the "old copy" intact >even if you lose the copy in RAM disk. A partially updated disk copy >when the power goes down (or other "bad crash") is generally worthless. > >Cheers! -- Jim O. Humph. I've been running full R/W caching 24h/day for a year now and haven't had any problems. The cache typically clears out within less than half a minute of disk activity finishing, and if I'm about to test some dangerous program, I manually flush the cache (some kind of manual cache-flushing has to be provided anyway for when you want to change disks). I haven't had any kind of disaster that I couldn't fix with DCHECK. I write stuff in C and ASM and haven't yet lost a file. I used my extra RAM here as a ramdisk before. I find R/W caching much faster and trouble-free. For C, for example, the edit-compile-test cycle simply became shorter (admittedly I have only 32k to use for ramdisk/caching; with bigger memory sizes a ramdisk might be faster). -- Pontus Hedman {utzoo|utgpu}!chp!rph
jimomura@lsuc.UUCP (08/23/87)
In article <1987Aug19.210404.455@chp.uucp> rph@chp.UUCP (Pontus Hedman) writes: > >In article <1997@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >> Well, I have to disagree with the trend here. I don't like full >>cache for OS-9 systems. There are a *lot* of different approaches to >>speed and system integrity. Full read/write cache adds speed but at >>substantial risk of data loss and file corruption in the case of power >>failure or other hardware flakey failure. Thanks guys, but no thanks. >>Data integrity is too important for me to risk that. Read cache--which >>was done by TLM on the Atari ST OS-9 port was, in my opinion, the >>best compromise. Keep in mind that OS-9 allows you to *preload* >>object files. This is much more efficient than cache. Secondly, >>for datafiles, it's faster to throw intermediate files and reasonably >>small files into a RAM disk. If a file won't fit in, say a 512K RAM >>disk, a cache isn't likely to help that much either. A RAM disk has >>most of the same problems for data integrity as a cache, but at least >>you have an inherently better chance of retaining the "old copy" intact >>even if you lose the copy in RAM disk. A partially updated disk copy >>when the power goes down (or other "bad crash") is generally worthless. >> >>Cheers! -- Jim O. > >Humph. I've been running full R/W caching 24h/day for a year now and haven't >had any problems. The cache typically clears out within less than half a minute >of disk activity finishing, and if I'm about to test some dangerous >program, I manually flush the cache (some kind of manual cache-flushing >has to be provided anyway for when you want to change disks). Exactly. You have to flush the cache manually on occasion anyway. For some people that won't be often. For floppy users and small hard disk/floppy systems (which are the *most* common for OS-9 systems) it's more often. I note that the people who have been commenting on my previous posting have not addressed the Read cache but seem to think the only thing I talked about was RAM disk. Guys, have you even *tried* read cache without write cache with RAM disk? And then there's the *size* of the RAM disk. My Atari 1040ST RAM disk was 360K and for a while my QT was 512K RAM disk. My QT is back down to 128K now due to a memory card failure. In fact, when I get my memory card fixed I might go as high as 1 Meg. RAM Disk. It's hard to say. The half Meg. was fine for most things. I'm just thinking about what size I'll need when I start getting large databases up. 32K and 128K are pretty pointless really. >I haven't had any kind of disaster that I couldn't fix with DCHECK. Probably due to clean living. :-) Personally, I've had the following over the last year or so: 2 floppy drives went bad last winter due to power outages (along with a power supply) with disks lunched along for the ride. Power outages killed the RAM probably about a dozen times over the year (mostly 1 sec. range power drops--I suppose I should have bought a UPS by now, but I haven't and I mean only the contents of the RAM while the computers survived). I've also had a hard disk show signs of read/write failure due to overheating (this was the Supra on the Atari ST whereas the above problems were on the CoCo3) and also an Atari SH204 hard drive is not dead and in for repair, most likely due to media failure. The power outages haven't generally hit the QT/ST setup as hard as the CoCo3. I think the reserve capacitance seems to cover a bit over 1 sec in these two machines. I've found situations where the CoCo3 had reset and the ST and QT had survived with RAM intact. I've only had the ST for a year or so and the QT for about 1/2 a year so I'm just getting a feel for them. So far though I've only lost RAM contents in the QT a couple of times due to power drops. Still, it happens. Now, you say you've never lost critical data. That's a matter of straight percentages. As you note, the longest time between the system write call and the actual write for you is about 1/2 minute. Let's say it's typically 10 seconds (not an unusual mean time for some systems although 2 - 4 seconds mean time is also possible depending on usage patterns and the scheme used). If you have critical writes 100 times a day (pretty low for a business system) then you can figure the percentage of critical writes per day and then figure out the odds of hitting a critical write with power failure. It's pretty low. But what's low may not be small enough for someone else. It depends on what you're doing. It also depends on how much of a gambler you are. I'm just not that much of a gambler. >I write stuff in C and ASM and haven't yet lost a file. Obviously I have. >I used my extra RAM here as a ramdisk before. I find R/W caching >much faster and trouble-free. For C, for example, the edit-compile-test >cycle simply became shorter (admittedly I have only 32k to use for >ramdisk/caching; with bigger memory sizes a ramdisk might be faster). -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
rph@chp.UUCP (08/25/87)
Before I start blathering, I'll just give my bottom line here at the top for those who otherwise would never see it: o Ramdisks are nice if you have piles of memory. o Caching is nice and doesn't need piles of memory. o It's nicest to use both at once. o As for the caching, personal experience has shown me that it doubles disk write throughput and doesn't cause reliability problems despite my endless crashing. Now for the blathering: In article <2004@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >In article <1987Aug19.210404.455@chp.uucp> rph@chp.UUCP (Pontus Hedman) writes: >>... The cache typically clears out within less than half a minute >>of disk activity finishing, and if I'm about to test some dangerous >>program, I manually flush the cache (some kind of manual cache-flushing >>has to be provided anyway for when you want to change disks). > > Exactly. You have to flush the cache manually on occasion anyway. >For some people that won't be often. For floppy users and small hard >disk/floppy systems (which are the *most* common for OS-9 systems) >it's more often. I run OS9 Level 1 with two 500k floppies... I've found caching is very useful for it. Flushing the cache (by typing "unmount") is no big deal, and 80% of the time unnecessary because it's already gotten flushed automatically in idletime. I think what really matters is that with R/W caching, you stick in a disk, edit/whatever a file, type "unmount" after which everything will be safely sitting on disk. Total time, 30s. Without the write caching, the drivers thrash about doing unnecessary writes (by a factor of 2-3; I did tests) and although you don't need to type "unmount", your total work time becomes 60s. Btw if you don't do any more writing the blocks will automatically get flushed anyway and you won't need to type unmount - when the disks stop spinning you're safe. >Guys, have you even *tried* read >cache without write cache with RAM disk? And then there's the *size* >of the RAM disk. My Atari 1040ST RAM disk was 360K and for a while >my QT was 512K RAM disk. I tried ramdisk first, then I tried read-only caching. Can't do both (snif). I have 32k of non-OS9 memory which makes for an all but useless RAM disk - but it makes one heckuva good cache. The read caching worked wonders for file access but I still noticed that writes were really pathetic and that's why I added write caching. I'd never go back to read-only caching. >>I haven't had any kind of disaster that I couldn't fix with DCHECK. > > Probably due to clean living. :-) Personally, I've had the following >over the last year or so: 2 floppy drives went bad last winter due to >power outages (along with a power supply) with disks lunched along for >the ride. I assume those disks that got lunched were not write cached? If so it should be apparent that your disks will get wrecked whether write cached or not :-). > I've also had a hard disk show signs of read/write failure due to >overheating (this was the Supra on the Atari ST whereas the above problems >were on the CoCo3) Ah now THAT is the most significant problem with write caching! When it comes time to flush a block and you find that the block won't write, what should the driver do...? Mine currently ignores the error (BOO HISS BOO). I do get to hear the drives rattling and then I get to try to guess what recently-written file has gotten munged. But ah well, write failures happen no matter what. There are far fewer physical writes with caching which reduces disk wear so I guess that makes up for it. > Now, you say you've never lost critical data. That's a matter >of straight percentages. As you note, the longest time between the >system write call and the actual write for you is about 1/2 minute. > Let's say it's typically 10 seconds (not an unusual mean time for >some systems although 2 - 4 seconds mean time is also possible >... >[w.out write cache] figure out the odds of hitting a critical write with >power failure. It's pretty low. But what's low may not be small >enough for someone else. It depends on what you're doing. It also >depends on how much of a gambler you are. I'm just not that much of >a gambler. I'm not sure what a "critical" write means here; for me it means a file descriptor sector or LSN 0. I gathered statistics on this when doing the caching (by hanging hooks into the driver to note block access)... without write caching, those blocks are constantly getting written out. With write caching, the FD sectors tend to get written out only when the file is all updated and closed and left alone. When your computer dies with write files open those files are pretty well guaranteed to be messed up anyway. With the write caching, when I fix up the disks I usually end up with the filesystem the way it was 10 seconds *before* the crash, which I kinda like. Not much I can say except "works for me". My machine runs a BBS 24h/day and used to run read caching only. Then I added write caching. It's just quieter and faster and wears out disks less due to less seeks. The machine has lousy memory so it crashes incessantly but I don't lose files. -- Pontus Hedman {utzoo|utgpu}!chp!rph
knudsen@ihwpt.ATT.COM (mike knudsen) (08/31/87)
In article <420@ea.ecn.purdue.edu>, mckay@ea.ecn.purdue.edu (Dwight D Mckay) writes: > > The Microware release of OS9 for the Atari ST has variable read-caching for > floppies. It makes a big difference in speed. > This release of OS9 also comes with a RAM disk. > A meg. of memory is nice to work with! I'm glad I sold the Coco... Could you answer us some questions about the latest ST OS9? Is your version from the bankrupt comany or straight from Microware? Any improvements since Mware took it over? Specifically I'd like to know what the ST version has in the way of graphics (ie, decent user interfaces to the ST's power) and "does it do windows?" Does the C compiler still cost $400? I've hoped that Mware would transfer its work on windows and graphics for the Coco-3 to the ST. Have/will they? BTW, can you have programs bigger than 64K (not incl data) on the ST? I've heard that position-independent relative branches in the 68000 can only cover 64K. Say it isn't so. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
mckay@ea.ecn.purdue.edu (Dwight D Mckay) (09/01/87)
In article <1949@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: > >Could you answer us some questions about the latest ST OS9? Sure. I purchased the "professional" version of OS9 for the ST directly from Microware. >Any improvements since Mware took it over? Yes. It's the latest release of OS9/68000 (2.1). It's supposed to be better documented as well. I have not seen the TLM release, but I am very pleased with what I have. >Specifically I'd like to know what the ST version has in the way >of graphics (ie, decent user interfaces to the ST's power) >and "does it do windows?" Nope. No windows, yet. Microware plans to offer a window manager called "Invision" late this year or early next year. That's what the Microware folks on CIS say, anyway. >Does the C compiler still cost $400? Don't know. C compiler comes with the $600 "professional" package. > I've hoped that Mware would transfer its work on >windows and graphics for the Coco-3 to the ST. Have/will they? See above. >BTW, can you have programs bigger than 64K (not incl data) >on the ST? I've heard that position-independent relative >branches in the 68000 can only cover 64K. Say it isn't so. Yup. It's a compiler option in the C compiler. "-k0l" gives you 32 bit offsets. --Dwight Mckay, ECN Workstation Software Support [arpanet: mckay@ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay] [Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561]