Hi Dietz,

thank for your fast reply. I did some testing, also with changing disk-drives (that took me some time...). I made some logs. My Configuration is now:

Drive C: dedicated 1TB HD
Drive D: dedicated 1TB HD
Drive E: dedicated 1TB HD

1. Copying a File from D to E

see screenshot of Win-Ressource-Monitor in http://dl.dropbox.com/u/3600096/picture_read_big_file.png

Data-Rate is expected at 80MB.

2. MIR when loading Konzertsaal-Impulse-Responses

http://dl.dropbox.com/u/3600096/MIR-Loading%20Impulseresponse.png

3. MIR a moment later, Impulse-Responses are ready, Samples are still be loaded in Background

http://dl.dropbox.com/u/3600096/MIR%20loading%20samples.png

What I see in case 3 is (please correct me if I am wrong):

Sample loading is at all with 10MB Datarate (instead of 80MB). But: There are many files accessed in parallel which means lots of seeking for my harddrive. That could be an explanation why its working with SSD but not with mechanical drives...

Am I wrong?

Best Regards,
            Tobias

Thanks again for taking the time to test this. As I said before, our developers are looking into it already.

Kind regards,

Hi,

I really don't want to push anyone - but I am interested... have you also seen the problem in your labs when loading libraries from "traditional" harddrives?

Best Regards,

                Tobias

There has been quite some effort form our developers to make loading as fast as possible recently:

-> [URL]http://community.vsl.co.at/forums/t/28664.aspx[/URL]

HTH,

@topse said:

What I see in case 3 is (please correct me if I am wrong):

Sample loading is at all with 10MB Datarate (instead of 80MB). But: There are many files accessed in parallel which means lots of seeking for my harddrive. That could be an explanation why its working with SSD but not with mechanical drives...

Am I wrong?

You are right, the prehistoric spinning drives with mechanical heads are limited by physics. The constant jumoping of the head while switching between samples to read, causes the read throughput to be substantially lower than during a sequential read operation. A figure of 10MB/sec is not uncommon.

10ms average seek time means 1s of pure seeking for 100 samples. Each sample uses 64kb precache. Reading 100 samples every second gives an average rate of 6.4MB/sec. Modern drives have some caching which allows the throughput to be slightly higher, but it is still hard to come above 15MB/sec with a "Spinning Jenny". SSD drives have no problem reaching 200MB/sec or above.

@MS said:

You are right, the prehistoric spinning drives with mechanical heads are limited by physics. The constant jumoping of the head while switching between samples to read, causes the read throughput to be substantially lower than during a sequential read operation. A figure of 10MB/sec is not uncommon.

10ms average seek time means 1s of pure seeking for 100 samples. Each sample uses 64kb precache. Reading 100 samples every second gives an average rate of 6.4MB/sec. Modern drives have some caching which allows the throughput to be slightly higher, but it is still hard to come above 15MB/sec with a "Spinning Jenny". SSD drives have no problem reaching 200MB/sec or above.

Which leads to the innevitable question of VSL software soon allowing users to change the precache in anticipation of SSD-based workstations, making it possible to run the orchestra without having to spend silly money on truckloads of RAM? Seek times are easilly 70-100 times faster on SSDs than HDs, IOPS is higher by ridiculous amounts and sustained transfer rates are now exceeding 500Mbps on SATA3, so my logic tells me it should be possible to do away with the requirements of all this expensive RAM we need to run proper sessions and templates. When MIR entered the scene it didn't really become better, since that (fantastic) monster gobbles GBs of RAM before you even load your first sample.

THAT would be good news to go along with the MIR Pro release...    along with an autosave function. [:D]

I already stated in another thread, that the next release of ViPro contains a setting for precache size, all the way down to 4kb/sample. My tests show it can play well even with that size, and a proper SSD setup.

@Vagn Luv said:

Which leads to the innevitable question of VSL software soon allowing users to change the precache in anticipation of SSD-based workstations, making it possible to run the orchestra without having to spend silly money on truckloads of RAM? Seek times are easilly 70-100 times faster on SSDs than HDs

Unfortunately you'll find that the money is even sillier for buying SSD, when compared with the "prehistoric" ones. [;)]

DG

Its a bit pitty that the requirements for the software (MIR) don't tell, that SSD is in fact essential... Will there also be a switch to increase cache per sample above 64kb?

SSD is not essential for MIR. AFAIK samples for MIR itself are loaded into RAM, so all an SSD would do is make loading faster. It's only the instrument samples that are streamed.

DG