199,409 users have contributed to 43,164 threads and 258,953 posts.
In the past 24 hours, we have 3 new thread(s), 10 new post(s) and 68 new user(s).
Hi,
Request for help from the disc experts!
I'm just formatting some hard discs and was wondering
a, Should they be formatted at 256k (highest block size)?
b, In x-bench what is the most relevant benchmark to look at to indicate performance is it Random uncached read 256k blocks?
This is to optimise for Vienna Instruments
Thanks for any advice.
Julian
Just did some tests - the drives are e-sata Samsung Spinpoint 1Tb (7200) with 32MB cache connected through a Sonnet 4 way SATA PCI Express card on a MacPro.
Uncached Read (Random) 4k 256k
1 disk 0.82 MB 36 MB
2 disk raid 0 1.36 MB 50 MB
4 disk raid 0 7.94 MB 336 MB
Uncached Read (Sequential) 4k 256k
1 disk 25 MB 113 MB
2 disk raid 0 23 MB 226 MB
4 disk raid 0 22 MB 323 MB
The 4 disc read speed appears to be over 4 times faster than a single disc, is that due to the 32MB cache? though the results are "uncached"
So would I be better Raiding or J-BOD? (I always back up my data so the increased possible failure rate of a raid is not too much of an issue.
Thanks
Julian
the raid vs. non raid question is not too easy to answer - too much depends on the behaviour of the raid controller which is poorly documented in most cases, so practical tests are finally the only method to decide.
first hand you should distinguish between two situations: a) initial loading (64 KB blocks) and b) streaming (16KB blocks) of sample data.... read mode is always random for sample streaming opposed to video streaming where it is sequential most of the time.
the default sector size on a single disk is 4KB - leaving the disk cache aside and assuming data on disk is not fragmented this means loading of 21-22 sectors for a) and 4-5 sectors for b) ... because starting point of a 16KB block must not be identical to the starting point of a 4KB sector.
formating a volume with 256KB sector size usually means most data is read from the disk (block-wise) but not used by the operating system.
when it comes to raid (mode 0 for striping) data is spread across 2 or more disks which means all disks have to position their heads over the right place on the plattern. usual block sizes for raids are 64 or 128 KB, cache behaving of the raid controller (not the disks!) differs between models.
in an example of a 4 disk raid 0 with a 64 KB block size this would mean for b) you read 4-8 x 64KB = 256-512 KB data but really use only 16KB ... now the raw data throughput on the raid is 4 times faster but the latencies and overhead is higher ...
remember: we don't have normal file access here like loading some photoshop file or even streaming video, we load little portions from within a large file ...
a test which has been done by a user with a high quality atto fibre channel raid (12 disks, 11 as raid 5 + 1 hot spare what equals to a 10 disk raid 0 for reading) configured with 16KB block size resulted in 10% longer loading times compared to a single sATA disk ... a result which almost had to be expected considering the above said ...
earlier models of Xraid actually had to be configured to not use the (raid controller) cache to allow at least some performance and everything depends on the raid controller if it allows *grabbing through* and requesting just portions of a file instead of starting heavy caching data which will be never needed ....
conclusion: tests like the one of the OP (if reliable) would only make sense with 16KB random read to tell us at least something.
hth, christian
Hi Christian,
Thanks for the info. I see what you mean about the load times and this supports what i found with a 4 disc raid that I had been using for the past couple of years - slow load times. However once we get into the streaming part (now the song is being played back in the DAW) does the raid now allow a greater polyphony? With my previous set up:
MacPro 3.2, 32GB RAM, 4 Disc (Apple software Raid 0, Western Digital WD4000KD) with 2 Disc Raid Boot Disc (everything backed up daily!)
I was very pleased about the simultaneous voice count so perhaps the Raid was contributing to this.
I also had thought about just spreading the samples across 4 discs without raid however I have significant audio tracks on some of my projects (the more audio tracks I run the lower the VI count so there isn't a conflict here) and don't want to have yet more discs just for audio.
So my current thoughts are to run 2x2 disc Raid 0. Split the Vienna Instruments across the 2 drives and transfer them first so they use the fastest sectors. i do have another drive that holds all my non VSL samples.
Generally I would prefer greater polyphony over load times so can you recommend an optimum sector size to try ?
Thanks
Julian
you are talking about a software raid (no raid controller present) what will in any case add load to the CPU and i don't know something about the used sector or block size ... my recommendation would be to stay with 4KB sector seize on single disks and just spread the content accordingly across drives if necessary ...
christian
Hi Christian,
Thanks for your further input. Wouldn't 64k block size be good on a raid. Set to this would ensure that the loading of each 64k sample header would not be spit across discs as each 64k would be on a single disc. (1st 64k on disc 1, 2nd 64k on disc 2 etc) so there would be no overhead (no need to access 256k to retrieve the 64 k header) Also by chance the sample headers (first portion of the longer samples) would probably be spread across the raid discs equally meaning up to 4 could be loading at the same time.
Something I didn't understand in your initial response was the block size of the streaming samples. The header, you say, has a data size of 64k (0.248 seconds at an uncompressed 24bit/44.1K data rate - though VI data is compressed yes?) this I understand. But you go on to say that "streaming (16KB blocks) of sample data" but the streaming file size will be related to whatever the length of the sample is i.e. a number of megabytes. This will be on the hard disc at the same block size as the header - in fact it is the same file isn't it? So I have some confusion when you say initial load 64k streaming 16k. Isn't it just one file all written at the same block rate determined by the striping block rate in the case of a raid 0, and the initial load just happens to load the first 64k. Even if the header files are separate files (are they?) these would be striped to disc at the same block rate as the full sample lengths so there would be no differential block size between initial load and streaming.... or am i missing the point somewhere!!
Thanks
Julian
the nature of striping (raid 0) is, that data to be written is spread across 2 or more disks, what happens in block sizes.
so writing 128 KB data on a raid 0 set to a block size of 64K having 2 member disks writes 64K to the first and 64K to the second disk.
vice versa with reading, means retrieving any data from this 128K needs both 64K blocks to be read (neither the controller nor the disk *know* where within those 128K the required bytes are located) ... it also requires to have the heads of both disks located over the correct position ...
this should illustrate why raid 0 is fast for consecutive writing or reading of large files, but not always fast if reading little portions.
loading vs. streaming block size: think of it like a buffer in an audio card ... you have to fill new data on the back before the buffer runs empty on the front.
audio cards or similar hardware usually divedes the available buffer size by 2, VI is dividing it into 4 sectors to allow some latency issues, which can occure if the harddisk is not immediately responding, what results in a sector beeing 16K.
of course when loading a patch the buffer is filled in one run, which is 64K
these numbers turned up to be reasonable with current hardware, choosing less (even only the half) results in a loss of available voices
hth, christian
So in the example of a single VI instrument playing from a 4 disc raid striped at 64k - On initial load 64k header is requested from disc. Does A reflect the situation or B !
A. Due to the 64k striping this portion only exists on 1 disc (if it is the exact first 64k data of the file) (if it was 128k it would be across 2 discs, if it was 256k it would be across 4 discs) so only 1 disc needs to be accessed and read.
B. As the file size of the whole sample is going to be well in excess of 64k it is written across all 4 discs almost regardless of block size (say using a total sample size of 3MB) So when initial load happens and the file is requested all 4 discs need to be accessed to create the file directory and thus retrieve the first 64k block although that actual block will only be on one disc.
I understand the principal of raid 0 and block size. files smaller than the block size go on 1 disc but the whole block size has to be read to retrieve files larger than the block size are spread across the discs in parallel so can be read simultaneously thus speeding transfer of larger files. What I'm struggling to understand is how this interfaces with the VSL streaming engine.
From your previous explanations my understanding is that the VI loads 64k initially then as soon as a note is played requests additional data packets to fill the buffer. These are requested in blocks of 16k. Now is it correct for each 16k requested a Raid 0 will have to send across 64k of data if this is the block size (and to locate this data 4 discs need to be read), so if the VI buffer requests 64k it asks for 4x16k blocks consecutively so the raid will read the same 64k block to provide this 4 times in a row! or does the computer understand the 2nd,3rd and 4th 16k data requests already exist in the system as they were sent in full to satisfy the first 16k block request. In the case of a long held note (non looping) is the data read off the disc as 1 large sequential file with all the potential benefits of raid or is it a succession of random 16k requests?
Thanks for your patience in helping to explain the complexity of disc access to a non expert! but I'm sure it will help me increase my (and others) understanding of the VI system and how it likes being fed!
Julian
unfortunately it is refelcted by B) - lets start with a single disk example ...
sector size is usually 4KB with modern OS and large disks ... now storing a tiny text file of say 200 byte requires 4096 byte space on the disk (one sector), storing a larger photoshop file of 1 MB requires 250 sectors, each of them fully filled ...
to read data an application asks the filesystem, the filesystem (or OS) asks the harddisk controller, the HD controller asks the disk.
for the text file a sector is read by the disk, the controller forwrads it to the filesystem which forwards the file to the application (2.000% overhead for reading).
for the larger file a (hopefully) consecutive number of sectors is read by the disk which will try to use intelligent read ahead using its cache, the controller forwards it to the filesystem, forwards it to the application (almost no overhead for reading).
obviously there is even more involved since the OS has to request memory space and store data there, but data can't be read faster than the pattern drives below the heads and one or more sectors can be read.
to overcome this limit of theroughput striping allows to write (and read) parallel on two or more disks which is done in blocks, usually 64K, but this works well only with multiples of 64K ... eg. 256K across 4 disks write as fast as 64K on a single disk (almost ...).
neither the application nor the filesystem knows something about which byte has been stored where. given the volume is formatted in 4K sectors (by the filesystem) it just knows it is somewhere within a 4 x 64K = 256K block which now needs to be read by 4 disks, forwarded to the controller, the filesystem, the application ...
imagine the overhead reading little portions and depending on the quality of the raid controller (if it allows to *grab through* or tries useless caching operations) the *felt* performance is better or worse compared to a single disk ...
hth, christian
Christian,
Thanks for being so generous with your time - and on a Sunday. One final question!
I understand now why you would recommend using 4 discs for VSL as separate single drives. Given that I'd also like to have a fast speed for copying large sequential audio and video files what block size would you choose to set up the raid in Apple's disc utility? The choices are 16,32,64,128,256k. I would run various tests but it takes so long to transfer all my files across after formatting that it would take a day or so per block size!
Thanks
Julian
