11 May
2018
11 May
'18
4:21 p.m.
I always thought the the slaves received a transformed frame in an
stable unknown (to me) format. And that's why the master gets easily
overcharged when converting unfriendly formats.
Manuel AC
On Fri, May 11, 2018 at 8:50 AM, Wolfgang Woehl via DCPomatic
<dcpomatic(a)carlh.net> wrote:
All systems are Windows 10; dcpomatic version 2.12.4
git 001a7047cb on all systems (current version).
Yes, master is encoding as well (and carrying the brunt of the load).
Hm, network throughput ... the tiffs are ~ 9 MB (75 Mbit). That should kind of work for 3
slaves, no?
Wolfgang
Am 11.05.2018 um 14:24 schrieb Carsten Kurz via DCPomatic <dcpomatic(a)carlh.net>et>:
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
--
http://akadcp.com/
https://www.facebook.com/akadcp
Source material is 12-bit tiffs with 9 MB each.
We’re seeing a lot less throughput than expected: ~ 6 fps. On the slaves status says ~
0.1 - 0.2 fps respectively.
Hi Wolfgang,
which version of DCP-o-matic are you using? I assume Linux for both master and slaves?
Do you allow the master to encode as well?
I guess 6 * 9MB could already be pushing it for a gigabit network. Hard to say wether
there is a code related issue. Carl will comment.
With smaller source files, we have seen network encoding up to 50fps. I have done a
Sintel test at 2048*858/8Bit at 17fps on a couple of older OS X machines.
Sometimes 'strange' TIFF versions could also cause slow downs.
I guess I would try to gain some insight by adding one machine at a time. I think a while
ago Carl added code to support encoding servers on multiple network segments. Maybe adding
more network ports/cards will help.
I love benchmarking, but I don't have access to such a configuration currently.
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic