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.
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.
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).
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.
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:
Reading an existing file, drawing a line, saving the file.
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.
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.
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.
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…?
I’ve been having this slow save issue since Rhino 5. I was hoping Rhino 6 would remedy this, we ugraded to 6 very shortly after it launched. I’ve had a lot of time to experience different files. Saving is consistently slower than other programs either to desktop or to the server. This is not just my computer, its our whole office. We are all saving to a server with SDDs, the server is running Windows Server 2016 Essentials. Its very fast for other tasks and other programs, but Rhino is very slow.
I did try your suggestion to " type the command SetArchiveMemoryBufferSize and enter 32000".
Here are a bunch of test with a large Rhino file (950 MB) and a large Photoshop file (996 MB). We generate a ton of large files, so every second in saving matters.
Rhino 6 File - 951 MB (997,403,500 bytes)
2:15 save from rhino to server
2:08 saveas from rhino to server
0:40 save from rhino to desktop
0:08 copy file from desktop to server
1:07 SetArchiveMemoryBufferSize to 32000 (Checked save textures)
1:02 SetArchiveMemoryBufferSize to 32000 (Un-Checked save textures)
Photoshop CS6 File - 996 MB (1,045,361,300 bytes)
0:24 save from photoshop to server
0:14 save to desktop
0:10 copy file from desktop to server
I’ve run these comparative tests before, this is the first time I tried it with the SetArchiveMemoryBufferSize. To me this is a Rhino problem, not a server problem. This conclusion is based on the comparative saves to desktop, and the saves from Photoshop to the desktop and server.
The Memory Buffer setting does help, it cuts the save time in half. I’d love to get it down to the level where it is comprable to Photoshop. The other thing that Adobe does is it lets you keep working while the Photoshop file saves in the background. This is also enormously helpful.
Thanks for the Memory Buffer suggestion! Let us know if you have any other Rhino fixes that could help, or hopefully Rhino 7 will address this.
Hello - we did find that for large files the time spent compressing starts to be overwhelmingly more than the save - In v7/WIP there is an advanced option to turn off compression, which may or may not help here, but just fyi…
Just did the same bench-marking with Rhino 7 WIP, here are the results:
Rhino V7 - Same file used - 951 MB (997,403,500 bytes)
2:14 save from Rhino to Server - Use Compression True - Size Result 952 MB (998,406,762 bytes)
1:50 save from Rhino to Server - Use Compression False - Size Result 1.09 GB (1,180,953,316 bytes)
1:09 save from Rhino to Server - SetArchiveMemoryBufferSize to 32000
0:35 save from Rhino to Server - SetArchiveMemoryBufferSize to 32000 and Use Compression False 0:12 save to desktop (WOW!!!) - SetArchiveMemoryBufferSize to 32000 and Use Compression False
The implications of not using compression is files that are 18% bigger. I think we’d likely turn compression off, however 18% is not insignificant.
It would be ideal if Rhino could save in the background so we could continue to work while saving, and not have larger files due to disabling of compression. The good news in disabling compression is that it really starts to let us realize the advantages of the SSDs that we put into our server.