ldstern@rodan.acs.syr.edu (Larry Stern) (04/13/91)
To all: I've been told that creating a drive D with ramdrive.sys and loading command.com there (ie. setting comspec=d:\command.com) will increase overall performance and speed. Any comments? P.S. I use a 286 AT clone, 640K base and 384K extended memory. Thanks, Larry Stern -- Larry Stern LDSTERN@RODAN.ACS.SYR.EDU
cs352a41@cs.iastate.edu (Adam Goldberg) (04/14/91)
ldstern@rodan.acs.syr.edu (Larry Stern) writes: >To all: I've been told that creating a drive D with ramdrive.sys and loading >command.com there (ie. setting comspec=d:\command.com) will increase overall >performance and speed. Any comments? >P.S. I use a 286 AT clone, 640K base and 384K extended memory. I have exactly the same configuration, and I do what Larry suggests. Performance increase comes only when loading COMMAND.COM ... ie, exiting programs or spawning a dos shell from within a process. Admittedly, this isn't a great speed-up, but I haven't any easy way to use my upper 384K for anything else. Speaking of which, anyone have any ideas what I could do (for free) to utilize my 384K better than a Ramdisk? -- +-----------------------------------------------------------------------------+ ! Adam Goldberg ! * ! "It's simple! Even a PASCAL ! ! cs352a41@cs.iastate.edu ! * ! programmer could do it!" ! +-----------------------------------------------------------------------------+
c60b-1eq@e260-1c.berkeley.edu (Noam Mendelson) (04/14/91)
In article <1991Apr12.192526.23566@rodan.acs.syr.edu> ldstern@rodan.acs.syr.edu (Larry Stern) writes: >To all: I've been told that creating a drive D with ramdrive.sys and loading >command.com there (ie. setting comspec=d:\command.com) will increase overall >performance and speed. Any comments? >P.S. I use a 286 AT clone, 640K base and 384K extended memory. Yes, it should increase overall performance in two respects: (a) when you shell to DOS (another copy of COMMAND.COM has to be loaded); (b) when you're executing COMMAND.COM's intrinsic commands. Situation (b) is less common but it does exist since COMMAND.COM only loads about 5K of itself into low memory and accesses the original COMMAND.COM when necessary. So, to answer your question, yes it does. But I'm sure that you could find better ways of utilizing a 384k RAM disk. Putting COMMAND.COM there is just a generic way of improving performance. You might consider setting some of your programs' 'temporary directories' to the RAM disk (provided you have enough room). That is a much better way to improve a program's performance. One other alternative is an extended memory disk cache. That will improve overall performance, but it may require you to surrender some of your conventional memory. -- +==========================================================================+ | Noam Mendelson ..!agate!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
jdwhite@iastate.edu (White Jason David) (04/14/91)
In article <cs352a41.671590865@zippy> cs352a41@cs.iastate.edu (Adam Goldberg) writes: [...] >Admittedly, this isn't a great speed-up, but I haven't any easy way to use >my upper 384K for anything else. Speaking of which, anyone have any ideas >what I could do (for free) to utilize my 384K better than a Ramdisk? >-- Yes, set it up as a disk cache. You'll love the difference in access time. This is, of course, assuming you have a hard disk. Jason White // jdwhite@iastate.edu // "Get bent!" - Bart Simpson
ldstern@rodan.acs.syr.edu (Larry Stern) (04/16/91)
In article <1991Apr14.022004.9023@news.iastate.edu> jdwhite@iastate.edu (White Jason David) writes: >In article <cs352a41.671590865@zippy> cs352a41@cs.iastate.edu (Adam Goldberg) writes: >[...] >>Admittedly, this isn't a great speed-up, but I haven't any easy way to use >>my upper 384K for anything else. Speaking of which, anyone have any ideas >>what I could do (for free) to utilize my 384K better than a Ramdisk? >>-- > >Yes, set it up as a disk cache. You'll love the difference in access time. >This is, of course, assuming you have a hard disk. > >Jason White // jdwhite@iastate.edu // "Get bent!" - Bart Simpson What is the best way (or configuration) to set up the 'upper' 384K as a cache? And does DOS have a way or is a PD program better? -- Larry Stern LDSTERN@RODAN.ACS.SYR.EDU
warkenti@CAE.Mitel.Com (Brad Warkentin) (04/20/91)
Adam Goldberg writes:
[use of upper 384K as ramdisk deleted]
Admittedly, this isn't a great speed-up, but I haven't any easy way to use
my upper 384K for anything else. Speaking of which, anyone have any ideas
what I could do (for free) to utilize my 384K better than a Ramdisk?
There are device drivers that allow you to simulate EMS memory with
this 384K extended memory. Most programs recognize this ok and are
willing to use it. I used to do this before I got some other
applications that could use the upper 384K directly. Go looking on
local BBSs for EMS simulators...
BJ...warkenti@CAE.Mitel.Com | This space for rent
Kanata, Ontario, Canada | [ CHEAP ]
I really didn't mean it quite that way, or did I :->c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) (04/25/91)
In article <34067@ccicpg.UUCP> mhr@ccicpg.UUCP (MHR {who?}) writes: >Whoa, hold on a moment there. >The upper 384k of the first megabyte of memory on a PC _is_ EMS memory. It is NOT EMS memory. EMS memory is a specification which allows 8086's to access data above 1M by simulating a 64K page in high memory and changing pages when different areas of the EMS memory are required. >Why would anyone want to go out and get an EMS emulator whic requires >XMS (extended memory spec) memory when they already have the EMS they >need? Because EMS memory is a standard. Many programs can't make use of extended memory, and by emulating EMS you're giving them access to it. >Now if Adam's 384k had been the first 384k on the far side of the first >megabyte, your advice would have been more appropriate, but I think you >may have misunderstood what he was saying (or I did, in which case >ignore this post). You've got it reversed. >Besides, I side with the previous responder to Adam's post who suggested >that he use it for a disk cache. I find that use to be eminently >suitable for my extra k. Agreed. A disk cache is a good choice if you want a general improvement in disk speed, since there are areas of the disk that are accessed frequently (such as the FAT and directory area). -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
cs352a41@cs.iastate.edu (Adam Goldberg) (04/25/91)
c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >In article <34067@ccicpg.UUCP> mhr@ccicpg.UUCP (MHR {who?}) writes: >>Now if Adam's 384k had been the first 384k on the far side of the first >>megabyte, your advice would have been more appropriate, but I think you >>may have misunderstood what he was saying (or I did, in which case >>ignore this post). >>Besides, I side with the previous responder to Adam's post who suggested >>that he use it for a disk cache. I find that use to be eminently >>suitable for my extra k. >Agreed. A disk cache is a good choice if you want a general >improvement in disk speed, since there are areas of the disk that >are accessed frequently (such as the FAT and directory area). Thanks to all who've sent me mail suggesting that I use a disk cache. I'm trying one out now, and it's kinda fun. I don't see the 900% improvement that some claim, but a little bit of improvement is ok, too...384k just sitting there at 10000h is a bit of a waste, so I'm better off now. -- +-----------------------------------------------------------------------------+ ! Adam Goldberg ! * ! "It's simple! Even a PASCAL ! ! cs352a41@cs.iastate.edu ! * ! programmer could do it!" ! +-----------------------------------------------------------------------------+
elund@graphics.rent.com (Eric W. Lund - Subop) (04/25/91)
cs352a41@cs.iastate.edu (Adam Goldberg) writes: > Thanks to all who've sent me mail suggesting that I use a disk cache. I'm > trying one out now, and it's kinda fun. I don't see the 900% improvement > that some claim, but a little bit of improvement is ok, too...384k just > sitting there at 10000h is a bit of a waste, so I'm better off now. I use my extra 384 for a cache, and most applications I notice a speedup. It is particularly helpful when running animation, for example an Autodesk Animator FLI file under 384k in size. After one pass through the animation, the disk access stops, the animation speeds up, and becomes much smoother. The extra 384k *IS* extended memory (XMS), not expanded (EMS). It can emulate expanded, by use of a driver (I have many), but I do not advise it. Expanded memory works by using a "window" through which data can be transferred. All the EMS->XMS drivers I've seen create a 64k window in MAIN system memory (<640k). That's a waste of main memory -- main memory is precious to programs that DON'T use expanded memory. And I have used several programs that use expanded, but need a good deal of system ram wether you've got that expanded installed or not! (Those who have tried to use Wing Commander on a 1 meg system with XMS->EMS drivers will know what I'm talking about.) If you can, put the CACHE in a batch file, with an appropriate uninstaller batch file if possible. PCTOOLS 4.5 and above have this, including the uninstall feature. (Of course, I'm afflicted with TSR-fright. I even have my mouse in a batch file.)
barry@gpu.utcs.utoronto.ca (Barry Lay) (04/25/91)
I have seen a number of remarks concerning 384k above the 1 meg line and what it is good for. While I also agree with the suggestion that a disk cache is probably the best because of the overhead of a XMS-EMS driver, I did notice some misinformation. For example, it was suggested that the 64k frame for EMS emulation had to go into conventional memory (below 640k). This is not true. Most emulators (such a QEMM, 386^MAX, even Windows, I think) will attempt to find a 64k window in the system area, between 640k and 1 meg. As most people don't have half a dozen different kinds of monitors or network cards installed in their machines, this is usually possible. On a 386 machine this can be achieved by remapping some of the 384k extended memory below the line. Another opportunity for some extra space is to use the 64k-16 above the line for TSRs etc., as it is accessable from real mode. This is available on 286s and up because the highest value for the real mode segment register is 0xffff, which points to an area sixteen bytes below the top. A sixteen bit offset register will take you almost 64k into new territory. Under normal circumstances this area is not accessable from real mode as the A20 line on the processor is normally gated off so that such memory accesses will wrap around to the bottom of memory, which is exactly what a 8088 will do. The HIMEM program (and probably QEMM as well) allows an application program to toggle the A20 gate so that TSRs or whatever can be loaded up there. Microsoft does warn that there are programs out there which assume that the wrap-around occurs, so you may experience curious results. Most of this information came from Microsoft's XMS specification which is available from Compu$erve in the Microsoft area. I am not sure why there isn't a version of HIMEM which installs itself into the first 64k of extended, but as there is source code for HIMEM (in assembler, unfortunately), there is no good reason why someone couldn't write one. I am also unaware of any programs which expect wraparound on high memory access, and it doesn't really make any sense to me to do such a thing. Probably something in DOS, as Microsoft makes special mention of it :-) Anybody know for sure? Barry
mhr@ccicpg.UUCP (MHR {who?}) (04/26/91)
In <34067@ccicpg.UUCP>, mhr@ccicpg.UUCP (me) writes: > The upper 384k of the first megabyte of memory on a PC _is_ EMS memory. > Why would anyone want to go out and get an EMS emulator whic requires > XMS (extended memory spec) memory when they already have the EMS they > need? > Ignore this please - product of a demented mind. I have had my upper 384k configured as EMS (w/driver) for so long I forgot. I still say a cache is a good idea, though.... -- Mark A. Hull-Richter UUCP: ccicpg!mhr In all things, restraint, ICL North America especially with respect 9801 Muirlands Blvd to posting articles and Irvine, CA 92713 (714)458-7282x4539 doubly so for flames.
RFM@psuvm.psu.edu (04/26/91)
OK, everybody agrees that using extra memory above 640k as disk cache will return more bang for buck than moving command.com up there. But why not do *both* ? A couple of points: (1) When it comes to allocating ram to disk caching, *MORE* is not necessarily better. I've read this in various discussions about disk caching, and I beliee it. In my own case, I get better numbers out of the Norton speed ratings with 128k in a disk cache than I do with 256 or 512k (all in EXPANDED mem, BTW). (2) I forget what I was going to say.... Anyway, why not try, for 384k, something like 128k in cache, and 256k in a ram drive, into which command.com is loaded and comspec'd (about 32k). If you're working WordPerfect with big documents, loading the file into a ram drive for work can greatly speed up i/o. Even better, for WordPerfect, is having enuf expanded memory to let WP load its overlays up there. Doing this will make WP (& maybe other programs as well) really zip along. BobM, PSU Harrisburg
c60b-1eq@e260-1g.berkeley.edu (Noam Mendelson) (04/27/91)
In article <91115.231110RFM@psuvm.psu.edu> RFM@psuvm.psu.edu writes: >why not do *both* ? A couple of points: (1) When it comes to allocating >ram to disk caching, *MORE* is not necessarily better. I've read this >in various discussions about disk caching, and I beliee it. In my own >case, I get better numbers out of the Norton speed ratings with 128k >in a disk cache than I do with 256 or 512k (all in EXPANDED mem, BTW). There is some truth to this. If you have an inefficient cache program or a slow-turkey computer, it may actually take the system longer to search through the cache than to just read it off the hard drive. Of course, the more memory you have allocated to the cache the longer the search time. A perfect example of a bad cache is the BUFFERS= statement in CONFIG.SYS. I've heard that this DOS cache uses no indexing, and simply searches the memory sequentially, looking for data. On a slow computer, if you set your BUFFERS too high, you'll actually get worse performance. Of course, the DOS cache is just about the least efficient known to man, but the principle can also apply to badly written caches. If you notice that a 256K cache actually slows down disk reads, you should probably get a new caching program. -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |