eli@spdcc.COM (Steve Elias) (06/14/88)
i've benchmarked the Compaq disk cache on my 10 MHz ALR at and the results seem to stink... i'm using 384k of extended memory as cache... the result is that using the cache actually slows the machine down. the disk drive is not fast, either: 40 ms st251... i believe that this can be accounted for by the bios calls necessary to switch into and out of protected mode. the overhead must be slowing the cache access down... any comments ??
iverson@cory.Berkeley.EDU (Tim Iverson) (06/15/88)
In article <1304@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: >i've benchmarked the Compaq disk cache on my 10 MHz ALR at and >the results seem to stink... i'm using 384k of extended memory >as cache... the result is that using the cache actually slows the >machine down. the disk drive is not fast, either: 40 ms st251... > >i believe that this can be accounted for by the bios calls necessary >to switch into and out of protected mode. the overhead must be slowing >the cache access down... any comments ?? Before you can decide whether it is in fact the bios block move calls or not, you would have to know the hit rate on your cache. At 6Mhz, the bios block move call can move 512B (the most common sector size) in about 1ms. Since your drive's latency is 40ms, this might suggest that it is the cache implementation and not the extended memory transfer. If the cache tries to do something moderately fancy like read-ahead, and you're not accessing sectors sequentialy (sectors, not file records - a sequentialy accessed file on dos is not guarenteed to result in requests for sequential sectors on the disk) then performance could indeed be very bad since each read would induce several other totaly useless read-aheads - thus reducing the hit rate on the cache. My guess would be that whoever wrote the cache wasn't really up to doing a good job. - Tim Iverson iverson@cory.Berkeley.EDU ucbvax!cory!iverson
eli@spdcc.COM (Steve Elias) (06/15/88)
actually, the cache does fine in improving dos command mode, but i'm more interested in speeding up nazty compile/link cycles. it does speed up reads, but can slow writes. the writebacks end up slowing the machine down, especially when it's forced to somersault into protected mode... i'd try using base memory for cache, but the bonehead compiler takes 490k. i should try desqview or doubledos... CDOS can't cut these compiles, even if it is the caddilac of multitasking DOS systems... ! In <3928@pasteur.Berkeley.Edu> iverson@cory.Berkeley.EDU.UUCP (Tim Iverson) writes: >Before you can decide whether it is in fact the bios block move calls or >not, you would have to know the hit rate on your cache. At 6Mhz, the bios >block move call can move 512B (the most common sector size) in about 1ms. >Since your drive's latency is 40ms, this might suggest that it is the cache >implementation and not the extended memory transfer. If the cache tries to >do something moderately fancy like read-ahead, and you're not accessing >sectors sequentialy (sectors, not file records - a sequentialy accessed file >on dos is not guarenteed to result in requests for sequential sectors on the >disk) then performance could indeed be very bad since each read would induce >several other totaly useless read-aheads - thus reducing the hit rate on >the cache. My guess would be that whoever wrote the cache wasn't really >up to doing a good job. i'd rather have expanded memory for cache... or a roadrunner. beep beep.
nelson@sun.soe.clarkson.edu (Russ Nelson) (06/15/88)
In article <1304@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: >i've benchmarked the Compaq disk cache on my 10 MHz ALR at and >the results seem to stink... i'm using 384k of extended memory >as cache... the result is that using the cache actually slows the >machine down. the disk drive is not fast, either: 40 ms st251... > >i believe that this can be accounted for by the bios calls necessary >to switch into and out of protected mode. the overhead must be slowing >the cache access down... any comments ?? Maybe not. It might depend on your BUFFERS= settings: Clarkson University Potsdam, NY 13676 John Dvorak PC Magazine One Park Ave. New York, NY 10016 Dear John: In the April 12, 1988 PC Magazine (V7N7) Inside Track column, you mention that your disk cache works better without any BUFFERS statement in your config.sys. You piqued my curiosity, so I wrote an autoexec.bat file that would run chkdsk three times and take the average. Here are the details: Zenith Z-386 (16 Mhz, no memory cache) Zenith's MS-DOS 3.21 Zcache using 1 Meg of extended ram 32 Meg Hard Disk w/ 28 ms average seek time. The numbers: Buffers Time in hundreths 1 728 2 423 3 316 4 247 5 236 6 238 7 239 8 240 9 252 10 247 11 261 12 258 13 267 14 265 15 274 16 278 17 280 18 289 19 289 20 300 21 297 22 308 23 308 24 311 25 322 -- signed char *reply-to-russ(int real_network) { /* Why can't BITNET use */ if (!real_network) return "NELSON@CLUTX"; /* TCP/IP? */ else return "nelson@clutx.clarkson.edu"; }