EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



NAME
     eqanda.txt - Expected Questions And Answers


CONTENTS
     This file 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 file.

     Why And How Cache Programs Speed Up Disk Io ?
     What Is IDE Disk ?
     What Are The Elements To Limit Concurrency ?
     What Is Floppies.exe ?
     What Is Ccdisk.exe ?
     Tell Me More About Ccdisk.exe's "takeover" Option.
     Why Ccdisk.exe Worrys About Irqs ?
     What Are Disk Drives Known To Concache.exe ?
     How Concache.exe Treats Disk Io Requests ?
     What Is Loading Order In Concache Family ?
     How Much Memory Should Be Prepared For Cache ?
     What Are Application Programs Inadequate For Concache.exe ?
     How Concache,exe Behaves For Dos Functions  Reset  Disk  And
     Commit File ?
     Then, How Concache.exe Can Be Tuned,  In  Terms  Of  Conven-
     tional Memory ?
     Aren't s, c, a, w Flags Redundant ?
     Quite Confused With +l, -l +u, -u !
     What Is "gang_interrupts" Option ?
     Is There Anything To Note With Relation To Serial Communica-
     tions Software ?
     Does Concache.exe Expect Any DOS Undocumented Internal ?
     Doesn't Start ! How Come !
     Data Corrupted ! What's Going On !
     Crashes Quite Randomly ! What Can Be Wrong !


QUESTION
     Why And How Cache Programs Speed Up Disk Io ?

ANSWER
     Actually, most disk cache programs don't speed up  disk  io.
     Instead, they reduce the number of disk io operations.  They
     work to the user as if disk io is completed as soon as  pos-
     sible.  How  ?  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.  For write requests, the
     data  to  be  written is copied into the cache and user pro-
     grams "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



Concache 1.00      Last Update:  18 March 1995                  1
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     is called 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
     postwrite,  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 opposite corner, every write request first writes FAT
     marking  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 not yet written
     FAT. So, not only actual number  of  write  operations  (not
     very  time consuming compared to head movements, though) are
     reduced but most head movements are eliminated by not  need-
     ing to actually go back and forth to FAT area.

     If no cache program is used you will experience severe  per-
     formance  degradation  if  buffers=  statement in config.sys
     file is inadequately written.  Also you will observe  writes
     get  slow down as your program proceed.  What cache programs
     do, up to this  generation,  is  to  extend  the  config.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.






Concache 1.00      Last Update:  18 March 1995                  2
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



QUESTION
     What Is IDE Disk ?

ANSWER
     It is Integrated Device Electronics (The Winn Rosch Hardware
     Bible).  It  is  the most popular disk interface today which
     connects to AT class machine.

     In this eqanda.txt file the word  is  grossly  used  as  the
     representative  of  disk interfaces, including those for ST-
     506 and ESDI  disks,  which  allow  programmers  communicate
     through  AT BIOS interface.  These disks are interchangeably
     called as IDE disks, BIOS (controlled) disks, or int13 disks
     in this document.

     However, even if  a  SCSI  disk  happens  to  be  interfaced
     through int13 with its unique BIOS, it is avoided to call it
     an IDE disk.


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.

     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  BIOSes handle only two "type"s of disks, which is suf-
     ficient 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
     manual  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



Concache 1.00      Last Update:  18 March 1995                  3
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     previous requests are in  progress. In fact, most known dev-
     ice drivers lose control of requests 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 dev-
     ices, 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.

     Finally comes the DOS drive  letter  availability.  If,  for
     example, 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.

QUESTION
     What Is Floppies.exe ?

ANSWER
     As we see above, floppies and  IDE  disks  cannot  run  con-
     currently  due  to  the  organization of DOS device drivers.
     Floppies.exe, under control of concache.exe,  replaces  most
     of  data  transfer  requests for floppies against DOS device
     driver to floppies.exe.  This  allows  IDE  disk  operations
     without interference from floppy disks'.

     Floppies.exe uses int40 instead of  int13  to  avoid  io.sys
     non-reentrancy problem.

     There are reasons not to use floppies.exe. First, since most
     floppy  operations  are read once, advantages to make floppy
     operations efficient by cache programs are, in  many  cases,
     doubtful.

     Second, if disk driver which  does  not  use  BIOS  call  is
     available,  then  configure  (non-bootable)  partitions  DOS
     incompatible, and use the driver for these partitions.  Then
     device  driver  and  int13  barriers disappear. See the next
     section for ccdisk.exe


