Shareware Supreme Volume 6 #1

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Supreme Volume 6 #1 / swsii.zip / swsii / 165 / MEMCACHE.ZIP / CACHE

Wrap

Text File | 1989-01-02 | 17KB | 347 lines

Dave Williams PO Box 181 Jacksonville, AR 72076-0181 USA I had seen cache software around before, and indeed had tried some of it, but that was back in the days when I was running a PCjr with one floppy and a 360k RAMdisk and could ill afford the overhead of caching software. After that, I didn't worry much about it as I moved up from the jr to a turbo XT and then to a turbo AT. Then I wound up getting involved in several similar discussions on DOS buffers and caching on several different boards within a couple of days, culmninating in a friend calling me in the middle of the night and babbling about how wonderful PC-Tools' cache program was. For some reason, I took all this as an omen that maybe I had better take a deeper look into this stuff. I blew the dust off a box of floppies and scrounged up the following programs, which I tested that night and the next day. This is the results. I also found a couple of articles by Barry Simon and some adware from PC-Kwik that had some useful into and threw the whole mess into the archive. Dave System: 12mHz AT, 1 wait state, tweaked DMA refresh, 8-bit RAM. Landmark Speed 12.6mHz. Okidata RLL half height hard disk, OMTI controller, 34 meg. Formatted to a 490k C: drive and a 16meg D: and E: drive under PC-DOS 3.3. 8-bit controller (The RAM and hard drive came from my old XT). Golden Bow's VSEEK says 109msec for the hard drive, which is rated at 65msec. CoreTest just sneers at it. This is a SLOW drive! I don't remember if the interleave is 2 or 3. Running IBM PC-DOS 3.3, with my usual assortment of TSRs and device drivers. A 240k extended memory VDISK was set up, leaving 144k for the cache's use. Testing: Hard disk was optimized with Golden Bow's VOPT before testing. For each test the system was warmbooted with the appropriate number of buffers in CONFIG.SYS and the PC-Cache string was REMmed out of the autoexec file when required. A public domain program timer called TME.EXE was used for time the execution of each repetition. After the warmboot, TME was copied to the RAMdisk, which was first on the path. No changes were made to the hard drive other than to the CONFIG.SYS and autoexec files. The DOS 3.3 CHKDSK command was selected as an appropriately disk- intensive program. Four reps of CHKDSK and four reps of CHKDSK /V were run with each configuration with TME timing execution. PC-Cache was interrogated between reps when used; it reported the current hit rate on the cached sectors. I feel that conditions were adequately controlled during each test. COPY \ut\tme.exe f: was always the first command after booting, TME CHKDSK was always the second to prevent preloading the cache differently each time. Sitting around waiting for this stuff to run, rebooting, running, rebooting..... is enough to drive you crazy. Program: Shareware PC-Kwik by Multisoft SPCKWIK v 2.2 command line: no parameters used SPCKWIK.COM 15395 5-04-88 12:00p cache buffers command times ----- -- ------- ------------------------- none 15 chkdsk 2.97 2.91 2.91 2.91 chkdsk/v 8.90 8.90 8.90 8.90 209k 3 chkdsk 2.25 .88 .88 .93 duh, forgot to chkdsk/v 7.03 6.98 6.98 6.98 check. 92k 3 chkdsk 2.04 .93 .93 .93 66% 80% 86% 89% chkdsk/v 7.03 7.03 6.98 6.98 91% 92% 93% 94% no disk access after first read, all 7 subsequent reads came right out of the cache. This version evidently works; it also stacks up with the best of them. Definitely worth trying if you didn't want to spend money on caching software right at first. limited SPCKWIK to 92k by loading multiple copies of COMMAND.COM to suck up space. automatically took 180k, leaving 360k for applications. I downloaded a different version of Shareware PC-Kwik 1.07 from a board a thousand miles away from the first and got the same errors. 1.07 evidently doesn't work, or doesn't work with DOS 3.3. Program: Discache Disk-Cache v0.01 command line: DISCACHE /E:144 /D:D /D:E DISCACHE /M:64 /D:D /D:E DISCACHE.EXE 11-12-86 8:29a RESPRO 1.2 reported no RAM used Discache reported "error reading drive D" (or E, F, A, or C) when tried. The documentation was well-written, there was talk of a distribution disk and no shareware notice, so I assume it is a pirated copy. Since it was dated 1986, I am assuming it didn't load because it didn't like my DOS 3.3 or the 3.3- FDISked triple-extended-DOS-partition weird hard disk. It did not install anything resident. Since the docs specified it would work with conventional, extended, expanded, or any combination of them, it looked veeery interesting. Might try loading it on a different machine. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Partway through testing all this stuff, I got my twin 20 meg AT drives back online. These had been on-again, off-again due to controller troubles inmy 12mHz machine. The drives are CMI drives out of real IBM ATs, with a Western Digital 1003-WA2 controller. Low level format was done with Everex Format, drive 0 is partitioned into 2 logical drives, a 360k and 1 21 meg, and drive 1 is one 21 meg. Interestingly, DOS considers both primary partions, then all logical partitions. C is on drive 0, D is drive 1, and E is drive 0. The 34 meg RLL drive that the other testing was done on was backed up with PKARC and then restored to the two drives, maintaining the same three logical drives. Golden Bow's VSEEK reports drive 0 at 43 milliseconds and drive 1 at 38 milliseconds, both within the rated limits of the docs I have on them. Bear in mind that except for being rammed along at twice the bus speed of an AT, this is all True Blue hardware. I had also just downloaded a nifty little utility in the form of ILEAVE16.ARC. It checks the interleave of your disk (it reported the interleave of 2 I told Everex to use) and lets you format a track with different interleaves to see which works the best. The results were: interleave msec 1 40 obviously the WD-1003-WA2 doesn't do buffering 2 5 <--- optimum interleave (on my system anyway) 3 8 IBM's standard interleave for the AT 4 10 5 13 6 15 7 17 Apparently my "look and feel" method of guessing the proper interleave worked in this case. Or it was just dumb luck. none 15 chkdsk 1.87 2.03 1.98 2.03 chkdsk/v 7.31 7.30 7.31 7.30 This is considerably faster than the fastest cached tests on the other drive! Obviously there ain't no substitute for hardware -- Lightning and Super PC- Kwik could beat it on multiple reads, but the first repetition is always faster with the faster drive. PC-Cache (extended memory) 144 3 chkdsk 1.87 1.87 1.87 1.86 29% 30% 30% 30% chkdsk/v 7.14 7.19 7.14 7.25 30% 30% 30% 30% This is interesting too... PC-Cache claims a 30% hitrate, but the access times aren't dropped much. Not a lot of results for a 144k cache now. PC-Cache (extended memory) 144 15 chkdsk 2.14 2.30 2.14 2.15 3% 4% 4% 4% chkdsk/v 7.31 7.31 7.30 7.31 3% 3% 3% 3% Yep, adding more buffers slowed the beast down. The algorithm used by PC- Cache probably waits for DOS to check its buffers first. That's the only way I can account for the abysmally low hitrate. Also notice the tighter time groupings on this CMI drive over the Okidata unit used in the other tests. At this point, caching doesn't really look worthwhile for the fast hard drive. Since PC-Cache is set up to use extended memory for the cache, I developed a working hypothesis that perhaps the cache itself isn't much faster than the hard drive. The AT has to save everything, switch to protected mode, grab a couple of bytes, then do what amounts to a sort of warmboot back into real mode. I had noticed that VDISK in extended memory seemed slower than a RAMdisk in my old expanded memory card. So for maximum fairness, let's try a 144k conventional memory cache with the same software: PC-Cache (conventional memory) 144 3 chkdsk 1.87 1.82 1.87 1.87 30% 30% 30% 30% chkdsk/v 7.09 7.09 7.09 7.03 30% 30% 30% 30% Yep, a small performance increase. Nothing to write home about though. Well, maybe Lightning can make some numbers like it did on the other drive.... Lightning 144k 3 would not complete boot 128k 3 would not complete boot 120k 3 would not complete boot booted off a floppy, then set up for a 64k cache (no TSRs, no nothing, DOS 3.3 defaults to 15 buffers). Loaded OK, but gave a bunch of "Invalid subdirectory entry. Convert to file Y/N?" terror messages. Control-C and reboot out, the disk was OK according to CHKDSK afterward. So no real comparison between the two programs yet. Message #521. 9-05-88 13:35.34 From: Tom Currie To: James Davis Subject: INTERLEAVE You're certainly right that if the interleave factor is correct to start with changing it can only hurt access times. However a lot of hard disks are running an incorrect interleave. There are programs that can check the interleave, but I haven't HEARD of one that will perform reliably in a multitasking environment -- every one that I have seen or heard about specifically directs that it be run without multitasking and generally without TSRs. I don't KNOW that it would or wouldn't make any difference. One fact however is that the worst likely interleave is essentially one level too tight! If and interleave of 5 is correct, and interleave of 4 is a disaster but an interleave of 6 has only a minor impact. In my case, for example, with an ST-238 running in RLL on a 8MHz PC Clone: INTERLEAVE REVOLUTIONS AVERAGE DATA FACTOR PER TRACK READ THROUGHPUT --------------------------------------------------------- 1:1 26 30,706 2:1 27 29,562 3:1 28 28,522 4:1 22 - 26 33,280 5:1 5 159,744 6:1 6 133,120 7:1 7 114,088 8:1 8 99,840 Obviously the correct interleave is the best way to go. On my setup however you can note that occasionally it succeeds in reading the next sector at a 4:1 interleave (thus the variation in the revolutions required to read a full track). Setting the interleave one sector too loose add the disk rotation time of one sector to the sequential access time. Setting the interleave one sector too tight adds one full rotation minus one sector to the sequential access time. It is one of those simple situations, the correct interleave is definately the way to go (as you said), but IF YOU ARE GOING TO MAKE A MISTAKE it is a lot better to err in favor of being too loose rather than too tight. ╔════════════╗ ║ Tom Currie ║ ╚════════════╝ .ORIGIN: 010/002 - SOFTSTONE BBS * 502-241-4109 * LOUISVILLE KY * CURT EDWARDS C Message #524. 9-08-88 15:21.14 (NO KILL) From: David Williams To: Scott Cushman Subject: INTERLEAVE ALSO SEE: 519. The original IBM PCs had some problems writing to the original 10 meg hard drives - DOS doesn't do much buffering on data, the controller did none at all, and the hard disk was faster than the machine's CPU. An interleave of 1:1 means sectors on the hard disk are written one after the other, just like on a floppy. Imagine a pizza. You go from one slice to the adjacent slice. That's 1:1. A 2:1 interleave means that you skip every other slice. 1-3-5, etc. As far as DOS sees, though, they're all still adjacent. The interleave is on a lower level than DOS. An interleave of 5:1 means 1-5-10, etc. The interleave is used to match the data transfer rate of the hard disk to the transfer rate of the bus. For example, with a 1:1 interleave, most machines aren't quick enough to read all the sectors in a row. The CPU has to wait for the second slice to come back around again, magically changing your 1:1 interleave to an effective 18: (the standard MFM hard disk has 17 sectors). Setting the interleave too wide has less of a performance penalty than setting it too low. Waiting 1 or 2 sectors for the next logical sector is a lot better than waiting a dozen or more for it to swing back by because you didn't quite pick it up the first time. A program called ILEAVE16.ARC can detect your interleave and then recommend an optimum interleave for your system. In my case, an interleave of 1:1 resulted in 40ms to access the next sector. An interleave of 2:1 dropped it to 5ms. 3:1 moved it up to 8, etc. The original IBM PCXT interleave was 5 or 6, I forget which. IBM took a lot of criticism when people found that they could drop the interleave to 4 and sometimes 3 without problems.... but the original PC ran DOS 2.0, buffers defaulted to 3, and had 256k. Later ones came with DOS 2.1 or 3.1, people learned to use buffers in their config.sys file, and usually had memory upgrades (to make more buffers practical). The original interleave was pretty well correct for the machines as delivered, though. ■■ Dave Williams ■■ Techno-Geek Extraordinaire ■■ Cruisin' USA on PCP! ■■ From: SYSOP To: DAVE WILLIAMS Subject: The Joy Of Spinrite (Reply to Message #5630) Did I lock out ZOO files? I'll have to fix that. I know I locked out .EXE, .COM, and .BAS files, but may be allowing .EXE files in just because that's the way Phil likes to distribute PKARC. I've played with caching a bunch, but I'm a bit leery of it at the moment. My Maxtor has a built in speaker that gives off messages just like the encoded beeps of an AT. Right now I'm getting several "sirens" per day out of it, and it all started when I began playing around with a 1M cache in EMS memory. No, I'm not really superstitious, but I've disabled that cache and backed up like crazy. Oh man, if that disk goes the Night Modulator is going to become a small time backwater BBS again. Any idea what those sirens mean? I've been trying to figure it out and can't, it isn't in the hardware manual for that disk. Message #5639 Dated 09-08-88 @ 07:40. (Logged Section: All) From: JEFFREY ZIMMERMAN To: SYSOP (Received: on 09-08-88 @ 08:37:52) Subject: The Joy Of Spinrite (Reply to Message #5589) I'm no expert, by a lonnnnnnnnnnnnng shot, but I suspect that an AT can handle the processing time a bit faster than an XT. It's one place where a faster processer DOES make a difference. My experience finds a significantly faster performance withOUT the cache, as long as I keep my disk tuned. (Where is that memo on Spinrite ... must call those people!) Message #5648 Dated 09-08-88 @ 08:43. (Logged Section: All) From: SYSOP To: JEFFREY ZIMMERMAN Subject: The Joy Of Spinrite (Reply to Message #5639) I've always gotten better performance WITH a cache, but only if it was a relatively big one. 400K seemed just about right for running the BBS. A cache can slow you down if it's size and the typical data blocks you use don't fit well. Making the cache too big imposes a small average penalty on all reads while the cache is being searched, but big speed gains on a high percentage of reads. Since my hard disk is still making 'siren' ooises even though I've disabled the EMS cache, I'm forced to conclude that something else is causing it. I'm going to call Maxtor this morning. The phone number for Gibson Research (Spinrite) is (714) 830-2200.