Hard drive partitioning?

[mnowak67]

If I'm using a large (250GB) dedicated SATA drive for sample libraries, will I get any better streaming performance if the drive is partitioned into 2 or more sections as opposed to leaving it at 250GB? (I'm on a G5, by the way)

thanks,
Mike

[Bill]

Simply, no

[Herman Witkam]

If you've partitioned it and are accessing the data from two partitions at the same time the drive will spin just the same way (as far as I know), so no difference at all.

[Steve Rees]

It doesn't make any difference to streaming, but this is supposed to help with fragmented files isn't it? i.e. if your files fragment, it reduces 'how far' they can fragment. It also seems to make defragmenting faster.

Steve

[sullivang]

There is one aspect which may make a difference - the throughput available is the best towards the outer cylinders of the disk, so it may make sense to
try to put the heavy polyphony libraries as close as possible to the beginning of the disk. (lowest numbered partitions are generally towards the beginning)
Whether it is worth going to this effort for what is probably a very incremental benefit is debatable.

Greg.

[Daedalus]

I've heard of this technique being used before but I don't think it will have much impact with today's high speed drives.

One tweak you can make to both NTFS and FAT systems is to set the size of a cluster (the basic unit of file storage on a disk) from 1KB to 64KB in NTFS and FAT32, and from 512 bytes to 64KB for FAT16. Smaller clusters typically waste less space, because every file (even if it's only 1 byte long) uses at least one cluster and almost always leaves its last cluster only partly filled. However, PCs can read larger clusters more quickly, thus boosting disk performance!

[sullivang]

On a related topic, when an underrun *does* occur, it'd be nice if the application advised the user. (or for there to be the option to). I've noticed a few demos on rather prominent library developer's web sites that have clicks in the recordings. (Not sure what software was used to create the demos.)
For critical work, I'd like a great big red skull & crossbones to appear on the screen, along with a very audible alarm. ;) I don't think Giga advises the user if the disk can't keep up, does it?

Greg.

[sullivang]

That's very interesting - I didn't know things had changed in that respect - thanks for the info.

Here's a URL which indicates that it was, at least at some stage, like I describe:http://osr5doc.sco.com:1997/PERFORM/disk_IO_mech.html

I also clearly remember this behaviour being well documented in a commercial video server product - that video server explicitly put the primary video blocks on the outer cylinders (lower logical block numbers), and the backup mirrored copy on the inner cylinders. (higher logical block numbers)

But things must have changed now.

Greg.



I've bounced this idea off my brother who's a senior scientist for Seagate, and he dismissed it as being silly. According to him, the way data is "sprayed" onto modern multi-platter drives is complex, and does not really reflect what you see in disk usage graphs. In short, you can't fill up a disk in such a planned manner. It's not like cutting an LP.

Whenever I bring up this subjects he tells me not to worry about it. If I persist with further questions, he drops by with a huge stack of current technical data, research papers, trade journals and product specifications. I've learned to keep my mouth shut and have faith. If I don't, my trash recycler is going to kill me.

Lee Blaske

[sullivang]

I've just read that URL which I posted again - it actually says that for small transfers, the inner cylinders are better. ;) So it may actually be that the *inner* cylinders are better for soft synths, due to the fact that it's reading relatively small chunks of data (for all the different samples which make up the library/instrument). It also says that the blocks can be numbered starting from either the inner or the outer cylinders. (I had thought that the lowered numbered blocks always started at the outer cyinders.)

But yes, if that Seagate scientist is right (which would seem extremely likely ;) , and we now have no control whatsoever, then the whole discussion is moot anyway. (despite the fact that "if anyone should know, he should", I'm still a bit skeptical of his response, as you can probably tell. I'm sort of wondering whether he may have misunderstood exactly what I was trying to say, perhaps)

Greg.


That's very interesting - I didn't know things had changed in that respect - thanks for the info.

Here's a URL which indicates that it was, at least at some stage, like I describe:http://osr5doc.sco.com:1997/PERFORM/disk_IO_mech.html

I also clearly remember this behaviour being well documented in a commercial video server product - that video server explicitly put the primary video blocks on the outer cylinders (lower logical block numbers), and the backup mirrored copy on the inner cylinders. (higher logical block numbers)

But things must have changed now.

Greg.

[Waywyn]

You might get marginally better performance, but one thing you would NOT want to do would be to simultaneously use sounds from two or more partitions. That alone would put a crimp in the way you could use your samples.
Lee Blaske

Lee, i don't understand. Where is the difference if you play two different libs or sample from two different partitions or just playing 2 or 3 samples/libs from the SAME partition ?!?

[sullivang]

Oops - now I've done it. :) Re: the logical block mapping discussion - I invite the senior Seagate scientist to the thread which I've started in newsgroup comp.arch, titled "Hard disk architecture: are outer cylinders still faster than inner cylinders?".

Greg. (ducking)

[csduke]

It doesn't make any difference to streaming, but this is supposed to help with fragmented files isn't it? i.e. if your files fragment, it reduces 'how far' they can fragment. It also seems to make defragmenting faster.

Steve
Defrag will be faster but with dedicated sample drives you only need to defrag when you add/delete a lot of samples whoch is not that often for most users. Also, a partitioned disk may add some additional addressing overhead since there is an extra step involved in translating the Application's disk request into the actual disk sector/address.

[Mark Trainer]

The main reason one wouldn't want to partition a drive into multiple partitions and then store a different library on each partition is that you're forcing the read/write head to now travel farther as it has to hustle from one partition to the other in an effort to meet provide streams from both libraries. If you were only using sounds from one library (partition) at a time then it shouldn't matter.

To the fella who wanted a skull and crossbones when buffer-underrun was encountered- I agree 100%, I'd like to know if the new Gigastudio provides any sort of feedback (other than clicks and pops) when this situation is happening. Ideally I'd also like to see the number of simultaneous voices that were being played displayed somewhere so I could get a handle on just how many voices my system can handle before dropouts occur. Obviously the software has all this info- it just needs to display it.

And while I'm rambling, I've often wondered why a RAID 0 config for gigastudio is really an advantage when it seems the data chunk being pulled in from disk is usually smaller than the stripe size anyway.

Mark

[Waywyn]

The main reason one wouldn't want to partition a drive into multiple partitions and then store a different library on each partition is that you're forcing the read/write head to now travel farther as it has to hustle from one partition to the other in an effort to meet provide streams from both libraries. If you were only using sounds from one library (partition) at a time then it shouldn't matter.

Mark

thanks mark, for clarifying this. next time i know better :)

