#1.3 ?
17 messages in this thread
Although 1.3's FFS does provide a much needed, and really noticable,
speed increase, most of the DISPERF's are quoting the read/write times with
the BUF value at 32K. The MORE telling figure is the 512 BYTE BUF stats.
Here the figures are MUCH slower (65-69K/sec on my Seagate 251 VS. 232K/sec
with the 32K BUF). The WHOLE system was much "snappier", but FEW things
will really attain that top speed. Programs load, for example, at a rate
lower than the MAX 512 BYTE rate. But still, it is a nice improvement.
RE: Program load Times with FFS: Have You set MaxTransfer in the
MountList to some value > 512? I have mine set to 204800, and
programs LOAD much quicker! This is on a 2090, with Omega 9 FFS, and
the 34.4 HDDISK, and an ST-251 (40 ms)
Larry, what is the meaning of maxtransfer, and how do you choose it? From what
I'm reading, is hddisk the actual ffs software? BTW, I have a 3meg ram system,
with a '33'meg 65ms hd, omti controller. Any comments on what value I would
use with maxtransfer (when the time comes, of course)? Thanks,
MaxTransfer is the total number of bytes FFS can transfer at ONE time
from the drive (I. E. it uses MultiSector Writes and READS when MaxTransfer is
set above 512.
As for recommendations, GET THE ENHANCER BOOK (With 1.3 When Released).
NO FFS is NOT in the HDDISK, it is a seperate File….
I dont want to do the recommendations, I just made mine 2 Meg, but that
was a guess.
Larry Rosenman
via Whap! 1.4R
Larry, how much ram do you have? I would imagine that if I were to tune down
blitzdisk (after all, I won't need it as much) and set maxtransfer to some
number like .5meg (I have 3 meg ram) I would be in good shape. I also get an
impression from what you're saying that preffs only does single sector writes
and reads. I would think that if I do much more then .5meg that I will tie up
a lot of ram while some code tries to catch up.
Ron
Ron,
Maxtransfer does not eat memory. Here's the scoop…
1.2 file system reads/writes only 512 bytes at a time. Most controllers are
capable of asking the drive for a number of sectors, starrting at a given
sector. FFS is capable of multi-sector read/write, and in addition, allows you
to set the maximum number of bytes that can be asked for by the file system in
any one IO request to the driver. Since the file syatem knows about teh
Amigados file format, it can determine how many contiguous sectors can be read
while reading a file, and will ask for them if maxTransfer is set high enough.
Asking the controller to transfer say, 10 sectors, is a LOT quicker than
asking it to transfer 1 sector at a time for each sector of the 10. As the
number of sectors asked for increases, the benefit increases.
Addbuffers is what will eat some memory.
-larry
Larry,
Unless they've changed something recently, the use of MaxTransfer
appears to be a limiting parameter rather than a performance upgrade parameter.
The reason I say this is that if you don't include that parameter in your
mountlist for the FFS drive, you get no difference in performance (using
diskperf) than if you had it set at a number above 32768. If you set it at a
lower number, (such as 4096), then the diskperf figures are the same for buffer
sizes of 4096, 8192 and 32767.
Getting away from diskperf, and into the real world where program sizes
are easily in the 100K category, I'm not so sure that MaxTransfer would do you
much good there either since the loader seems to be the slow down.
I do suspect that MaxTransfer can eat up memory, at least during disk
i/o, since if you ask for 32K bytes at once…they have to be buffered
somewhere.
Perhaps a balance between the buffers, maxtransfer and priority
parameters could be achieved to maximize performance.
Don
I happen to have 3 Meg (1 meg on the motherboard, and a A-2052).
As Larry Phillips says, MaxTransfer does NOT eat memory, but my 300 buffers of
AddBuffers does.
Larry Rosenman
via Whap! 1.4R
Larry,
I ran some tests with MaxTransfer and settled on a value of 20000.
Diskperf has 4 read/write speed tests at the end – 512 bytes, 4K, 8K and 32K
bytes. MaxTransfers greater than 10000 only affected the last test (32K), the
rest (first 3 tests) were identical. MaxTransfer = 255 was the slowest, with a
max speed in the 32K test of about 85K/second.
My point was that the 512 byte test topped out at about 65/second – even
when the 32K test was showing 238K/second. And ACTUAL LOAD times were less than
the 65K/second. So the figures we've seen bandied about ARE a bit misleading.
But the system IS snappier with 1.3.
Lloyd
What MaxTransfer does is set the MAX amount that can be transfered in ONE
request to the driver. If the DISK is NOT Fragmented, the MaxTransfer helps.
I run mine with MaxTransfer set at 204800 so I gets up to 204K at a clip. I
also run with 300 buffers, and getting something the 2nd time is nice.
FFS is a *LOT* smarter about what gets cached in the extra buffers (like
Directory and Header blocks, not data blocks).
Bear in mind, I do not work for or represent Commodore, and have found
this out from being a Gamma/Omega tester of the Software.
More definitive Info should (I HOPE) be in the 1.3 release docs.
Larry Rosenman
via Whap! 1.4R
Lloyd,
The figures are not misleading in terms of transfer rate of data (as opposed
to program loading). The loader introduces its own overhead due to the need to
relocate programs.
-larry
Lloyd,
An interesting point in relation to MaxTransfer. The Gamma doc says
that the number is supposed to be the maximum number of _blocks_ transfered
during any one read/write. In fact, it's the maximum number of _bytes_
transfered. Easy way to test this (which is how I found out) is to set it at
4096 and run diskperf. You'll find the 4096 , 8192 and 32767 numbers all the
same. Also, I found NO difference in speed if I set MaxTransfer at a quite
high number or left that parameter out alltogether.
Don
What about the effect of max in program loading?
Ron
Ron,
I wasn't able to 'see' any difference. My quickie check was to time
the startup (lots of program loading). I never used a real low number
thou…and suspect it would slow down program loading.
I'll do some more playing tonight and let you know some exact values.
Don
Larry,
Be aware that some controllers limit the number of sectors allowed to be
transfered in one operation. As an example, (though it may not apply to other
controllers such as the 2090) the Western Digital WX-1 allows 256 sectors to be
transferred at once only.
Lloyd,
Yes, most published figures show the 32K buffer size numbers, but on all
of my diskperfs, I get between 2 – 3.5 times faster with 512 byte buffer sizes.
For me the directory scan speed increase is the one that I notice the most, and
again that shows 2 – 3 times faster.
I think you'll find, that after 1.3 and FFS becomes availiable, developers
will start to take advantage of the speed increases with larger buffer sizes.
ie. speed up picture loads. load the entire file into a ram buffer (if ram is
availiable) and the decompress and decode. That should speedup loads by about 5
– 10 times.
-Dean