QUESTION
     What is Ccdisk.exe ?

ANSWER
     Ccdisk.exe is the device driver for  non-int13  SCSI  disks.
     It handles any number of disk units DOS drive letters allow.
     Since floppy preempts two drive letters, the maximum  number
     of  disk  units ccdisk.exe handles is 24, assuming each unit
     configured into one partition.



Concache 1.00      Last Update:  18 March 1995                  4
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     In the absence of concache.exe, ccdisk.exe works as an ordi-
     nary  DOS  device driver, its reentrancy codes being a small
     overhead. In this case since DOS does driver  requests  only
     serially,  additional buffers, designated on config.sys com-
     mand line, are wasted.

     When  concache.exe  is  loaded,  concache.exe  does   driver
     requests  what  DOS has done to ccdisk.exe, which intercepts
     and reroutes to ccdisk.exe. Concache.exe  does  requests  of
     its  own  cache  managements, directly far calling the known
     entry point in ccdisk.exe. Since being  reentrant,  as  many
     requests as number of buffers ccdisk.exe holds are accepted.

     The concurrency of SCSI disks is determined  by  ccdisk.exe,
     not  by  concache.exe.  On  the  other  hand,  for one part,
     concache.exe is responsible for device request  arbitration,
     since  only concache.exe knows all disk io requests. For the
     other part, the multiplicity directly impacts  memory,  such
     as  io  buffers,  requirements  allocated  by  concache.exe.
     Default ccdisk.exe action is to evaluate  multiplicity  half
     the independent units it recognizes.

     There are cases  where  ccdisk.exe  does  not  provide  much
     advantages.

     1)   If disk unit or SCSI interface board  has  large  cache
          memory, using it instead of concache.exe may be in some
          cases faster. It eliminates the need for  memory  space
          ccdisk.exe occupies.

     2)   If there is only one disk  is  configured  but  no  IDE
          disks,   then   no   positive  merits  exist  in  using
          ccdisk.exe other than loading extra device  driver.  In
          this  case, it would make sense to treat the unit as an
          int13 disk, using floppies.exe if desired.


QUESTION
     Tell Me More About Ccdisk.exe's "takeover" Option.

ANSWER
     Suppose your machine has two SCSI  disk  units  but  no  IDE
     disks.  Unless you have the luxury to insert two SCSI inter-
     face boards into your machine, you either configure both  as
     BIOS  controlled  or  not.  This means you have to boot from
     floppy or lose concurrent operations of two disks, of  which
     you may not want either.

     To overcome this inconvenience, concache.exe and  ccdisk.exe
     cooperate in a special manner.  The devices remain nominated
     as io.sys drives  but  driven  by  ccdisk.exe  through  SCSI
     manager,  dictated  by  concache.exe.  Thus, after bootstrap



Concache 1.00      Last Update:  18 March 1995                  5
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     that needs BIOS access has finished, disks  can  enjoy  con-
     currency.

     Note SCSI manager must be loaded to  use  "takeover"  option
     even  if the board is configured to use BIOS.  Also note the
     option  takes   effect   only   by   concache.exe.   Without
     concache.exe, the drives remain io.sys properties.

     If more SCSI disks are connected than BIOS can  handle,  the
     remaining  SCSI disks are treated by ccdisk.exe operating as
     the device driver for them.  For those disks not under BIOS,
     presence  or  absence  of the option is irrelevant.  In gen-
     eral, it is hard to find the reason not to use this option.


QUESTION
     Why Ccdisk.exe Worrys About Irqs ?

ANSWER
     This comes from the nature of interrupt handler and the  way
     concache.exe switches.

     As  described  elsewhere,  switching  back  to  concache.exe
     occurs  at command posting (in ASPI terms) for SCSI devices.
     This implies the next SCSI request to the target  device  is
     prepared  in  this  instruction  thread while the control is
     held by,  which  can  be  something  lengthy.  In  spite  of
     concache.exe/ccdisk.exe full reentrancy, ASPI manager awaits
     return from command posting with interrupts  locked  on  the
     SCSI irq. Thus, not returning immediately from command post-
     ing may stop the other SCSI activities.  Note it  may  cause
     deadlock situations if more than two disks are involved.

     Then, if returned immediately,  where  should  the  required
     switching be performed ?

     It must be after the interrupt handler but before  returning
     from  the  interrupt.   Ccdisk.exe lets every SCSI interrupt
     call the handler and after that,  let  concache.exe  perform
     the switching.

     This is the story why ccdisk.exe is worrying about irqs.

     Since there is unfortunately no knowing of  irqs  from  pro-
     gramming interface, the command line must supply them.

     As might be seen, it matters only if  multiple  devices  are
     hooked  on  the irq.  If not, then saying no irqs may make a
     few microseconds faster.

     Note. This interrupt handler's behavior can be particular to
     aspi4dos.sys.   The   other   ASPI   managers   may   behave



