Re: Good settings for BlockRead
- From: "Terry Russell" <trochilus@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 23 Aug 2005 15:18:17 +0930
"Jud McCranie" <youknowwhat.mccranie@xxxxxxxxxxxx> wrote in message
news:8eqeg15jqdv8rgq5tdr5p6uoo6hfib1bq8@xxxxxxxxxx
> On Sun, 21 Aug 2005 01:50:36 +0930, "Terry Russell"
> <trochilus@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> >Your transfer reading, are you sure you are comparing oranges,
>
> I hope I'm comparing accurately. I defraged the disk and rebooted
> before each test to clear out the disk cache. But I don't know where
> on the drive the system put the file.
>
> > and what does HD Tach measure ?
>
> HD Tach is a neat free program for testing disk speed. It has nice
> graphics showing how the speed varies with location:
> http://www.simplisoftware.com/Public/index.php?request=HdTach
It needs an install, and doesn't give anything other noinstall tests show.
It measures raw low level speed, but you are going through the OS.
HdTach says 72 burst 64 max
Another much simpler app says 71 burst 62 max
with 512meg memory memory and a 2 gig file using blockread
( that should clear the cache :-) )
for 512KByte blocks I get 33Megabytes per second average
for 16meg blocks I get 65 MBps average, much the same for 64 meg blocks
The interesting this is that if I force 300 mb of physical ram free
before reading I see 61 mbps until free ram is gone for 512k block and up
which implies the OS cache shuffling may be the biggest bottleneck
on small blocks
[ this is where some of those memory manages can improve apps that
otherwise thrash the HD with small page/read cycles, unfortunatley if
every app tried to manage ram you could be sure there would
be some sort of catfight ]
The advantage of this cache is rereading then has a few 100megabyte bursts
at 200+ mbps as it reads from cached data while the bulk still
averages at the 33MBps range,
same for 64 meg block but 62MBps for off disk portions.
Bursts far beyond the average can be ignored as cache noise if you want to
get a quick and reasonably accurate data rate test without the need to
reboot.
For long strips rereading the OS tends to keep this first 300 MB in ram and
not
flush as more data from the same file comes in with same priority, random
access
progressively retains the most used blocks.
It depends on OS and hardware but with memory so large and cheap and the
machine running one primary application the OS should contrive to keep most
of the data for a large number of records in memory without any application
control or much advantage in tweaking blocksizes.
Rule of thumb blocksize 1/16 of RAM should keep the OS cache/drive cache
in a reasonable zone for P150 to P3000.
Back in the dark ages of 1990 600KBps was a good speed for a $300 40MByte
drive on a 2Meg RAM 386 33MHz costing $2500.
Tweaking was worth it then and predictable, the OS didn't presume to do much
and usually only one primary app was resident at a time.
Now you can get 60MBps off a 40G HD into a 512MBRAM 2Ghz P4 for $300
and cannot predict what the OS will do with your data in relation to the
other
apps that may be running.
Static tweaking effects are not predictable.
And for all this , 1000 times more storage, 200 times more RAM, 100 times
faster
CPU, for 1/10th the price, how much more can we do?
If the problem is digital we go from 'not-enough' to 'enough' at some point,
if we
have reached 'enough' then there is little profit in expending effort in
further improving
the process.
Instead of faster disk access maybe a better help system would be of more
benefit?
.
- References:
- Good settings for BlockRead
- From: Jud McCranie
- Re: Good settings for BlockRead
- From: Terry Russell
- Re: Good settings for BlockRead
- From: Jud McCranie
- Good settings for BlockRead
- Prev by Date: Re: Creating controls and forms at run time
- Next by Date: Re: Good settings for BlockRead
- Previous by thread: Re: Good settings for BlockRead
- Next by thread: Re: Good settings for BlockRead
- Index(es):
Relevant Pages
|
