Speed Up Loading Of Files Via Network In Nuke? Wins/smb Problem Prevents Fast Loading? (nuke Specific Problem)

[gcpnmax]

Hey everybody,

I'm no networking guy, so the description of the problem I give here may contain wrong terms ect. I would be glad to be corrected.

As I started to use Nuke on Windows (Win xp64, with Nuke 5.1v2 64bit version) I was disappointed of the loading times of my footage (actually the time Nuke took to show me the contents of a directory e.g. when using a read footage node). I loaded my image sequences (10 bit DPX) via a gigabit network (from a linux server which is fibre channel attached to the main gigabit switch). Whenever I opened a script, Nuke froze for several seconds (even when no viewer was present, so no rendering occured) before I could do anything. This didn't happen when I had all footage locally on my HD. So I tried something. I went into the file C:\Program Files\Nuke5.1v2\plugins\folders.nk and replaced all the server names of my favorite directories with direct IPs. So if there was a path like //mainframe/footage/images.%05d.tif I replaced it to //172.123.23.11/footage/images.%05d.tif and suddenly everything went smoothly. When I use only IPs instead of machine names everything is fast and responsive. Is this phenomeon related to some Wins or SMB Service configuration? Because Nuke, as I read somewhere was developed mainly on a LINUX platform and later had versions for Win and OSX developed maybe there is something strange going on with windows related smb directory sharing and Nuke? Because this phenomenon doesn't occur in AFX or DigitalFusion (same machine and config) so I thought maybe Nuke win does something differently when resolving the IP for a given machine name (say the server is called "Otto" and the IP is 172.123.24.32 everytime a frame is loaded, the IP has to be resolved before accessing the data).

Any Ideas? Maybe anyone else noticed something strange in a mixed Win/Linux work environment? Interested in any comments

Louis

ps.: btw. which is the fastest image format for Nuke? Should everything first be converted into EXR's to achieve maximum performance? How about DPX/CIN or float tiff?

[deke-kincaid]

QUOTE(LouisCyphre @ 11/14/08, 08:46 AM) [snapback]295179[/snapback]
When I use only IPs instead of machine names everything is fast and responsive. Is this phenomeon related to some Wins or SMB Service configuration? Because Nuke, as I read somewhere was developed mainly on a LINUX platform and later had versions for Win and OSX developed maybe there is something strange going on with windows related smb directory sharing and Nuke? Because this phenomenon doesn't occur in AFX or DigitalFusion (same machine and config) so I thought maybe Nuke win does something differently when resolving the IP for a given machine name (say the server is called "Otto" and the IP is 172.123.24.32 everytime a frame is loaded, the IP has to be resolved before accessing the data).
Couple things, first UNC file paths have always been slower then directly mapped paths in Windows since nt3.5.1.

Another issue I've run into is that on large scripts can slow down Nuke if your autosave location is on the server.

[gcpnmax]

Thanks for the hint with the autosave location, didn't think about that.

[axislg]

Try to use for program's share on server "windows offline files" technology. also it useful for cin/dpx. Map %windir%\CSC fastest drive. Try use ramdisk for temp. Try change options for autosave like [firstof [value root.name] [getenv NUKE\_TEMP\_DIR]/].autosave.