Concache 1.00      Last Update:  18 March 1995                  6
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     differently.

     Important. In most cases default SCSI irq  detection  works.
     However,  not  all  BIOSes  use segment 0xf000, the guess is
     easily defeated by the other programs,  "stacks="  statement
     in  config.sys hides ROM segment addresses, and high latency
     interrupts  may  not  want  to   be   involved   in   delays
     concache.exe  switchings  cause.  It  is advised a few keys-
     trokes on config.sys should not be spared.


QUESTION
     What Are Disk Drives Known To Concache.exe ?

ANSWER
     If drive is one of following, then it is "unknown". All  the
     others are known to concache.exe.

     Number of fats are not two.
          These drives may represent ram disks, which don't  need
          to cache.

     Not a physical disk.
          In current directory structure in DOS,  each  drive  is
          marked as a physical drive or not.  Concache.exe faith-
          fully believes this information.

     Extraordinary block size devices.
          If physical block size is not 512 bytes or  if  logical
          block  size is not 512, 1024, 2048, 4098, or 8192 bytes
          then the device is unknown.

     No device parameters.
          Drives  on   device   driver   which   ioctl   function
          (int21440d,  get  drive  parameters  call)  is unimple-
          mented.  Only this type of  drives  can  be  forcefully
          "known"   to   concache.exe   by   using   the   option
          unknown_drives_permitted, in which case  the  drive  is
          handled as if a known disk.

     Drive is neither disk or floppy.
          If device parameter reports otherwise, then  the  drive
          is considered unknown.


QUESTION
     How Concache.exe Treats Disk Io Requests ?

ANSWER
     Unlike traditional disk cache programs which  intercept  i/o
     at BIOS level, concache.exe treats disk i/o requests at dev-
     ice driver level. That is, all DOS disk requests are  routed



Concache 1.00      Last Update:  18 March 1995                  7
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     through  concache.exe and it either caches the data to write
     or reads the data from disk or from its cache  memory.   Its
     postwrite  requirements are processed via intercepted device
     drivers.  The intent of this scheme is to be able to  handle
     broader  range  of device types without limiting cache capa-
     bility to BIOS supported disks.

     The negative aspect of this policy is that it had  to  fight
     against    DOS   non-reentrancy   problems;   for   example,
     concache.exe must await completion of CLOCK$  device  driver
     called  during  DOS  idle.   This sort of synchronization is
     unnecessary if concache.exe is implemented  at  BIOS  level.
     The synchronization certainly slows down both disk and clock
     devices.  Another difficulty intorduced by intercepting dev-
     ice  drivers  is that some software hide the physical driver
     entry and connections  with  them  are  sometimes  virtually
     impossible.

     The positive side is of course it can be used to cache  non-
     standard disks (with no concurrency however).

     In addition, it is very easy to implement  reentrant  device
     drivers,  in  this version ccdisk.exe. Concache.exe communi-
     cates with ccdisk.exe very easily.


QUESTION
     What Is Loading Order In Concache Family ?

ANSWER
     Under DOS  environment,  it  is  important  to  load  device
     drivers and TSRs in a specific order. This section describes
     the loading order related to concache.exe.

     1)   Concache.exe must be loaded after block device  drivers
          intended to be cached.  It intercepts DOS device driver
          requests.

     2)   Ccdisk.exe must be loaded after ASPI manager,  but  due
          to  the  condition  above,  it  must  be  loaded before
          concache.exe. Ccdisk.exe is loaded only by config.sys.

     3)   Floppies.exe may  be  loaded  independent  of  all  the
          other. It can be loaded even as a TSR.

     4)   If disk-in-disk type of device drivers are  used,  then
          concache.exe  must  be  loaded  before them, except for
          those specifically noted.


