Re: [DVD-o-matic] benchmarks/machines

Am 16.12.2013 um 01:17 schrieb Carl Hetherington: Maybe a screenshot of the taskmanager showing the individual core/thread loads (must be quite impressing anyway with 16 individual load scales ;-) ? If the 'master thread' is starving the encode threads, we would probably see one or two threads at 100% and all the others at something between 30% and 50%? I already suggested to this user to do a test with a second instance of DVD-o-matic encoding the SINTEL Trailer in parallel a second time. If the single main thread is the bottleneck, both encodes would still run for roughly the same time as a single encode at something like 90-100% total CPU load. Would be another hint. For the same reason, using multiple fast network clients will be of little use - besides the aspect of gigabit network saturation beginning at probably 10fps total node encoding capability, the master application/thread will starve the network nodes just as well around 10-12fps for the same reason, I guess. Only segmented offloading of the complete conversion could solve that - but then (partial) source and target files would have to be located on all remote machines, distributed and collected/assembled before/afterwards. That sounds like a lot of work - for a relatively small group of users being able to benefit ;-) If the machine has enough memory, means, no major swapping, I, too, think disc performance is nearly irrelevant, as typically both input and output is compressed and thus comparatively small and read/written quickly. Actually I am not citing these benchmarks to suggest a major modification of the framework to improve the performance for this high end machine class - again that could be a lot of work for a rather small user base. My real intention with these numbers is to find the sweetspot where a moderately priced machine will deliver maximum throughput with DVD-o-matic. It seems that currently this is a single CPU 6-8 core HT machine and something around 10-12fps where DVD-o-matic maxes out under practical conditions. But maybe, minor changes to the program framework and FFMPEG calls could still improve the thread balancing somewhat. This issue, however, should be solved once we see a GPU accelerated version of OpenJPEG ;-) - Carsten