JRKUHN@MTUS5.BITNET (09/26/90)
Regarding lower data transfer rates with Quarterdeck's QEMM:
I encountered the same problem on a 386-25 with an RLL drive.
Apparently, Qemm imposes enough of an overhead to the system that some
disk controllers cannot keep up at their current interleave setting. The
solution is to lower the interleave of the hard drive until it is at a
point where it can keep up.The interleave on a hard drive can usually be
adjusted using programs such as Spinrite II or the Norton Utilities v 5.0,
but be sure to heed all warnings these programs provide and BACKUP the hard
disk before you attempt to change the interleave.
More specifically, the problem is as follows:
On a system with an MFM drive, for example, unloaded (i.e. no QEMM
overhead), the disk may be able to run at an interleave setting of 1:1,
meaning it can read every sector on the disk in order sequentially in real
time. Thus, the disk sectors are ordered so that they read sequentially,
(i.e. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ), and it only takes one
revolution of the disk to read the entire track.
Now, with the introduction of QEMM into the system (requireing usually
a 5 % overhead or so), the disk can no longer read the sectors sequentially
in real time. Since the sectors are still sequentially ordered, however,
the system will tryand read an entire track sequentially. Since it cannot,
however, the result is that it ends up reading only 1 sector per revolution
of the disk. Thus, it now requires 17 revolutions of the disk to read a
single track -- resulting in an incredible slowdown in disk throughput
(essentially a factor of 17).
If the interleave on the disk is now lowered to 2:1, the sectors will be
staggered, i.e. (9 1 10 2 11 3 12 4 13 5 14 6 15 7 16 817 -- or close to
this). While the system still cannot read a track in one pass, because the
sectors are staggered, it can read half of them (every other one) in a single
pass. Thus, it now requires only two passes to read a track.
The end result is that with QEMM loaded, this will speed the disk up
again, although it's new data transfer rate will be slightly lower,
reflecting the lower interleave. If you need the features QEMM provides,
this is a reasonable solution to the problem.
Note also that you may have to lower the interleave further than a net
1 revolution change. Both Spinrite and Norton 5.0 will compute the best
interleave for your system and display a table showing the interleaves and
their resultant data transfer rates.
Also, I do not know if this problem occurs also with 386-to the Max.
--- Hope this helps, JRKUHN@MTUS5.BITNETmlord@bwdls58.bnr.ca (Mark Lord) (09/27/90)
In article <90269.100339JRKUHN@MTUS5.BITNET> JRKUHN@MTUS5.BITNET writes: > >Regarding lower data transfer rates with Quarterdeck's QEMM: > > I encountered the same problem on a 386-25 with an RLL drive. >Apparently, Qemm imposes enough of an overhead to the system that some >disk controllers cannot keep up at their current interleave setting. IHMO, the simplest and best overall solution for this, is to install a track-buffering disk caching program, such as pc-cache, superpckwik, hyperdisk, or others.. I have had no problems with 1:1 interleave using QEMM or QEMM+DESQVIEW, but then I always have a track-buffering cache installed, as well. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|