On Dec 21, 2004, at 7:55 AM, drK wrote: > Partiton 1: Audio - less than 25% of the total drive size. > Partition 2: System - bigger than 10GB but keep the total of this and > Audio less than 50% of the drive. > Partition 3: Data - rest of the drive. This is where you store your > sound libraries, non-streaming samples, projects when not in active > rotation, email, documents, etc. (this is a re-post with the appropriate heading) drK, Thanks a lot for all of this useful information, I'm going to use this approach for my G5, which I'm setting up this week. I would like to ask another question regarding this method of partitioning. I'm wondering about the partition for the sample libraries. EWQLSO Gold strongly recommends a dedicated drive for their library. I'm sure this is a good idea but I'm wondering if it's OK to put other libraries on that same drive as long as they are not being used in that same project. Will it slow the access time down just by the mere presence of data, or does the data need to be actually in use? I hate to buy these big drives and then have a lot of the space sitting there unused. So for instance, if this were true, I could put one large orchestra on the outer platters and fill the remaining space up with storage and the performance would not be affected. Or perhaps it would be better to partition this one drive in the same way; outer portion for Orchestra, inner for Storage. Do you (or anyone) have any thoughts about this? Thanks Michael Telle

On 03.01.2005, at 07:42, Michael Telle wrote: > On Dec 21, 2004, at 7:55 AM, drK wrote: >> Partiton 1: Audio - less than 25% of the total drive size. >> Partition 2: System - bigger than 10GB but keep the total of this and >> Audio less than 50% of the drive. >> Partition 3: Data - rest of the drive. This is where you store your >> sound libraries, non-streaming samples, projects when not in active >> rotation, email, documents, etc. > > (this is a re-post with the appropriate heading) > > drK, > > Thanks a lot for all of this useful information, I'm going to use this > approach for my G5, which I'm setting up this week. I would like to ask > another question regarding this method of partitioning. Why are you doing that? A partitioned disk is not fast, it might even be slower. Get a second disk. Please :) Peter Ostry

At 8:39 Uhr +0100 03.01.2005, Peter Ostry wrote: >Why are you doing that? >A partitioned disk is not fast, it might even be slower. Get a second >disk. Please :) There is one distinct advantage to having the system on it's own partition: If the system goes south you can just format that partition and put a new system on it without loosing data. Not as necessary anymore than it was in OS 9 times, but still a little reassuring. Looking at the performance you are right about loosing performance. Cheers Hans

>>> Partiton 1: Audio - less than 25% of the total drive size. >>> Partition 2: System - bigger than 10GB but keep the total of this and >>> Audio less than 50% of the drive. >>> Partition 3: Data - rest of the drive. This is where you store your >>> sound libraries, non-streaming samples, projects when not in active >>> rotation, email, documents, etc. >> >> drK, >> >> Thanks a lot for all of this useful information, I'm going to use this >> approach for my G5, which I'm setting up this week. I would like to >> ask >> another question regarding this method of partitioning. > > > Why are you doing that? > A partitioned disk is not fast, it might even be slower. Get a second > disk. Please :) > > Peter Ostry Hi Peter, Well I'm not quite sure what you're referring to here. It has never been proven that a partioned disk is slower than a non-partitioned one. (to me, at least) A lot of people have opinions but I'm going to need to hear a little more factual discussion before I make up my mind on this issue. In fact drK's supposition makes sense to me. If you partition and have the audio (or samples) only access the outside of the platters, you stand to gain almost double the access time than if the same data were accessed from the inside platters. In this approach you use the inside of the disk only for non critical storage. The system partition is the second from the outside thus cozying up to the audio partition and cutting down the amount of head movement necessary. If you don't partition, at some point you will be needing to access audio from the inside of the disk while your system partition is clear on the other side, making it necessary to travel back and forth across the whole expanse. That seems to me about as bad a scenario as possible. But again, I don't know for sure. I'm just trying to piece a strategy together without knowing for sure where the truth lies. I'd love for someone to be able to explain all this with facts and numbers rather than conjecture and anecdotal evidence. Cheers Michael Telle

