Path: utzoo!attcan!uunet!husc6!bloom-beacon!spdcc!eli
From: eli@spdcc.COM (Steve Elias)
Newsgroups: comp.sys.ibm.pc
Subject: pc cache programs
Message-ID: <1311@spdcc.COM>
Date: 15 Jun 88 00:38:45 GMT
Reply-To: eli@spdcc.UUCP (Steve Elias)
Organization: why?
Lines: 29

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.