dlr@daver.UUCP (Dave Rand) (11/08/88)
I have been trying to track down why the System V file system is
so slow, at least on the ICM-3216. I finally found the reason why.
I was getting about 40k bytes per second from the disk, through
the file system. This was confusing, as when a direct dd was
done, with a large block size, over 200K/second was possible.
I investigated a number of possibilities, and checked a number of
things. It came down to the fact that the Z-80 (which handles
the disk I/O on the ICM) had a latency of about 10 milliseconds
from the time it received a request, to the time it issued an
I/O to the SCSI device. This meant that the maximum I/O rate,
assuming zero seek time, zero rotational latency, and infinite
transfer rate was 100k/second (since System V requests 1k transfers).
To "fix" this, I modified the disk driver to cache requests,
and built a local 100k cache in the driver. This does a pre-read
if the block requested is not in the cache.
The transfer rate has improved dramatically, but still is not
as high as I would like to see it.
Does anyone else running the ICM-3216 have any ideas?
Diffs for the changes are available, if you want to try them on
your system.
Disclaimer: These opinions reflect my thoughts only.
--
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlrdtynan@sultra.UUCP (Der Tynan) (11/09/88)
In article <7090@daver.UUCP>, dlr@daver.UUCP (Dave Rand) writes: [about a problem with the latency of the Z80, when it comes to disk I/O on an ICM3216]. > > To "fix" this, I modified the disk driver to cache requests, > and built a local 100k cache in the driver. This does a pre-read > if the block requested is not in the cache. > > The transfer rate has improved dramatically, but still is not > as high as I would like to see it. > > Dave Rand Rather than use a cache, use the space to do track buffering. In other words, divide the 100K of cache into 'n' track buffers. When requesting a block from disk, check to see if the 'track' is already in the buffer, in which case, move it over. Otherwise, using LRU (or something else), load another track. This way, the requests to the Z80 are on a track by track basis (spread the overhead), and the 10ms isn't as big a problem. Also, if your system isn't too fragmented, you've implemented a read-ahead scheme. When flushing dirty tracks, make a decision whether to just write the full track, or the dirty blocks, based on which is more efficient. Reading and writing a full track also negate the use of a disk interleave, so your read/write times should improve as well. I'll be happy to answer any questions... - Der -- dtynan@Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!zorba.Tynan.COM!dtynan --- God invented alcohol to keep the Irish from taking over the planet ---
ian@sibyl.eleceng.ua.OZ (Ian Dall) (11/23/88)
In article <7090@daver.UUCP> dlr@daver.UUCP (Dave Rand) writes: >I have been trying to track down why the System V file system is >so slow, at least on the ICM-3216. I finally found the reason why. . . . >I investigated a number of possibilities, and checked a number of >things. It came down to the fact that the Z-80 (which handles >the disk I/O on the ICM) had a latency of about 10 milliseconds >from the time it received a request, to the time it issued an >I/O to the SCSI device. Does anyone know why this is? I've tried to glean as much from the ICM hardware manual and some SCSI bus timing specs and I can't for the life of me see what should take so long. The SCSI bus arbitration should be in micro seconds, not milli seconds. I don't know anything about the 5385 SCSI controller, (for all I know it might be a dog to drive) but it seems like the Z80 just has to point the 5385 at a command descriptor block in main memory and tell it to go. Can the Z80 code be improved? I heard there were revisions to the PALS and/or Z80 roms to improve IO performance. It this true and if so what were the upgrades and how does one go about ordering one? I am planning on designing a 32CG16 based graphics card compatable with the ICM series. National don't have any work going on this do they? I have no desire to waste effort. Did any peripheral cards for the ICM series besides the 8 line serial expander ever see the light of day? -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.