--- In logic-users@yahoogroups.com, Michael Telle <telle@s...> wrote: > I'm wondering about the partition for the sample libraries. EWQLSO > Gold strongly recommends a dedicated drive for their library. I'm > sure this is a good idea but I'm wondering if it's OK to put other > libraries on that same drive as long as they are not being used in > that same project. Will it slow the access time down just by the > mere presence of data, or does the data need to be actually in use? Howdy Micheal Basically how much stuf can you shove down a pipeline with a limit in data flow? If you are reading & writing whilst running many apps how much pipeline is each going to get? What does make sense is to separate the data flow especially for your audio. You dont want anything accessing your audio disk whilst recording other than audio coming off, but if you have audio apps accessing as well as system software running in the background then you are going to limit performance & possibly have glitches in your recording. I have songs, samples, vst banks all running of one drive with apps running on another. The extra space is not as detrimental as restricted read/write speed. I am about to install another drive to stream video from, being a large amount of data high speed disk access is a must. This is one of the basic requirements of a computer based audio system. There are many more tweaks to make your system run more effectively in the realm of audio production but this is a main one. Hope this helps Regards Richard

On 03.01.2005, at 09:26, Michael Telle wrote: >> Why are you doing that? >> A partitioned disk is not fast, it might even be slower. Get a second >> disk. Please :) > > Well I'm not quite sure what you're referring to here. It has never > been proven that a partioned disk is slower than a non-partitioned one. > (to me, at least) A lot of people have opinions but I'm going to need > to hear a little more factual discussion before I make up my mind on > this issue. > ... You cannot be sure that it is slower, right. But you can be sure that it is not noticeable faster. Logic wants disk access, EXS wants to stream, the system wants to swap, not to mention other applications you might run. Everything goes over one bus. Not to mention poorly programmed applications. When it comes to speed we don't have to talk much about head movements. Our problem is, for example, synchronous reading: an application wants THAT data chunk NOW. Point. Do you know which one? No? How do you calculate the way of the disk heads? We deal a lot with optimization on our database servers and everytime we set up a new machine our (very good) admin starts the discussion again :) But we do not longer deal with peanuts, I mean microseconds. To get remarkable better performance you can stay a couple of levels higher: Lower the bus traffic: put a second disk on a different bus. Release the processor: give more RAM to reduce swapping, use SCSI disks. Not enough? Run a RAID. Preferable SCSI. More? Involve other machines as slaves. Even more? Build a cluster... > But again, I don't know for sure. I'm just trying to piece a strategy > together without knowing for sure where the truth lies. I'd love for > someone to be able to explain all this with facts and numbers rather > than conjecture and anecdotal evidence. I found an easy to understand and short text here: http://silverwraith.com/papers/freebsd-tuning.php And here are some snippets: --- Optimizing the the disk subsystem on FreeBSD... 1. RAID: ...With RAID1 (also called mirroring), ... speed advantage from RAID1 comes when reading ... Writes are no faster than on a single disk... RAID0 (also called stripping) ... your throughput and your maximum disk operations relative to the number of disks you have. For example, 4 disks would give a 400% increase. 3. Partitioning: Having separate partitions on separate disks can help a lot. For example, your system will always be performing different tasks at any one given time: writing log files, serving out data, and so on. The Unix directory structure is built around using different directories for partitions for different purposes ... Arrange these on different disks to best suit your needs. If you have disks of varying speeds on your system, place the most frequently used partitions on the faster disks. 4. IDE vs SCSI: ...and the much sought after disk sizes and faster throughput's are now available on IDE disks. SCSI disk sizes have also grown but not as fast. SCSI disks still offer faster throughput's however. At the time of writing, the fastest IDE interfaces could push 133Mbyte/s, whereas the fastest SCSI interfaces could push 320Mbyte/s. --- Peter Ostry

