Hey all,
I'm having an issue where my background file cache via tops is taking more than double the time it takes to cache in the foreground. I'm a bit perplexed by this. This is a flip sim geo cache, without any input simulation (just the particle fluid surface part) so I have simulation disabled. I was hoping to take advantage of parallelization to make it cache faster, but I'm actually getting bottlenecked. In the local scheduler, the only thing I have changed from the default is the thread count. I set it to equal cpu count less one, thinking giving it all but one core would get the file cache to happen at least at similar speed to the foreground cache, even if it made my machine lag heavily, but the reverse was true--its less than half as fast.
Im using a threadripper 3970, and my houdini build is 19.5.605. I have an optane 905p hard drive, caching to another intel ssd. Are there any parameters I can tweak in the schedular that can help maximum background performance on my rig?
I should add too, I get heavy lag with my mouse when this background render is happening. This happens even if set the scheduler to only use a quarter of my cpu cores. This is a behavior I did not experience in previous versions of houdini. Is there something nuanced I should be aware of here to help reduce this behavior? I understand these are probably separate issues, but felt like I ask about both here.
Thanks in advance for any insights!!!!!
Best,
TOPS Background File Cache Very Slow
2448 1 0-
- jtk700cln
- Member
- 63 posts
- Joined: Jan. 2016
- Offline
-
- jtk700cln
- Member
- 63 posts
- Joined: Jan. 2016
- Offline
Hey all,
not sure if this will be helpful or not. I managed to get virtually identical cache time to the foreground by turning off autosave, and setting the Frame per batch on the ropgeometry1 (inside the topnet itself) to $FEND/63 (63 being my core count)- which in this case wound up being 22 frames per partition. I also set the connection retries on the RPC server to 0, and the connection timeout to 1. Based on my limited understanding here, I figured if any of my cores were hanging, the top network wouldnt even bother trying to get it back into the q, instead it would move on to a working core. I have to check again and see if this was actually something that helped.
the mouse lagging behavior persists, but I can live with that for now.
not sure if this will be helpful or not. I managed to get virtually identical cache time to the foreground by turning off autosave, and setting the Frame per batch on the ropgeometry1 (inside the topnet itself) to $FEND/63 (63 being my core count)- which in this case wound up being 22 frames per partition. I also set the connection retries on the RPC server to 0, and the connection timeout to 1. Based on my limited understanding here, I figured if any of my cores were hanging, the top network wouldnt even bother trying to get it back into the q, instead it would move on to a working core. I have to check again and see if this was actually something that helped.
the mouse lagging behavior persists, but I can live with that for now.
-
- Quick Links