QUESTION
     How Much Memory Should Be Prepared For Cache ?



Concache 1.00      Last Update:  18 March 1995                  8
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



ANSWER
     There are certainly optimal points  of  cache  size.  Unfor-
     tunately,  the  points  are too dependent on application and
     the mix.  There is no clear way to  estimate  the  size  and
     performance 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 irrelevant to the other steps (unrealistic ?  but
     think  simple  this  way.) 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
     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
     better 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



Concache 1.00      Last Update:  18 March 1995                  9
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     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 ?


QUESTION
     What Are Application Programs Inadequate For Concache.exe ?

ANSWER
     The other disk cache programs may not coexist,  needless  to
     say it may be.

     Any program to maintain disk partitions is harmful.

     As far as tested, popular file maintenance programs such  as
     Norton  Utilities  and  PC-tools  work  properly.  Yet it is
     unsafe to use them with concache.exe. Unless  you  are  very
     brave  it is usually wise to use these programs concache.exe
     stopped.  This precaution is because many  file  maintenance
     programs can use int13 interface directly while concache.exe
     works the above so that cache data can become inconsistent.

     For performance reasons, maintenance such as  copying  files
     in  convoy  is,  although safe, should be carefully planned.
     Chances of reusing data in cache are rare in such cases,  so
     usually  no  point  in  using cache.  Since sooner cache are
     filled with data to be written to,  concache.exe  starts  to
     find  out  space for new request by vacating one of them. In
     this case cache performance will be  degenerated  to  be  no
     better than write through.

     There are programs which you may want to experiment (or  you
     may  produce  one).  To use such programs, at least "w" flag
     should be in effect.

     For incompatible softwares, see below and intro.txt filf.


QUESTION
     How Concache,exe Behaves For Dos Functions  Reset  Disk  And
     Commit File ?

ANSWER
     Reset disk function (int210d)  causes  concache.exe  refresh
     all pending dirty sectors of all local devices.  Commit file
     function (int2168) causes concache.exe refresh  all  pending
     dirty sectors of the local device the file is residing on.

     For files opened by  extended  open  (int216c)  with  commit
     flag,  file  writes,  together  with close, are handled like
     write-through requests.



Concache 1.00      Last Update:  18 March 1995                 10
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     However,  if  a  disk-in-disk   driver   is   loaded   after
     concache.exe,  then  the  driver may cause writes just after
     concache.exe has done the job, making  drives  again  dirty.
     There is no solution to this problem by concache.exe.


QUESTION
     Then, How Concache.exe Can Be Tuned,  In  Terms  Of  Conven-
     tional Memory ?

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
     concache.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
     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  480  bytes,  is  not
     used,  then it can be reduced to bare minimum 320 bytes pro-
     vided no SCSI disks are used. However, this may be  affected
     by  the  other external interrupt devices so experiments 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 ?



Concache 1.00      Last Update:  18 March 1995                 11
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



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.

     Finally, splitting files into disks in a scheme io  overlap-
     ping is possible would greately avoid the clashes.


QUESTION
     Aren't s, c, a, w Flags Redundant ?

ANSWER
     Concache.exe allows operation of cache both as the nature of
     drives  in  driver descriptions and as the operating mode of
     the program itself in flags.  This is to keep the nature  of
     drives  by  only  changing  flags. If complex (i.e., hard to
     remember) designations are given to drives,  the  flags  are
     convenient.

     They work as follows. For each drive, "s" is the  strongest,
     that is, if +s or a drive is to be stopped, the drive is not
     cached. "w" is the next, that is,  if  neither  is  "s"  and
     either is "w", then the drive is treated write through.  "a"
     comes next, and finally "c" (the default).


QUESTION
     Quite Confused With +l, -l +u, -u !

ANSWER
     They read, in the order, "start  locking",  "stop  locking",
     "start unlocking", and "stop unlocking", respectively.

     "Locking" means keep the "locked" data into cache.  After  l
     flag is set, concache.exe marks the data in cache as locked,
     to indicate subsequent space hunter  keep  away  from  those
     marked.  If  the  flag is reset by either "-l", concache.exe
     stops the marking.

     "Unlocking" means unmark the locked data touched  while  "u"
     flag  is  in  effect.   These data in cache becomes ordinary
     member of cached data.  After this, space  hunter  can  take



