External USB HDD and Poser Libraries
Networking Runtimes between computers is a lot of traffic. Optimally, you should be using dedicated network cards for doing so.
MTU (Maximum Transfer Unit) is a setting for packet sizes sent between cards.
You can modify the MTU size, but there is a catch to doing that.
Even thou sizes can be changed, it only changes it on certain Layers.
Only Layers one and two can use Jumbo frames.
Layer 3 is limited/capped to MTU 1500.
Layer 3 is also the layer that the internet uses, so if the same nic card is used for internet connectivity you end up with a bottle neck.
Another misconception is that a MTU setting of 9000 is going to be the best for NAS, which is not always the case.
5000 (or 4096 depending on hardware) is usually a better size in the end.
Another area that confuses people, is the required network protocols that the adapter needs to function.
You only need 3 for NAS, or for most networks period.
These are the only 3 that should be active on a NAS subnet.
- Client for Microsoft Windows
- File and Print Sharing
- TCP/IP v4
All the rest should be disabled and then removed if not needed, and these include.
- QOS Packet Scheduler
- TCP/IP v6
- Link Layer
- Adapter Multiplexer
- Net Bios
Some op systems can be odd and even ones that are installed and turned off, can consume an I/O slots.
It depends on the Bios in the NIC, Op system, etc.
I don't think I have ever set IRPStack much above 20 on any system, And that was on a busy server.
Some op systems freak out if set in the 30's, and require a patch to fix that. (Windows, Redhat, etc)
A better option NIC wise, is a ganged card in each machine with 2 or 4 crossover cables running between machines.
This drastically increases thruput, but may require an additional network protocol depending on the NICs used.
If you can afford too slurge on NIC's, Converged 10gbs cards are worth every penny when it comes to network storage.
They are PCIexpress 2.1 cards, and thruput is their middle name....
These cards require shielded cat6 cable, or they will drop packets. Lots of them....
You should use the same cards on both ends, down to the build and bios numbers.
Not all operating systems support these cards, read up on them before you buy them.
You can usually find them far cheaper used, but getting matching pairs can be an issue then.
ibr_remote last edited by
This is great information. Thank you for sharing it. Others using Poser with external runtimes may also find it valuable for reference.
@ibr_remote Sadly, it is far from solved... I have now determined it is not a network issue, but something in this one computer's installation of Windows 7 premium interfering with the Library manager (got tired of the library timing out, so I copied the offending runtimes first to a 5tb USB drive... same problem persisted and thought it might be related to what you have so I copied the runtimes to the internal HD on the computer and still the problem is persisting... none of my networked Win XP machines have this issue).
@shvrdavid yes, this is on my home render network. The network only interconnects the machines for the purpose of sharing content via Queue manager (or for lightwave Screamernet) and sharing runtimes between my old fileserver and my newer 64 bit machine. The only machine giving me trouble is the newer 64 bit machine running Windows 7 Premium. Sadly it is even giving me trouble with the library with the runtimes on a local drive, which is problematic as I intended this machine to be my new workstation.
I am taking a short break today because I am fed up with looking at registry screens, Group Policies, and firewall rules (and yes, I have told it to turn the firewall off, but somehow things still get blocked on my local network... hate Windows 7)
What operating system is on the system, that the files are on?
And did you turn off auto disconnect on that machine? (net config server /autodisconnect:-1)
@shvrdavid Initially the machine they were on was Windows XP Pro 32 bit (my older workstation trying to turn into fileserver due to massive HD capacity). These were being shared over local network with multiple computers (two Win XP Pro 64 bit machines, and 4 Win XP Pro 32 bit machines... the 4 32 bit machines were Dell's I salvaged and rebuilt back in the day). I have since moved the runtimes several times - all on to the Windows 7 Premium 64 bit machine that I am trying to make my new workstation (first to external, self powered 5tb USB drive, then to one of the internal HD partitions).
Autodisconnect is off. I also have the power config setup so that no drives are spun down or idled while the machines are on.
Since the issue does not happen on any of the Windows XP networked systems when I open Poser and load the library, I am fairly convinced it is something in Windows 7 causing the issue. I have tried going through the various Firewall, Group Policies, and even certain known registry keys to fix possible causes (and am finding Wind 7 does a lot I do not like...like ignoring whether the firewall is on or off, still need rules to allow certain programs). I am admittedly not as familiar with 7 as XP though.
This behavior with the library for me is happening across Poser 8/2010, Poser 9/2012, Poser 10/2014/GD, and Poser 11 Pro. I had already had a fairly lengthy tech support ticket, tried the Internet Explorer 11 fixes, tried a number of Flash and Air fixes, and at one point it almost seemed fixed (until this past week when I am on a deadline for a number of very high resolution renders that my 32 bit system just can not do or even compose all of the elements into Poser for).
On the upside, I am keeping notes of some of the possible fixes as I go to include in the troubleshooting guide I am always expanding. It needs it's version 2 finished up though and published.
By chance does the computer that drops the shares have a Broadcom or Intel NIC?
Some of those ignore auto disconnect settings in Windows.
You can find alternate drivers for some of them that enforce the Windows setting.
@shvrdavid I will have to check that when I go home. I was not aware of that, but it's good to know. Though the NIC shouldn't still be causing the problem with the runtimes locally.
The Workstation with the issues has a Broadcom NetXtreme Gigabit card for networking.
Check these two registry keys.
Your choices for this registry key are 1,2 and 3. Should be set to 3 for file sharing
1 = Minimize Memory Used
2 = Balance
3 = Maximize Throughput for File Sharing and Maximize Throughput for Network Applications
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache
Your choices for this registry key are 0 and 1. Should be set to 1 for file sharing
1 = Maximize Throughput for File Sharing
0 = Maximize Throughput for Network Applications
Some programs, such as SQL and Exchange, set this value during an installation. For these programs, the optimal setting is 0.
0 = Indicates that the computer does not go outside its cache pool and use program memory to perform I/O functions.
1 = Indicates that the computer looks outside of of the allocated cache pool and uses program memory to perform I/O functions. This occurs if the cache is full.
You may very well be running out of NIC cache space and Windows is not setup to deal with a NIC driver that does. Manually increasing the cards memory allocation may help as well.
Are you using the Windows drivers for the network card, or the Broadcom ones? (I believe there is nothing written to the bios on that series chip, and the bios is written in during bootup) Might be worth a shot to use the try the other driver from what you are using.
Looking thru some stuff, go to that machine, go to the device manger and turn off the following in the advanced tab of the NIC.
- Interrupt Moderation - clumps packets together and sends them as a batch - the main offender
- Flow Control - sounds counterintuitive to disable it, but it messes with existing flow control in Windows networking stack
- Receive Side Scaling - also messes with Windows networking stack
- [anything goes here] Checksum Offload - supposed to speed up performance by offloading TCP/UDP checksumming to hardware; in reality does nothing for an average desktop PC except interfere with Windows networking stack
- Green Ethernet - performance-eating eco garbage
Curious to know if this is the root issue causing your problem.
Here is the long version of it from Microsoft, this applies to any file server, no matter what op system version from NT 4 up.
Your basically just changing the way it talks to the router/switch/nic to eliminate the chance of errors.
Any other NIC talking to it is forced to do communications in an error correcting way only.
You probably will notice a speed difference as well, it will increase.
Haven't had a chance to try any of this yet - will let you know after I do.