On Jan 3, 2005, at 7:07 AM, Peter Ostry wrote: > > You cannot be sure that it is slower, right. But you can be sure that > it is not noticeable faster. Logic wants disk access, EXS wants to > stream, the system wants to swap, not to mention other applications you > might run. Everything goes over one bus. Not to mention poorly > programmed applications. > > When it comes to speed we don't have to talk much about head movements. > Our problem is, for example, synchronous reading: an application wants > THAT data chunk NOW. Point. Do you know which one? No? How do you > calculate the way of the disk heads? > > We deal a lot with optimization on our database servers and everytime > we set up a new machine our (very good) admin starts the discussion > again :) But we do not longer deal with peanuts, I mean microseconds. > To get remarkable better performance you can stay a couple of levels > higher: > > Lower the bus traffic: put a second disk on a different bus. > Release the processor: give more RAM to reduce swapping, use SCSI > disks. > Not enough? Run a RAID. Preferable SCSI. > More? Involve other machines as slaves. Even more? Build a cluster... > Multiple drives can offer better performance, provided they are properly setup and the system can handle the concurrent disk I/O. SCSI excels at this, ATA does not. RAID configurations offer marginal, if any, performance improvements unless the drives are controlled by a separate HW raid controller. In all cases though if one places data towards the center of the drive it will be transferred slower than data at the outer part of the drive. This is the physics of current HDD technology. Minimizing head movement is important in typical DAW usage. Two factors limit how many chunks of audio can be playing at the same time: the transfer throughput from HDD to RAM buffers, and the time it takes to step from chunk to chunk on the HDD surface. Often it is the step time and rotational latency (waiting for the data to come around to the heads once the heads are on the correct track) that ends up being the critical factor. This is especially true for audio files with a lot of edits. The step time limitation can be overcome somewhat by having larger track buffers in RAM, and more lookahead disk reading, but this comes at the expense of longer delays from pressing play to hearing the sound. If you restrict your data to a smaller area of the HDD head performance will always be improved. Modern OSes do a good job of minimizing head movement but you can help them by restricting where the data is placed. Of course if you have many applications all doing HDD access at the same time then the advantages of restricting where the data is located become diminished to the extent that different partitions are "in play". But this is not a typical situation in a DAW. You should have adequate RAM to eliminate unnecessary swap activity, and unrelated background activity that is pounding the HDDs is just not good practice. If you control the data placement for the DAW-related activity predictable performance is achieved, and in this case partition helps a great deal. Regardless, the raw transfer performance of the outer cylinders is always nearly 2X faster than the inner ones so at least important data can be restricted to where it can be retrieved quickest. So the conclusion is pretty straight forward. Use multiple drives if you can, and your system can truly take advantage of the extra drives. Always, whether using one or multiple drives, partition the drives so that you can control where the data is placed, and to minimize as best as possible head movement. Outer cylinders are always prime locations for data that must be streamed quickly. Finally, one *should not* attempt to design an optimization strategy for a DAW HDD system based on the practices of other apps like databases. The use profile is quite different. The OS itself will make a difference (i.e. Windows principles don't necessarily apply to OSX, and in spite of its UNIX underpinnings OSX is different that other varients). Many of these end up doing little good, and sometimes makes things much worse! drK

On 03.01.2005, at 16:51, drK wrote: > ...RAID configurations offer marginal, if > any, performance improvements unless the drives are controlled by a > separate HW raid controller. ... Yes, I forgot to mention that. If you need speed thanRAID without a dedicated hardware controller (outside of the computer) is not worth the effort. > ...Outer cylinders are always prime locations > for data that must be streamed quickly. I know only from Solaris, they have the swap partition in the outer area and I won't change that because the SUN swaps a lot. What about the Mac? Peter Ostry

> >> ...Outer cylinders are always prime locations >> for data that must be streamed quickly. > > I know only from Solaris, they have the swap partition in the outer > area and I won't change that because the SUN swaps a lot. What about > the Mac? > > > Peter Ostry > OSX does not use a separate swap partition but rather instead places swapfiles on the system volume. Furthermore "out of the box" the system volume is one large partition that consumes the entire hard drive. Swapfiles are created on demand, and after every reboot they are "reborn". So as the single partition files (which it will since it also contains user data, iTunes library, etc all by default) the swapfiles tend to be placed closer and closer to the HDD's center, and as a result swaping performance degrades. Apple decision to do this was to make OSX easier to use and maintain but one has to wonder... drK drk.iuma.com

--- In logic-users@yahoogroups.com, drK <drk@d...> wrote: > OSX does not use a separate swap partition but rather instead places > swapfiles on the system volume. Yeah, what were they thinking? They could have used a dedicated partition and just made it invisible to the Finder. It is completely possible to use a dedicated partition for swapfiles. This has the advantage that if you do run out of swap space (increasingly likely if you go a long time between reboots), the swapfiles won't start overwriting anything, as can happen with the default setup. See http://www.math.columbia.edu/~bayer/OSX/swapfile/index.html for a GOOD discussion and instructions - this requires some minor Unix hacking. I've been using this method to put the swapfiles on a scratch partition for some time now, with no issues at all. John Pitcairn ------------------------------------------------------------- Logic Control emulation for generic midi controllers: LC Xmu demo: http://www.opuslocus.com/lcxmu/ -------------------------------------------------------------