CD Shareware Magazine 1997 January

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

/ CD Shareware Magazine 1997 January / CD_shareware_1-97.iso / DOS / UTL-DSK / CCACHE11.ZIP / EQANDA.TXT < prev next >

Wrap

Text File | 1996-06-22 | 21.0 KB | 532 lines

EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA NAME eqanda.txt - Expected Questions And Answers CONTENTS This section contains the questions probably raised in using concache.exe and the family programs, the DOS disk cache program, and their answers. Following is the contents of this section. Why And How Cache Programs Speed Up Disk Io ? What Are The Elements To Limit Concurrency ? How Much Memory Should Be Prepared For Cache ? How Concache.exe Can Be Tuned, In Terms Of Conven- tional Memory ? Is There Anything To Note With Relation To Serial Com- munications Software ? Troubleshooting QUESTION Why And How Cache Programs Speed Up Disk Io ? ANSWER Actually, disk cache programs don't speed up disk io. Instead, they reduce the number of disk io operations. They work to the user program as if disk io is completed as soon as possible. They buffer disk data in a large memory area called disk cache buffer (hereafter simply termed cache). For read requests, if the data to be read reside in the cache, data is supplied from cache. Also, data to be read next by user programs are read and stored in the cache. This method of speed up is called "read ahead" or "preread". For write requests, the data to be written is copied into the cache and user programs "think" the data to be written are really written to disks. The data are actually written at the cache program's convenience. This method of speeding up the write requests is called "delay write", "write behind", "write after", or "postwrite". First generation of PC cache programs were generally reluc- tant to use postwrite. This is thought of as a too special luxury. Data to be written are written to disks as soon as requested. The method to handle writes this way is called "write-through". When cache programs arrived on the market which use post- write, it is found the programs more than double the speed of writes. This is because disk allocation table, known as FAT, is located at the top of disk and data space at the Concache 1.10 Last Update: 19 June 1996 1 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA opposite corner, every write request first writes FAT mark- ing as used and then turns head to the allocated area and write data sectors. Postwrite in effect eliminates repeated writes on FAT by submitting to DOS yet unwritten FAT. So, not only actual number of write operations are reduced but most head movements are eliminated by not needing to actu- ally go back and forth to FAT area. When working on floppy, you might have experienced severe performance degradation if buffers= statement in config.sys file is inadequately written. Also you might have observed writes get slow down as your program proceed. What cache programs do, up to this generation, is to extend the con- fig.sys statement buffers= to a large cache buffer. Next come so called "advanced" cache programs which attempt to write data back concurrently with user programs. These cache programs don't wait keyboard idle time, for example, to write back cached data. This means traditional DOS pro- grams' common inception that because disk writes are slow they must be held into application program's buffers until absolute needs arise to write them back is wrong. Writing data as required is in fact faster and, perhaps less impor- tant, eliminates the need of huge buffers from each applica- tion program. In addition, because data are written as they are produced, there are less chances of accidental data loss. They become faster, safer and leaner. It might be possible to think disk speed up has taken place beginning with this generation. Concache.exe belongs to this generation, and has added another generality. It allows concurrency as far as there is no reason to refrain from. The result is one floppy, one BIOS disk, and as many as SCSI disks configurable into DOS can be driven concurrently with DOS/user programs. QUESTION What Are The Elements To Limit Concurrency ? ANSWER From hardware point of view, floppies can not perform io concurrently each other due to floppy controller design. Also, IDE disks cannot. SCSI disks can perform io in paral- lel, as seen on many multiprogramming operating systems. At this level, one floppy, one IDE disk and SCSI disks can operate concurrently. Concache 1.10 Last Update: 19 June 1996 2 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA The next level to consider is BIOS to support io operations. As far as published BIOS listing is concerned, there is no reason floppy and IDE disk cannot operate concurrently. SCSI drivers are usually written to do io asynchronously. Here comes BIOS capability to distinguish disk events. Stan- dard BIOS handle only two "type"s of disks, which is suffi- cient for floppies and IDE disk environments, as found in most PC configurations. Fortunately, ASPI (advanced SCSI programming interface) specification, now broadly employed, supports a mechanism effectively similar to BIOS disk event notification, called command posting. (See appropriate man- ual about this.) This allows handle individual disk's events. At this level no situations about concurrency issue is changed. The next level of the factor is device driver's non- reentrancy. Even if a device driver manages several disks, it expects its requests come serially but not while the pre- vious requests are in progress. In fact, most known device drivers lose reentrancy necessary for concurrency at the very first two steps of driver code execution. Also, io.sys handles int13, which is passed through by almost any disk device call, in non-reentrant way. So, you may think if third party device driver is used, for example using io.sys for floppies and that for the other disk devices, then at least the combination of one floppy and one hard disk should work concurrently. But no. If both share int13, then they don't work concurrently. Next comes the DOS drive letter availability. If, for exam- ple, a SCSI disk is split into two partitions, with many good reasons, the user loses one drive letter for one disk. These two partitions cannot share the io operation time. Those constitute inherent limitations of concurrency. In practice, there are resource limitations for programs under DOS. For example ASPI drivers may limit the number of pack- ets that it can accept at once. Likewise, ccdisk.exe can limit the concurrency of SCSI disks from its command line. Finally, concache.exe can limit concurrency in two ways. 1) concurrency= option limits the number of concurrent devices. Concache 1.10 Last Update: 19 June 1996 3 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA 2) io_buffers= option specifies insufficient io buffers to let devices work concurrently. QUESTION How Much Memory Should Be Prepared For Cache ? ANSWER There are certainly optimal points of cache size. Unfortu- nately, the points are too dependent on application and the mix. There is no clear way to estimate the size and perfor- mance of cache. Fortunately, concache.exe allows change cache size on the fly. You can observe the performance of various cache sizes. If adding memory doesn't improve, then probably your mix needs more memory, or you decide decrease cache memory size without degrading performance. A "pathetic" looking example is presented below. This kind of anomaly is not uncommon in practice. Consider following hypothetical example. I edit, compile, link, and debug programs, just cyclically repeating these steps. For simplicity, assume each step requires exactly one megabyte. And assume each step needs a set of files completely unrelated to the other steps (unrealistic ? but think simple this way for now.) Now let's have 3 megabytes cache. Then how this 3 mb will be used ? Each of first three steps loads editor and source files into first megabyte, loads compiler, header, source, and object files into the next megabyte, finally loads loader, library, object and exe files into the last megabyte. The fourth step finds no free megabyte. So it must select one from among three. Now familiar algorithm is in its turn. Since the content of first megabyte is least recently used, it is considered unlikely to be used very soon. So the algorithm loads exe file, debugger, test data into, you see, into the first megabyte. I go back to editor. It is not in the first megabyte as you have just witnessed. The editor etc. must be loaded into second megabyte under similar fuss. This will purge com- piler and so on from second megabyte. ... In this example cache performance is no better than if I used only one megabyte cache. If I added another megabyte then the performance will be jump improved but adding the Concache 1.10 Last Update: 19 June 1996 4 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA more does no good. If your job mix consists of five mutu- ally unrelated steps each requiring one megabyte and cache size is four megabytes, then four megabyte space is no bet- ter than one megabyte. This extremity comes out of commonly used LRU algorithm and extremely simplistic assumptions of usage pattern. The least recently used space is unlikely to be used very soon, but actually it is in this case. So, to pick up a victim out of already used three megabytes, let us select it randomly. The probability of the survival of the next needed megabyte is 0.67, and cache performance is improved that much, isn't it ? A similar situation is when copying a large file. Never read again and never written again records continually flows into cache data area, thereby erasing useful data from there. So, more than double the file size cache area is necessary to keep important data cached. In practice, however, situation is not that bad. Even for file copying, FAT and directory images are repeatedly refer- enced from cache data area so disk head movements, as well as repeated reads and writes to these area on disks are avoided, thus improving the speed of the copy operation. In the case of file copy, a rather small cache area works as well as large ones. QUESTION How Concache.exe Can Be Tuned, In Terms Of Conventional Mem- ory ? ANSWER An inevitable penalty of concurrency is memory requirements. Each concurrently driven device needs its own io buffer, control and stack space to switch to and fro, request packet to organize io, and, for ccdisk.exe, SCSI control block, in addition to descriptors needed for drives managed by con- cache.exe. Following is the description to save memory space used up by concache.exe. First, you can load concache.exe into upper memory, either through config.sys as a device driver or through autoexec.bat as a TSR (terminate and stay resident). Second, io buffer size can be changed by buffer_size= option, which can slow down data transfers. Note the size Concache 1.10 Last Update: 19 June 1996 5 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA must be at least the size of the largest sector to be cached. Third, the number of io buffers can be changed. This change can affect io performance done by concache.exe so experi- ments are needed. Fourth, directory space can be made at a minimum to the con- currency you want. Fifth, if full stack space, currently 440 - 500 bytes, is not used, then it can be reduced to bare minimum 320 bytes provided no SCSI disks are used. However, this may be affected by the other external interrupt devices so experi- ments may be needed. (After all, under DOS, the proof of the stack is in the eating.) Finally, on ccdisk.exe command line, concurrency require- ments can be reduced down to somewhere bare minimum. If unfortunately concurrency mode cannot be used, then saying "concurrency=1" would save hundreds of bytes. QUESTION How Concache.exe Can Be Tuned, In Terms Of Performance ? ANSWER Speeding up is gained by either letting io efficient or by taking maximal concurrency. First, make tick_delay= value larger, to avoid clash between DOS and concache.exe write back actions. This goes with almost no penalties. Second, make io buffer size or number of io buffers larger. Options for these two factors work almost synonymously, since concache.exe doesn't do io in fixed size buffers. This will improve each io time and, if number of buffers is sufficiently large, will also allow concurrent actions. Third, as cache data area is split into multiple units of 8kb, which is fairly large compared to cluster size many people prefer, if the drives are heavily fragmented, then a large amount of space can be wasted in cache area. Note drive fragmentation is not the least influential on perfor- mance, and this is not particular to concache.exe but to all disk cache programs that work on FAT oriented file systems. Fourth, splitting files into disks in a scheme io overlap- ping is possible would avoid the io clashes. Concache 1.10 Last Update: 19 June 1996 6 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA Fifth, although preread improves performance in most cases, it can degrade overall performance in certain cases; if read pattern is random then preread is not only useless but also further slows down by access clashes. If such files are frequently accessed, it might be better move them to a par- tition that does not preread. If cache data area is of marginal size then preread can purge still useful data from there and instead read out yet unnecessary data. QUESTION Is There Anything To Note With Relation To Serial Communica- tions Software ? ANSWER Serial communications are notorious for their severe timing requirements. For example, when communication speed is 38.4kb and the communication device is a model that lacks buffer, then each character received through it must be han- dled within 25 microsecond. Failing to handle the received character within the interval would result in overrun error familiar to programmers. Note this problem is particular to receive side; a few delays on send side usually make no severe problems. On the other hand since concache.exe works asynchronously with serial io, disk io is initiated and completed concur- rently with character transmissions. This means con- cache.exe causes various housekeepings in DOS context to be performed within the short interval, which is almost impos- sible on most PCs other than recent high performance ones. Alleviations do exist, fortunately. Following lists several of possible ways. write after mode This is to avoid overlapping operations with serial transfers, thus the severe timing problem disappears. buffered controller If controller used for serial communication has receive buffer it allows extend the short interval several times longer. For example, using NS16550 chip enables, when properly programmed, lengthen the interval 16 times. hardware flow control If this is possible on your PC and the counterpart, this prevents receiving when there is no room to do so, Concache 1.10 Last Update: 19 June 1996 7 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA thus the short interval is (unlimitedly ?) extended. Troubleshooting In the following, common conflicts such as irq, dma, memory, SCSI option settings are not discussed. They are treated in respective manufacturer's manual, and (probably) not partic- ular to concache.exe per se. First, stack issue must be tried, as this causes most obscure effects on the workings of DOS programs. Concache.exe is designed to work in the environment stacks=0,0. However, because of variety of BIOS manufactur- ers and existence of so many BIOS versions, it is not cer- tain the estimate on concache's own stack requirements is enough in every environment it encounters. In addition, there may exist programs which expect a large stack space is available at any time. For testing purpose, first try "extremely wasteful" stack space in config.sys. If this solves problem, your remaining task is find out the best values for the config.sys line. Alternately, stacksize= option on concache.exe can be tried to find if concache.exe is experiencing stack overflow. Let's discuss the problem in each mode of concache.exe. Respective mode is to be given by option or by drive description. Fail On Stop Mode If concache.exe fails in stop mode, there are two cases to consider. CPU overhead concache.exe incurs can be the problem. See the section on the relations to communication. There is no gen- eral solutions whatsoever. The conflict can be between third party device drivers or hardware. The gnaw_interrupt option on concache.exe may help in some cases. Write Through Mode Doesn't Work Added complexity from stop mode to write through mode is the actual access to memory manager and device driver. Empirically, conflicts with memory managers are very rare, except for pre-'90 EMS managers. Concache 1.10 Last Update: 19 June 1996 8 EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA Some device drivers may not be prepared with recent device driver conventions. Write After Mode Doesn't Work Concurrency problems start from this mode. A variety of assumptions about single-taskness of DOS programs where io actions are enclosed within DOS context begin to cause con- flicts. Interrupt intensive applications can fail due to switching overhead caused by concache.exe. If this might be the case, then try write through mode. Slowing down is far better than losing data. Concurrency Mode Fails If write after mode works but concurrency mode doesn't, it seems most of problems are of synchronizations. One of cases encountered while testing compatibilities are due to improper int2a8x handling. For example a network program ignores int2a8x critical sec- tion interrupts while within int13 period, exactly which is what concache.exe is going to do. Consequently, the program miscounts int2a8x and erroneously identifies DOS idle period. Another example. There are certain periods concache.exe does not want to be interrupted and reentered. In such cases it issues DOS synchronization interrupt and warns not to call DOS. Unfortunately, the interrupt is ignored or ill- treated, thus causing hang. SEE ALSO ccdisk.txt, concache.txt, floppies.txt, overview.txt. Concache 1.10 Last Update: 19 June 1996 9