I'm configuring a new RAID 0 for my sample libraries and wondered if anyone could make a recommendation regarding what would be the best block size for this application. (Mac OS 10.4.5/dual 2.5GHz G5/7GB RAM/Logic 7.2). I would be most appreciative of help with this.Thanks.
-
Best Block Size for sample libraries?
-
If you are writting lots of small files then a smaller block size gives a more efficient use of space but as all sample files would be considered, in this contex, (particularly the VI .dat files!) to be larger files a larger block size should give you a higher transfer speed.
Unless you are going to store non audio files on the disc i would consider using the largest block size availabel.
Julian
-
for raid controllers 64 kB is the default and i'd keep this value for best performance. you can play around with the size for testing, but i bet no other value will perform better.
also i'd switch off any caching option because the portions of requestd data for streaming are tiny and any caching (of larger portions) is basically contraproductive. eg. the Xraid brings real advantages only with switched-off caching.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Hi Christian,
I'm interested if you will expand on your Raid experiences! I know in the past you have had reservations about Raid drives.
This quote :
http://www.pcguide.com/ref/hdd/perf/raid/concepts/perf_Stripe.htm
"Decreasing Stripe Size: As stripe size is decreased, files are broken into smaller and smaller pieces. This increases the number of drives that an average file will use to hold all the blocks containing the data of that file, theoretically increasing transfer performance, but decreasing positioning performance.
Increasing Stripe Size: Increasing the stripe size of the array does the opposite of decreasing it, of course. Fewer drives are required to store files of a given size, so transfer performance decreases. However, if the controller is optimized to allow it, the requirement for fewer drives allows the drives not needed for a particular access to be used for another one, improving positioning performance."
From a file size point of view as the .dat files are so large won't they be spread across all drives in a RAID regardless of block size? Also I use my RAID (4x400GB SATA 2) to capture audio as well - the level of audio use is inverse to the level of sample use so it makes sense to use the same disc - does using the RAID for large audio files have a bearing on the cache - my discs have 16MB x 4 so that is I guess a fair size but I'm not sure if there is an option in the Disc Utility (Mac)software RAID to disable the cache.
Thanks
Julian
-
ok, software raid, some details might not apply. to switch off caching of a disk you need a utility (and i'm not aware for the moment of one for OSX).
a software raid does not depend on a (raid-)controller and therefore no need to switch off any caching of a controller.
the given example on the page you linked is not relevant for VSL - the files are 512 MB, so they get spread across all added drives anyway. basically we have good results with software raid-0 (stripes) - i don't have a mac with enough drives at my hand currently, but i'd leave the settings at the default value (they should know which default value is the best for OSX), if no default available then 64 kB.
drives which are members of a raid-0 should not be partitioned and ideally of the same size and even same type (that's what you have obviously)
also remember, that streaming apps request portions of 64, 128, 256 byte (basically the number of bytes it needs to refill the buffer of the soundcard) so any block-size setting would have minor influence - the most important capability of a drive would be NCQ, and this is what sATA2 drives should all have per definition.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Christian,
Thanks for the response - just so I understand what the Vienna instruments do is it as follows:
The first 64k of every single sample required for an instrrument is loaded (so for 40,000 samples -near the current limits - its 2.56GB. But it's 2.56GB loaded in 40,000 individual chunks - hence the elongated load times in relation to total data size?
When the instruments are played the moment the VI recongizes a sample has been activated it calls up the additional sample data beyond the 64k. So for example a 6 note chord would be calling up 6 data streams from different parts of the same .dat file.
The huge number of samples required per VI matrix does mean load times and RAM requirements are high. Once the midi is fixed there is RAM optomisation but this does not appear, to me, to be that different (except perhaps still being able to alter attack and release times) from actually freezing the track. I wonder if there could be some halfway house to improve the flexibility vs load time equasion.
One example might be that you could set the Vienna Instruments preference to recognize the key signature on insertion so only the required samples were loaded. Yes you would loose the ability for accidentals and key changes but for a lot of tracks this could speed up things and where the full set of keys were required the preference could just be set to off.
Julian.
-
julian, we've been talking about the method data is stored on a raid. the ViennaInstruments need far less byte for preloading (i don't know how many exactly - 512?). what you are describing is basically realized with the optimize method, which removes unused samples of a *learned* sequence - see also the last video here
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Christian,
I was actually referring to the VI optomise process (fairly similar in affect to freeze as to susequently change your score you would need to load all the samples again - (unless you played a different combination of the same notes!) when wondering if there could be a half-way house - the example I was suggesting was optomize to key.
Julian.