Concache 1.00      Last Update:  18 March 1995                 12
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     the piece of memory into consideration.

     Since it is illogical to allow both locking and unlocking at
     the  same  time,  the  "+l"  and  the '+u" are considered to
     implicitly deny each other.  The command line does not allow
     "+ul" or "-ul".

     There are two points to note.

     If locked too much, cache performance  can  degrade  because
     concache.exe uses only the remaining space for the other.

     Locks should not be used on highly fragmented  drives  since
     locked  records can cluster to a narrow range of cache area.
     (Note clustering itself is irrelevant to  locking,  but  its
     effect is more severe if locked records exist.)

     For write operations, if space to write cannot be found,  an
     arbitrarily chosen locked space will be unlocked and used as
     an ordinary cache space.


QUESTION
     What Is "gang_interrupts" Option ?

ANSWER
     The  "gang_interrupt"  option  is  related  to  concache.exe
     interrupt handling.

     Concache.exe switches to user program when device gets  busy
     and  switches  back  to itself when the device gets idle, as
     stated elsewhere.

     Due to the organization of IDE disk controllers, which  BIOS
     assumes,  hardware  interrupts  come in very short interval,
     one interrupt per one sector, after disk  head  is  properly
     located  to the desired track.  BIOS is designed to generate
     interrupts int1590 and int1591 in response to  every  sector
     it  transfers.   From  concache.exe  point of view, only the
     first int1590 and the last int1591 is important but there is
     no  way  to  know  the last one so concache.exe must perform
     switching on every int159[01].  When concache.exe  is  going
     back to BIOS by threading through the chain of the interrupt
     in normal fashion the  next  hardware  interrupt  is  ready.
     Worse,  on  the  chain,  interrupts  are  enabled by io.sys.
     Thus,  the  next  hardware  interrupt  is  generated  before
     returning back to the originator of int1591, the BIOS, which
     calls the next int1591 in response to this  hardware  inter-
     rupt.   The  result  is the accumulation of interrupt frames
     onto the stack which the first interrupt  of  the  gang  has
     eventually caught.




Concache 1.00      Last Update:  18 March 1995                 13
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     (If DMA is used for BIOS disks, then no gang  of  interrupts
     occur,  and  the  wasteful  switchings in concache.exe would
     have been eliminated.  But it is have-not's envy.)

     Each interrupt frame is relatively small. But it comes in  a
     group  of  8,  16  or more and the other external interrupts
     (such as timer) rolls the same stack frame.  This causes the
     defeats of small stack spaces.

     On the other hand, under usual situations, audiences of mul-
     titasking  interrupts are limited to concache.exe and multi-
     taskers.  Since the latter are loaded after concache.exe, it
     is safely concluded that the last listener to the interrupts
     is concache.exe, thus it must be safe to fold  the  path  at
     concache.exe.  Concache.exe  prevents  this  accumulation of
     interrupt frames by somewhat anti-social treatment of multi-
     tasking  interrupts.  By default, concache.exe truncates the
     BIOS multitasking interrupts and returns from the  interrupt
     immediately.

     However, if there is a need to pass multitasking  interrupts
     to  the  programs  loaded  before  concache.exe,  the option
     "gang_interrupts" allows concache.exe behave polite to  pass
     the interrupts down through the chain.

     If this option is in effect, arbitrarily chosen stack  space
     may  be  affected.   It  is  recommended  stacks=n,m line in
     config.sys file should read n=10 (or slightly more) or  n=18
     (or  slightly  more) and m=128. Avoid setting the value of n
     to a multiple of 8.  (Note stacks=0,0 does not  always  mean
     smallest  stack  space.   Rather, it means that the smallest
     stack space prepared by any program is  sufficient  for  any
     external interrupt.  Thus, in practice, stacks=8,64 may mean
     the smaller space than above for external interrupts.)


QUESTION
     Is There Anything To Note With Relation To Serial Communica-
     tions Software ?

ANSWER
     Serial communications are notorious for their severe  timing
     requirements.  You  must  be  concerned with CPU performance
     degradation concache.exe may cause.

     Following experiment may interest you. It is done with Cyrix
     DR486/33 with varying performances.  Using ms-kermit 3.13, a
     large file is downloaded on 19.2 and  38.4  kb  via  NS16450
     port, with packet length = 1000 bytes, default XON/XOFF.  On
     19.2 kb, there is no problem.  File  is  successfully  down-
     loaded.   (As  you  might  expect, using 486/33 machine with
     38.4 kb is ok.) On 38.4 kb, following is the result.



Concache 1.00      Last Update:  18 March 1995                 14
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     Norton SI                  Result
     ----------   ----------------------------------
         9.2                  don't work
        16.2                    ditto
        36.9      tick_interval must be 6 or greater
        53.5                    ditto
        54.2                    ditto

     Above  "don't  work"  means  download  was  successful   iff
     concache.exe  is  not loaded. Even the minimum overhead stop
     mode needs was unbearable.

     Above "tick_interval  must  be  6  or  greater"  means  that
     smaller   tick_interval   values   caused   overrun.   Since
     transmitting 1000 bytes at 38.4 kb needs 250 ms or more, and
     tick_interval=5  implys there is no cache refreshment writes
     for at least 275 ms after DOS  io,  concache.exe  activities
     should be essentially disallowed in these cases.


QUESTION
     Does Concache.exe Expect Any DOS Undocumented Internal ?

ANSWER
     Let's be precise. All the internals documented in the  books
     cited  in  intro are expected, and tested by concache.exe if
     used.

     The other internals not documented in the citations are few.

     1)   Int2a8[01] are "well balanced".

     2)   Int2a82 does nothing with synchronization.

     3)   Synchronizations int2a8[01]02 come with ds:si  register
          pair loaded with pointer to device driver.