[Miguelo Adorno]

Then how about streaming audio tracks from another partition? Or is it better to dedicate separate drives for audio and samples? Especially if both would use own SATA busses.

- Mikko

[Waywyn]

but also people say, that it is not good to have the system files where you record audio or have samples.

so let me check:

- one HD: one partition for system
another partition for programs

- one HD for samples

- one HD for audio

that's three harddrives. usually you have 2 ata ports so it means you can attach 2 HDs, then you have dvd/cd and burner. how should i integrate three drives in my setup if i have two ports?

[Miguelo Adorno]

that's three harddrives. usually you have 2 ata ports so it means you can attach 2 HDs, then you have dvd/cd and burner. how should i integrate three drives in my setup if i have two ports?

In most motherboards today there are also 2 Serial ATA ports, which are much faster than normal ATA ports. So if I've understood correctly ideal setup would be:

- 1. ATA port: System + apps HD
- 1. Serial ATA port: Sample HD
- 2. Serial ATA port: Audio HD

- Mikko

[gstern]

Exactly how would I set the cluster size on my NTFS drive to 64K?

Gabriel

[sbkp]

Exactly how would I set the cluster size on my NTFS drive to 64K?

Gabriel

As far as I know, you have to do it when you format the drive, under "Allocation Unit Size." In my copy of XP, though, my only options are 512 bytes, 1K, 2K, and 4K.

- Stefan

[newmewzikboy]

You have to go to the COMMAND line prompt and do it there with the DOS FORMAT command. There are command line options for sizes that exceed what XP Windows will allow

[maszat]

If you own PartitionMagic then you can change it on existing partitions too.

Kornel

[Crystal]

Also, a partitioned disk may add some additional addressing overhead since there is an extra step involved in translating the Application's disk request into the actual disk sector/address.

Interesting point.

I never thought about this. Anyone can confirm this ?




- one HD: one partition for system
another partition for programs

- one HD for samples

- one HD for audio

that's three harddrives.


Four.

If you don’t use a Raid 1 on your audio drive, I say good luck to you.

The dead drive is only a myth.

Till it appends to you...

(Like it appended to me...)




To the fella who wanted a skull and crossbones when buffer-underrun was encountered- I agree 100%, I'd like to know if the new Gigastudio provides any sort of feedback (other than clicks and pops) when this situation is happening. Ideally I'd also like to see the number of simultaneous voices that were being played displayed somewhere so I could get a handle on just how many voices my system can handle before dropouts occur. Obviously the software has all this info- it just needs to display it.


On Giga, clicks and pops don’t depend only of the number of voices, but also the way they are solicited.

You can for example add 350 voices successively without problem but have a big one if you call all of them at the same time with a cluster (on tracks, for 350 voices !). So a warning system is probably a complex equation to build for a sampler (with a lot of local parameters), and will necessary affect the latency.

Personally, I prefer to use only my ears as a warning system with a low lacy sampler and / or more polyphony, instead of using a sampler which visually warn me (I never look my screen when I play...), and will also possibly block the polyphony with missing voices in my mix, with less polyphony in some situations and a worse latency.

We don’t have to forget that audio applications are very specific cause they are the only one which have to care about latency.

Cause we record in real time.

Even the video montage doesn’t need to work in a perfect real time. Cause an editor doesn’t record anything. He only build his track.

And anyway, I would easily bet that there is only in audio forums that the ‘latency’ word is used. Other applications don’t really care about this exigency.