Rhino 6 - Slow save to network location

I have a large file that I’m working in (257Mb) that takes ~22 minutes to save to a remote network location. To save the file locally takes seconds, and to then drag and drop it into the same network folder takes ~55 seconds. My workstation and the remote storage are all on the same domain, and we have a dedicated VPN tunnel between the local AD Server and the datacenter where the DC and the storage physically resides. Watching the network communications it’s slow steady throughput when saving over the network, I can copy a file to the same place via explorer while saving in Rhino and the throughput spikes until the transfer is complete then goes back to thew slow rate.

Rhino 6 SR12 2019-1-29 (Rhino 6, 6.12.19029.6381, Git hash:master @ ae9d7fba5fda0b43002dc44a34e059a9a382db04)
License type: Commercial, build 2019-01-29
License details: LAN Zoo Network Node

Windows 10.0 SR0.0 or greater (Physical RAM: 32Gb)
Machine name: GCCHEJCREECY

Non-hybrid graphics.
Primary display and OpenGL: NVIDIA Quadro P4000 (NVidia) Memory: 8GB, Driver date: 12-17-2018 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 412.16

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 12-17-2018
Driver Version: 24.21.14.1216
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB

Rhino plugins
C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands” 6.12.19029.6381
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 6\Plug-ins\RhinoBonusTools.rhp “Rhino Bonus Tools”
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp “Rhino Render”
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 6.12.19029.6381
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp “RhinoCycles” 6.12.19029.6381
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 6.12.19029.6381
C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp “Displacement”

No ideas yet. @dalelear is the file I/O guy and is off today.
At least you have a reasonable work-around for the time being.

I wonder of it’s related to some file scanning process that is going on that is bypassed by the Windows File Explorer…

I am having the same issues here.

Rhino 6 files are painfully slow, to the point where users have to save locally and then copy to the network/server shares.

We also run Revit and saving/syncing files are NOT an issue for them. It only effects Rhino 6 files.

Any ideas? Anyone? Bueller ?

@Cskills @jcreecy

As a shot in the dark, type the command SetArchiveMemoryBufferSize and enter 32000.
If that fixes the issues, then the network has high delays for “seeking”. If that doesn’t fix the issue, return the setting to 64 and it is more likely it is a file permissions/locking/renaming/moving or other storage media issue not directly related to sending bytes from Rhino to the storage media.

Thanks @dalelear

Just tried the command and there is definitely a difference.

Before: Opening up a new Rhino 6 file with simple shapes, took about 20mins to save (the file itself was less then 10MB). After (running the command) it took less then 3mins.

Before: Opening up an existing Rhino 6 model (roughly about 1GB, a lot of vray, materials, etc.) took about 90-120mins. After (running the command) it took about 40mins.

Not saying this is a permanent fix, but at least it’s in the right direction.

Anything else you can think of?

Side Note: Asking the designer to run a clean/check on his model to make sure nothing is “bad”.

Nothing immediate. If you have a good network expert handy, you can tell them that the change you made reduces calls to “fseek()” and Rhino is basically sending large chunks of bytes from memory to the storage media using “fwrite().” They could investigate adjusting network settings based on these breadcrumbs of information.

We have several networks in our office and haven’t been able to reproduce the slow performance issues we hear about. There is so much variation among networks and so many ways to configure them, that it really takes somebody familiar with the network to investigate it on site.

Not related to Rhino at all, but as a test, you could also see if you can access your network adapter advanced settings.
Try turning off/disabling:
Flow Control
Jumbo Packets

Understanding that it sounds like everyone in your office is experiencing this issue, it may be that a setting has been updated/changed on a piece of your internal office network equipment?
(we turn this stuff off at our switches). Not suggesting you start telling your Networking department what to do, but it might be worth asking? (Turning the settings off on your workstation network adapter would be a first test to see if it even makes a difference).

Thanks Chris,

Confirmed that Flow Control and Jumbo Packets have been disabled on the switch level. I might have to start thinking of it’s the existing system structure, as we are on DFS (not replication) and wondering of that’s the issue.

shrug + more testing…insert heavy sighs

Thanks!

we use DFS as well, for what it’s worth, we haven’t seen any performance issues…yet. Did you also try to disable flow control/jumbo packets at the workstation level? worth a shot?

@Cskills Something that just popped into my head is to see if there is a difference in times between:

  1. Reading an existing file, drawing a line, saving the file.

  2. Reading an existing file, drawing a line, using SaveAs to save the file in the same directory as the original but with a completely new name.

If there is an appreciable performance difference between these two tests and 2 is faster, then we could look at how we handle shuffling files around between a temporary, backup, and final result.

Gonna try that now on a couple of systems to see how that will work. Will keep you posted.

ok, good luck! These are never fun things to troubleshoot. but a few orders of operation that we have found helpful, (in situations where network speed seems to be troublesome).
Specific to Windows Servers running DFS: the usual suspects are updates, reboots, blah blah.
Also, if any of your dfs targets are ISCSI, (and attached to your DFS server)…definitely turn off the following items on the NIC of the DFS Server, (especially if it’s a broadcom adapter), heck, you might want to try these even if it’s not ISCSI.:
Flow Control
Interrupt Moderation
Large SendOffload (IPv4 and IPv6)
Receive Side Scaling
TCP/UDP CheckSum Offload (IPv4 and IPv6)
Virtual Machine Queues

you said you aren’t using DFSR, so I will assume that this isn’t a “wrong site target issue”.

All of this is just recommendations, they do not require reboots, but obviously will drop the network connection when you make changes, so…don’t do these on the server during production.

Lastly…This is NOT to say that Rhino 6 ISN"T the culprit. Just a few other items to consider.

1 Like

So after checking on our VMs and setup, it looks like VMQ was the issue.

Granted I’ve only done a couple of test, but the results are night and day.

Did a save as with VMQ enabled, and it was at least 45mins.

Did a save as with VMQ disabled, and it completed at 5mins.

/me: smacks myself for the little things…

Thank you all for the assist and beers on me @chanley!

1 Like

@Cskills, @chanley

Cskills, I’m glad to hear that you made some improvements by adjusting network settings. It would be nice if we could modify Rhino so it wouldn’t be so sensitive to “VMQ” settings and I’ve added this information to our internal bug report.

Thank you all for using Rhino and sharing what you’ve learned in this forum.

– Dale Lear

For what it’s worth, The only time I have seen the VMQ setting make a difference is on a windows 2008, (or up), server, with a broadcom adapter.

Rhino 6 is slow not only to network location but so at external HDD via USB 3.0 or HDD internal SATA 6 Gbs
… I testing opening the same file duplicated . Rhino 5 in one screen vs Rhino 6 at second screen. Rhino 5 wins always.
Any workaround…?