View Full Version : Lightwave slow saving to NAS

05-29-2015, 03:04 AM
We have a technical problem with NewTek Lightwave software, exactly with its saving capability.
First, I will outline the situation in the workplace. We have 4 workstations with Lightwave 11.6.3, we use a network storage NAS (QNAP RAID 5) with some HDDs, each consisting different data (for example - X is for actual projects, Y is for model/images library... atc.). When any of us saves something in Lightwave (Layout and Modeler) the saving itself is running unbelievably slow ..... about 10 times slower than other applications.
The question is why the saving of LightWave Layout and Modeler is running so slow? And why the problem occurs only for modeler and layout??? Other applications saves things much faster. Photoshop saves 100MB file in seconds, Lightwave is saving model of tree (of the same size) a whole minute (I am exaggerating of course but the difference between PS and LW is perceptible!)

Can anyone tell me what causes this issue? (slow saving ONLY from lightwave software).

Example: 106MB file
Copy Total Commander (copying from volume NAS X: to C: and vice versa) - 2,5sec
Save Photoshop file to volume NAS X: - 2,0sec
!!! Save Lightwave Modeler Object to volume NAS X: - 24,0sec !!!
!!! Save Render from Lightwave Layout TGA-32 to volume NAS X: - 22,0sec !!!


05-29-2015, 05:52 AM
Files saved from modeler and scene files from layout are small files. Have you tried saving small files from other applications as the problem might be the small file size not the application.
What brand of switch are you using that the nas is connecting to ? In the past there has been some compatibility issues with intel nics and cheap dlink switches in that small file sizes transfer really slow.
Are you using jumbo frames and if so do all your devices on the network support jumbo frames.
On my network I have no such slowdowns so I doubt it is lightwave. Check your cables and replace a couple to see if it makes a difference. Small files will always transfer slower than larger files due to the network overhead etc but it shouldn't be that slow.

05-29-2015, 07:05 PM
I can only guess. But there are two ways how applications write data: whole file at once, single buffer with size of entire file. Or in packets, or row by row (text files). I think so LWS scene files are saved row by row.

05-30-2015, 09:15 AM
I'm pretty sure it's not an issue with LightWave per se, as we run a QNAP NAS with a couple of mirrored hard drives in, and also have X for projects, with other drives mapped for other uses, and have no problems with speed when it comes to saving small files. We also pull files from other NAS boxes with no problems (Synergy boxes) but they're not in RAID, purely back up drives.

But weird how it only happens with LightWave's files.

05-30-2015, 01:14 PM
I've seen this too, especially with large LWS files (not so much with objects). Senseis explanation about row by row (LWS), makes sense. I remember one of the scenes for World in Conflict taking 10 minutes to save over network (LWS at approx 800MB). Took around 1 minute to save to a local drive. The workaround for that was to save localy and then copy the file to the network storage. :D

05-30-2015, 05:15 PM
Try disabling the firewall and antivirus and test. Some of them do extensive examination of transfers across the network that look suspicious and that can toss a big log in the road.

07-15-2015, 06:40 AM
After some time I return to this question.

spherical: I tried your advice. Turn off firewall and antivirus. Difference saving for the test file is 106 megabytes 19sec (F & A OFF) ..... 26sec (F & A on)

Next, we tried to create the NAS volume with RAID 0 storage is subjectively improved a little, but not in any way rapidly.

Really I do not understand why that speed is a problem only Lightwave. Other applications store almost 10 times faster.

07-15-2015, 03:32 PM
Ok, so there's some file contents scanning going on with the FW/AV, which is to be expected. Usually, you can turn that off in a "Trusted Zone". I didn't see any response to lightman's observations in post #2. There are some things in there that ring true.

09-25-2015, 08:00 AM
After some time I return to this topic.
Spherical: Unfortunately, the response Lightman I have no answer for two reasons.
The first 100 megabytes do not consider small files
2. If one oplikace stores quickly, and the other slowly, pravděpodovně can prevent damage to LAN cables

And now a couple of new knowledge.
With the upgrade to Windows 10, it is possible to monitor in detail the means in Task Manager and Resource Monitor.
If you like watching půběhy through Windows Resource Monitor, thus saving the modeler.exe shows the portion of the network speed of 1.4 KByte / s. While saving from Photoshop photoshop.exe process is not visible, but in the process System network speed steadily to 12.7 MBytes / s. Vezmuli that without storing process system takes 2MByte / s, based on Photoshop 10 Mbyte / s. Again, almost 10 times higher than Modeler.
It is also interesting that Windows takes modeler in this case as a separate process and Looks like that for some reason has limited resources for network communication.

09-25-2015, 03:41 PM
Then I agree with Senesi and Cageman that it is the file data type and how that type is transmitted; not an issue with LightWave itself.

09-25-2015, 07:18 PM
Then I agree with Senesi and Cageman that it is the file data type and how that type is transmitted; not an issue with LightWave itself.

Actually, doing line-by-line output is wholly within LW's control. The app chooses which level of file IO APIs are used, and how they are used. Inefficient choice and use of OS file IO APIs is an application coding issue, not an OS issue.

None of the evidence shown to date gives any clear indication that the performance issues seen are a result of some kind of OS-imposed issue or limitation. Indeed, the fact that other apps aren't showing such problems clearly indicates the OS supports apps using file IO APIs to achieve much greater transfer rates.

09-26-2015, 12:17 AM
OK, I didn't fully elucidate. Didn't mean to "blame" the OS; just addressing the issue, as the OP sees it, by noting the difference in throughput of different structures that are handed to the OS to process. How they are handed to the OS is the issue. Yes, LW3DG can modify the code to take advantage of better methods. So, in that sense, it is their problem to fix. I'm betting that the code in question is legacy code from waaaay back when the network wasn't nearly as fast so, not an issue. If the OP hasn't, he should file a bug report, with supporting materials, through his account page.