Frage von DSLR-Freak:CS5 Premiere: New rules for the hardware!
"AVCHD-border systems' hard disks & Setup Introduction: At the premiere CS5 CUDA-enabled graphics card has a great influence on the performance and reduces the load on the CPU. The GPU does some of the work. As the CPU gets more room to breathe, the CPU is no longer the primary Bottelneck synonymous, as was usually the case in the past! Principle: expanding RAM -> Minimum 12 GB for costly "AVCHD-border systems,"
New bottleneck is the hard disk setup: AVCHD footage: The forward-and backward-scrubbing means a lot of work / activity on the hard drive. That is especially the bottleneck when several (; AVCHD -) signs to be drawn on the plate in the memory (and therefore synonymous large RAM).
The nominal bandwidth and data rate of the SATA2 or SATA3 usually suffices no longer, by several AVCHD - or other MPEG streams performant play. Tests have shown that significant performance gains by a large number of disks that can be achieved preferably by a RAID system. This is especially true if several hard disks are implemented.
SSD's are no-cost alternatives to conventional hard disks (; price factor of 30 higher). Otherwise, SSD is a high-performance alternative dar.
The following rules apply so for conventional hard disk systems:
Rules for HD setup: This is the crucial question of the configurations are often suboptimal in many areas!
Usually "0": Only hard disks 7200 RPM or faster use types. No
green disks!
Rule 1: Create,
NEVER Why? The operating system must be otherwise for all requests on a first partition table s.Anfang go of the plate. The heads move back and forth. This means a lot more wear and tear, lower speeds and more work for the operating system.
Rule 2: No USB - (; 2.0) drives
... because they are the slowest on the market. Stay with SCSI or SATA hard disks or e-SATA. This has changed somewhat with USB 3.0. Problem is that USB claims the CPU. This can use at Videoeting but None. They are actually better suited for backups as for editing.
Rule 3: Use at least 3 different physical drives on a workstation (; see chart)
... one for OS / Programs, one for media and one for swap file / scratch / rendering. Even on a
laptop with an internal drive, it is easy with the help of a dual e-SATA port Express (card) to drive;. This gives an additional two e-SATA ports for external hard disks.
Rule 4: Distribute the requests of so many hard disks as available
If you have OS and Programs on the hard drive C, you set the paging file to another disk. set page file to a fixed size s.Besten, somewhere in the 1.5 times the physical memory.
Rule 5: Index Search and off compression.
Rule 6: If single SATA hard disks about 60-70% full, it's time to get a bigger or additional hard drive to get.
Rule 7: regularity & szl
Antwort von Jörg:
the good Harm ...
only what is new s.seinen Tips?
Basically, back in 2000 my machine looked so aus.Natürlich without SSD, but with RAID, 4 then disgustingly expensive scratcdisks etc. ..
The number with the swapfile see the guys leave the way in which I build quite different. For me it is normal at SSD.
They have only smiled when asked if this is useful. Time will tell.
Antwort von DSLR-Freak:
The number with the swapfile see the guys leave the way in which I build quite different. And that's why you have guys selling again soon tumble.
They have only smiled when asked if this is useful. And then Clint Eastwood came in and said to yourself: "Let us do, baby."
And all of them just smiled ...
and then ... You're awake.
So seriously:
I wanted to take up this topic to one or the other to help with configuration. The topic eventually comes up again and again. Now would not have thought that the very first commentator is so cool.
In support:
http://www.slashcam.de/artikel/Test/CS5-Files--Teil-4---After-Effects---Multicore-and-RAM.html
Antwort von Jörg:
I wanted to take up this topic to one or the other to help with configuration. The topic eventually comes up again and again. is indeed very commendable, but your title suggests new findings, but then only the well-known, and of many serious people who are long-used.
The observation with the dryer then we won as a joke sometimes ... the boys know exactly what they do ;-))
Antwort von Frank B.:
@ DSLR-Freak
Hm, I'm not the big PC Freak - I actually know very little of it, which I should like once synonymous excuse the simple question:
The data rates are not higher than AVCHD DV - Video. So why a RAID system for speed increase? For data security, it stands to me. A good SATA drive would still loose for 5 - 10 range AVCHD streams. Clear to me is synonymous to use for system, data and video files more separate non-partitioned hard disks. But must it be a raid now?
And what is with USB 3 - hard disks? That is missing in your statements above. I would put it in with a series with eSATA, right?
Antwort von tommyb:
The nominal bandwidth and data rate of the SATA2 or SATA3 usually suffices no longer, by several AVCHD - or other MPEG streams performant play. Tests have shown that significant performance gains by a large number of disks that can be achieved preferably by a RAID system. This is especially true if several hard disks are implemented. The limiting factor is the bandwidth of SATA, as SATA 1 already provides as specified 150 Mb / s. That would be 1200 Mb / s and can be theoretically enough to play the same 50 24-Mbit AVCHD sources.
The limiting factor is in fact the hard disks (; not the interface), as these create only "files s.Stück" a read / write speed of at least 100 Mb / s. The performance synonymous bent but only because one, because the plates are in simultaneous access extremely slow just because the head will not come after (; why SSDs are here synonymous far more suitable - synonymous to it to place the swapfile).
Only one RAID can remedy the situation because - depending on the RAID level and the number one then creates s.Platten synonymous to play with several times of the streams.
Antwort von Frank B.:
The limiting factor is in fact the hard disks (; not the interface), as these create only "files s.Stück" a read / write speed of at least 100 Mb / s. 100 MB / s. would apply to about 20 - 30 AVCHD-rich streams, or what I see as wrong?
Antwort von RickyMartini:
In H.264, however, limited the board only if it is older - but more problematic is the CPU! A current SSD is far superior to any HDD in terms of particular parallel requests and access times.
I know of no board announced that it would allow enough 6Core take i7 CPUs that reflect about 30 H.264 streams without Dropped frames in real time to!
The CPU would not schonmal be able to lead a fleet HDD to the limit, if they would have to decode multiple H.264 streams, as they already "seal off" would.
Antwort von DSLR-Freak:
Finally get the issue some way.
The CPU would not schonmal be able to lead a fleet HDD to the limit, if they would have to decode multiple H.264 streams, as they already "seal off" would. This is just not right.
You can visit the following test statistic for CS5 to. Pays particular attention to the hard drive configurations.
http://ppbm5.com/Benchmark5-1.html
Is instructive, not only the issue concerning HD.
Antwort von RickyMartini:
Thanks for the info! The benchmark I'm going to perform with my SSD and HDD.
Antwort von DSLR-Freak:
Another important link to disk configuration: http://forum.slashcam.de/download.php?id=4714
Antwort von tommyb:
100 MB / s. would apply to about 20 - 30 AVCHD-rich streams, or what I see as wrong? If you would all be played after each other - maybe.
Perhaps something can be described s.einer Highway:
Suppose we have a highway with a total of 20 tracks. These 20 tracks represent our individual AVCHD streams. At the end of the highway there is a constriction - passport control or anything. There are there only 4 switches, ie, the cars of the 20 tracks to squeeze through the 4 switches. Of course, like front and rear, not - it forms a traffic jam and the cars come only very slowly.
The bottleneck is the switch. The switches are symbolic of the heads of the disk. The panel has only a limited supply, and the heads can not make the same 20 files so fast that they can be played in real time. That is, the appetizers always read heads, these 20 tracks, they work good after the order. Are the heads up but ended up with track 1, but more time elapsed than is allowed. The head is ready to read Frame No. 2, of the time since he had to deliver but Frame No. 5.
From here starts the system slow down and see at the speed drops to the basement.
To compensate, one can either reduce the size of the packets (; sector size) or increase but the number of simultaneously operating heads. The latter happens when the RAID. With a RAID 0 of two plates one could therefore theoretically double the number s.arbeitenden heads, ergo would also increase the data throughput. Similarly, you can rely on faster disks (; example of WD Velociraptor).
Effective get there with an SSD out of this thing. There are no moving parts that have a speed limit for physical reasons - so the work is synonymous with SSDs much faster. The best example is the program starts - for example, there is very many small files are accessed simultaneously.
Antwort von Frank B.:
Thank you for this beautiful tommyb, the layman catchy statement.
If the video data are available, but on several separate hard disks, but would then increase the total throughput synonymous, synonymous with no raid.
I think after your explanation, a raid might make sense if someone absolutely compositions with 50-10 layers, or it must make real-time, or working in data-intensive codecs on several tracks. For AVCHD neck of the bottle should really be more of the processor. Thus, on my relatively weak system easily more than 5 tracks in DV quality possible with AVCHD I do not come to this region, although both codecs have similar data rates.
Antwort von tommyb:
If the video data are available, but on several separate hard disks, but would then increase the total throughput synonymous, synonymous with no raid. That's right - but falls in this solution because eight of the comfort you need to always ensure that you spread the material all uniform. This unnecessary "thinking" you do not need a RAID system.
A RAID system actually makes more sense, because the one you have for some RAID modes in addition to increased speed or data security synonymous - also you are always prepared for a possible more complex projects. If today's Project with its four streams is still reasonable, the next major project with eight streams not just torture to be the case and you have to with jerky playback or unnecessarily long render times, because the processor turns thumbs and waits for input.
AVCHD happens to be a very modern codec with very complex approaches to data reduction - DV, however, is a joke with his SD resolution and intra-frame compression. The data rate here has absolutely no effect (; would be unrealistic unless they are high) but are definitely compressed the way images.
DV is intra-frame, ie each picture is stored separately without relation to previous or subsequent frames. Jump to randomly somewhere in the project and her back is loaded directly into the Picture.
With AVCHD, it is complex because the frames can refer here not only information of frames in the immediate vicinity but may even see something next. Jump to a timeline on a random frame, must enter the main frame, are decoded, then all subsequent frames until you reach the desired frame (I-frame). This process is associated with much effort, but fortunately the processor already use today by decoding graphics cards on the ground.