I've got 4 machines and am using Windows 10 w/ Houdini 17.5.391 on all of them (and rendering with Mantra).
Rendering itself is working just fine… however submitting the job takes what seems to be an absurd amount of time! I hit “submit” and often have to wait for 10+ minutes!
The hip file is on a NAS box and I'm using the “render current HIP file” option.
Any ideas on how to speed this up? All of the machines can read/write without issue. This is the one part of the process that's killing me! It's not too bad when I'm just submitting one file but I've got 4 to submit and the thought of waiting over half an hour just to submit (let alone any fixes if/when the job fails!) is rather depressing!
I changed the HOUDINI_ACCESS_METHOD to “2” thinking it might make a difference but no such luck.
Any ideas are greatly appreciated.
Thanks!
Hqueue Job Submission Slow
3185 4 2-
- The3DStig
- Member
- 130 posts
- Joined: 10月 2015
- オフライン
-
- eikonoklastes
- Member
- 447 posts
- Joined: 4月 2018
- オンライン
I have just started tinkering with HQueue and noticed the same issue, also using 391, and Mantra.
I put out a test job to a specific client to ensure it was delivering frames. The render time for each frame is around 30 seconds. The job submission time was 6:03 PM, and the first frame was delivered at 6:52 PM! The frame range is 1-240.
After that very slow prep time, the frames started coming in as expected, around 30 seconds each, but that initial delay is unacceptable.
I put out a test job to a specific client to ensure it was delivering frames. The render time for each frame is around 30 seconds. The job submission time was 6:03 PM, and the first frame was delivered at 6:52 PM! The frame range is 1-240.
After that very slow prep time, the frames started coming in as expected, around 30 seconds each, but that initial delay is unacceptable.
Edited by eikonoklastes - 2020年3月9日 01:35:06
-
- jm
- Member
- 40 posts
- Joined: 9月 2014
- オフライン
When you say submit. is HQ saying “waiting for resources”? or is it the wait to see it even pop up on HQ?
Setting machines up on my end I've run into the issue of it rendering/simulating slowly when i have a central storage location. Without knowing more about your setup it would be hard to say as it could be how your NAS is setup. My current work around is to choose which machine my jobs get offloaded too and i select the option to copy the hip file to the selected location for it to deal with the hip file and caches locally instead of pulling data across the network. Just doing that, the speeds was like night and day.
Setting machines up on my end I've run into the issue of it rendering/simulating slowly when i have a central storage location. Without knowing more about your setup it would be hard to say as it could be how your NAS is setup. My current work around is to choose which machine my jobs get offloaded too and i select the option to copy the hip file to the selected location for it to deal with the hip file and caches locally instead of pulling data across the network. Just doing that, the speeds was like night and day.
-
- eikonoklastes
- Member
- 447 posts
- Joined: 4月 2018
- オンライン
I've isolated the issue to being related to the ‘Frames per Job’ parameter. When set to 1 (the default), each frame is sent as a separate task to HQueue, and the preparation process takes an unreasonable amount of time for many frames.
For my 240 frame sequence, increasing the number to 30 splits the jobs up into 8 chunks of 30 frames per machine, and the job preparation in HQueue takes only about 90 seconds (as opposed to 50 minutes).
It's still not an ideal scenario as the slower machine gets apportioned too many frames and, towards the end of the job, the faster machine sits idle, while I wait for the final chunk to finish on the slower machine.
To work around this, at that stage, I'll probably have to kill the render on the slower client and reschedule the job with the faster client(s) selected. Again, not ideal, this manual workaround-ing.
For my 240 frame sequence, increasing the number to 30 splits the jobs up into 8 chunks of 30 frames per machine, and the job preparation in HQueue takes only about 90 seconds (as opposed to 50 minutes).
It's still not an ideal scenario as the slower machine gets apportioned too many frames and, towards the end of the job, the faster machine sits idle, while I wait for the final chunk to finish on the slower machine.
To work around this, at that stage, I'll probably have to kill the render on the slower client and reschedule the job with the faster client(s) selected. Again, not ideal, this manual workaround-ing.
Edited by eikonoklastes - 2020年3月9日 09:20:42
-
- jerry7
- Member
- 680 posts
- Joined: 11月 2013
- オフライン
-
- Quick Links



