* Re: CPU requirements......
2015-07-13 16:14 CPU requirements Another Sillyname
2015-07-13 16:26 ` Jared Mauch
@ 2015-07-13 23:10 ` Adam Goryachev
1 sibling, 0 replies; 3+ messages in thread
From: Adam Goryachev @ 2015-07-13 23:10 UTC (permalink / raw)
To: Another Sillyname, linux-raid
On 14/07/15 02:14, Another Sillyname wrote:
> I've been testing a test RAID6 setup with a 5970 CPU that has worked fine.
>
> As this box is almost exclusively going to be a file server I'm
> thinking of swapping to a G3258 processor, dual core, not overclocked
> and no hyperthreading or turbo features.
>
> The box may also be used to do transcodes of media files from HD mpeg
> to x264 which is pretty CPU intensive......
>
> Are there any likely issues with the RAID running on a substantially
> slower CPU? I can't seem to find an recent/decent docs suggesting
> minimum CPU requirements for MDADM raid configs.
>
I'm not sure about the specific CPU's you are referencing, however, as I
understand it, RAID5 (and RAID6) are still single threaded (only one CPU
is used for calculating the parity) which is done during all writes, and
when degraded during all reads as well.
In addition, transcoding media files will also be very CPU intensive.
Some questions to ask:
1) How many transcodes do you want to do concurrently? Just one at a
time means you maybe only need one core for that.
2) Does transcoding a single file/stream utilise more than one core?
Having more cores will mean a faster result.
3) What is the read throughput you need to keep the transcoding process
CPU busy (ie, you want to be able to read the file from disk faster than
the CPU can do the work to convert the file)
4) What is the write throughput you need to save the resulting file from
the transcoding process (ie, if the transcode can't write the result,
then it will waste CPU time).
5) Don't forget you now have concurrent read/write on the same set of
disks, consider tuning the read ahead (read and cache more of the input
file) and potentially write buffers (assuming you can always recode the
input file if the system crashes during the process).
What is the goal?
a) Make sure it works (should not be a problem, just performance will be
slower)
b) Make the transcode as fast as possible with the given disks (If the
disks are slower than the slow CPU, then no problem, otherwise use the
faster CPU)
c) Make the transcode as fast as possible with the given CPU (either
one) (take your pick...)
You would probably need to do a lot of test and measure of the above.
The advantage you have is a well defined work load, that can be easily
tested. Just remember to record the results clearly showing what you
changed in each scenario. Though it might be difficult to "swap" CPU for
the various tests...
Hope that helps....
Regards,
Adam
--
Adam Goryachev
Website Managers
P: +61 2 8304 0000 adam@websitemanagers.com.au
F: +61 2 8304 0001 www.websitemanagers.com.au
^ permalink raw reply [flat|nested] 3+ messages in thread