From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9706110228.AA14716@clio.rice.edu>
Subject: Re: Latest stub
To: billc AT blackmagic DOT tait DOT co DOT nz
Date: Tue, 10 Jun 1997 21:28:59 -0600 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il, robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de,
        djgpp-workers AT delorie DOT com
In-Reply-To: <339EFABB.18E8@blackmagic.tait.co.nz> from "Bill Currie" at Jun 11, 97 12:21:31 pm
Content-Type: text
Precedence: bulk

> Ugh... Hmm.. what are the consequences of the size not being on a 512
> byte boundary?

Nothing terrible - just slowness when writes are not sector aligned on
the disk so DOS does more buffering.

> After posting my patches, I found the cause of the problem I mentioned
> it that post (the one with the aborts), and now I definitly agree with
> Charles' solution, just fix stubedit to limit the maximum size to 63k.

Actually it ought to be 63.5K - the maximum sector aligned size.  Since
DOS can't handle anything >= 64K, and making the size not a 512 multiple
will just make things slower - 63.5K is usually the max performance point for 
large transfers.  Real life tests on non cached disks showed little to no
performance over 16Kb.  Multiple buffers in 32-bit memory improve 
performance on non-disk cached systems (acting like a cache) but we
chose not to implement that.  For programs that do lots of short random 
(non-sequential) reads on files, a smaller transfer buffer is actually 
faster (which is why it was left stubedit-ible)...