Re: Modified floppy server

Hi,

I've cc'd this to the list in case anyone with more experience of floppies
can spot any gaping wholes in my reasoning about performance.

Dave Mason wrote:
>
> > Running a boot floppy with the new code seems to have everything running
> > about 200-300% faster under a dos fs.
>
> Usable!

Well it allows me to bring up VSTa and all of my servers in just under 1
minute from a boot floppy :-) (It was about 5 minutes before the new code)

> > FWIW I believe that the difference between the 71 second and the 56 second
> > results is down to the overhead of an extra 35 requests per track (2880
> > requests as opposed to just 80).

Actually I fixed a bug earlier today and the timings are now 76 and 46
respectively. I think some work on the messaging code and context switching
will improve this quite a bit. It also suggests that some of the copying
from the read-ahead buffer may be quite a bit more expensive than I'd
originally realised.

> Why not buffer a full track? It's only 18K. You could issue the
> first 512 bytes, then 3.5K, then 14K (postponing the 14K read allows
> waiting to see if the 3.5 was useful (i.e. did the client ask for more
> before the 3.5 was read) to optimize most access patterns).

I thought about this (although it would be a more significant rewrite) - in
fact I made a comment about track caching in the readme for the 1.3.2
version of fd. The performance issue with floppies is that of missing the
next sector - waiting 200 ms for the disk to spin round again is really bad
news.

If we used segmented buffering of a track (ie 512, 3.5k and then 14k) we'd
be in great danger of missing the next sector after each segment and thus
waiting 200 ms for the next blocks.

One thing I did try and found wasn't useful was reading ahead for whole
cylinders (both sides of the media), but the extra code didn't actually give
me any benefits in performance (so I took it out - I like to keep things as
simple as possible).

There are a couple of nice side-effects of the way the read-ahead works.
The first is that we're unlikely to want to read data from lower numbered
sectors if we make our first request somewhere in the middle of the track so
we don't bother to buffer (and thus wait for) data we aren't likely to need.
The second is that whatever the client requests gets DMA'd directly into
their buffer not DMA'd into a track buffer and then copied - quite a saving
on a lot of I/O.

> I'm not running vsta yet, but fairly soon, I think.

The more the merrier :-)

                        Regards,
                        Dave
Received on Fri Oct 28 17:56:09 1994