QUESTION
     Doesn't Start ! How Come !
     Data Corrupted ! What's Going On !
     Crashes Quite Randomly ! What Can Be Wrong !

ANSWER
     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 1.00      Last Update:  18 March 1995                 15
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     Concache.exe  is  configured  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. (By the way, one of programs
     that uses tightest stack  space  is  command.com.   Repeated
     invocations  of  innocent  batch  file (for example, of only
     echo statement) will be a good test tool for stack  problems
     for TSRs and device drivers that serve external interrupts.)

     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
     solutions whatsoever.

     The conflict can be between third party  device  drivers  or
     hardware I didn't pay attention and money, and concache.exe.

     For other programs this level of incompatibility is  out  of
     assumptions  about  DOS  interrupt  schemes or out of device
     driver behaviors.


  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.

     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.



Concache 1.00      Last Update:  18 March 1995                 16
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     Solving these cases need real hack; many of troubles  caused
     by write after mode are given up to isolate real matters.

     Some  scenarios  found  during  test  but  not  solved   are
     presented here.

     Int13 problem
          Concache.exe doesn't monitor int13, so that the data on
          disk  and  cache mismatch but concache.exe doesn't have
          the way to note.

     Disk-in-disk problem
          Device drivers employed by disk  compression  and  data
          encryption software hide physical device driver entries
          and call the entry independent from concache.exe,  thus
          causes  corruption of non-reentrant device driver codes
          and misbehaving of devices.

     Another disk-in-disk problem
          This is similar to int13 problem discussed above.   For
          example,  if  writes  to both COMPRESSED and its mother
          drives are needed, any write after policy on the mother
          drive can become dangerous.  The data on the drive must
          be synchronized at all  times  (that  is,  it  must  be
          "clean" at any time.)

  Concurrency Mode Fails
     If write after mode works but concurrency mode  doesn't,  it
     seems  most  of  problems  are  of  synchronizations.  Cases
     encountered while testing compatibilities are

     1) improper int2a8x handling
          For example a network program discards int2a8x critical
          section  interrupts  while within int13 period, exactly
          which is what  concache.exe  is  going  to  do.  Conse-
          quently,  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 reen-
          tered. In such  cases  it  issues  DOS  synchronization
          interrupt  and  warns  not to call DOS.  Unfortunately,
          the interrupt is ignored or  ill-treated,  thus  causes
          hang.

     2) improper int159x handling
          While int159000 is hidden from  concache.exe,  programs
          usurped  int76 still cause int159100, thus concache.exe
          gets confused.

          Floppies seem to be forgotten.




Concache 1.00      Last Update:  18 March 1995                 17
EQANDA            COPYRIGHT horio shoichi 1995             EQANDA



     3) failing to switch vm
          This happens when ASPI is going to  switch  to  the  vm
          that issued io upon SCSI interrupt (although it appears
          not an ASPI bug).


SEE ALSO
     ccdisk.txt, concache.txt, floppies.txt, intro.txt.















































Concache 1.00      Last Update:  18 March 1995                 18
