Hi Dorian,
we actually observe this behaviour here, too - sometimes at least. i
could not find any conditions yet to reproduce it exactly.
our workstations are on windows (xp64 and 7), the file server is running
debian with samba which we use to connect the shares.
do you know of any similar settings like the TCP ACK delay you're
mentioning that have an impact on nuke's performance when writing files?
i'd like to check those to see if tweaking those makes any sense.
cheers,
Holger
Peter Pearson wrote:
On 23/11/11 17:30, Dorian Fevrier wrote:
Hi!
OS are Linux Opensuse 11.1 and we use NFS export.
Thanks in advance,
It depends on all sorts of things - how many NFS nodes you have,
whether NFS is configured to use UDP or TCP (and if it's the latter,
the TCP ACK delay), how busy the NFS network is, the format of the
images you're rendering out, if it's EXRs then the number of channels
you're writing out and the compression type you're using, etc, etc.
Nuke uses standard file writing POSIX APIs to write to files, and
while there will be a slight overhead in sending data over the network
in chunks (due to the TCP ACK delay) as opposed to the whole file at
once like the cp command does) it shouldn't be anywhere near what
you're seeing. It sounds very much like a network configuration issue
your end, either to do with some TCP ACK delay or fsync/flush
configuration on the filesystem that the NFS drives are using.
Peter
--
Holger Hummel - [email protected]
Celluloid Visual Effects, Paul-Lincke-Ufer 39/40, 10999 Berlin
phone +49 (0)30 / 54 735 220 - [email protected]
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
