Just to clarify (searching post only made this more confusing)
Has the issue with having HTT turned on been resolved.
Thanks
no more bugs here
vray 1.47.03
2 xeons 3.06 ht on
I’m using 1.47.03 with dual Xeon 2.4’s and dual Xeon 2.6’s and if I enable HT, they wont render. With it turned off, they render just fine.
We have a few dual HT machines here plus one AMD dual dual-core, but they all seem to render fine.
Best regards,
Vlado
Hi,
we have it think over 40 renderboxes with HT. 20 of them Dual Xeons with Hyperthreading. They all render. With the Dual Xeons however strange things happen. Sometimes (Especially with huge image formats, backburner slicing or heavy scenes) they render only with 30% cpu usage. We couldn’t find out why. If the render starts locally everything is fine. We have a suspicion that it has something to do with the bitmap pager and it’s better to turn it off. But there are still cases where the xeons render only with 30 %. Has anybody experienced this?
Best Regards,
Dieter
Well, this is what we do:
If we are rendering an animation from a saved solution, we turn off HT.
If we are rendering images, turn it on.
This works flawlessly and I can’t afford to risk the random errors that we used to get with rendering animations. I think until the HT problem is specifically addressed, ie “We have established what the random problems were and Vray release x.xxx now works 100% with HT”, we will continue to work this way.
We have run into the same problem, but only using 25%. But it was noticeable on dual amd´s too. I came to the conclusion that displacement was the cause of this severe slowdown, i changed it into common displacement max modifier and the problem was solved. So, i think it wasn´t related to HT, as it can´t be applied to AMD´s.
Seems a slight mystery still but at least I know Im not nuts. Thanks for the input.
Yep, this is because the actual geometry creation for displacement/fur etc. is not multithreaded - so if V-Ray needs to dump and re-create that geometry too often, it will appear to be using just one thread. As such, this particular issue is not a bug.
Best regards,
Vlado
Is it technically impossible to speed it up? Displacement will be always that slow? Or is it related to dynamic memory usage when creating geometry, flushing it out and create new geometry and so on? Displacement is NOT always slow, so i guess it depends on the amount of geometry it has to calculate…How can we check when displacement will start to create problems?
The problem is not that displacement is slow, but that V-Ray hits the dynamic memory limit and starts to flush parts that are not needed, and creating new ones etc. This slowdown can be reduced if you increase the dynamic memory limit, as then V-Ray will have more room to keep geometry around. Also, avoid using very large triangles in the displaced meshes for 3d displacement, as that would create many triangles in one chunk, which degrades the performance of the geometry cache.
In general, there is no way to find out in advance at which point the dynamic geometry cache will overflow, but I suppose that V-Ray can put up a warning when this starts to happen too often.
Best regards,
Vlado
Thank you Vlado, i really appreciate the time you take to answer my/our questions! 
Keep up the good work!
think i’ve found a fix for the bug if CPU usage is at 25%…
open task manager
go to the 3dsmax.exe process
right click - set affinity
make sure all of the CPU’s are selected
when i checked the affinity for the 3dsmax process only CPU 0 was selected hence the 25% CPU usage - when i checked the other three CPU’s performance went up to 100%
can anyone else confirm?
soreal the affinity problem is a known max problem, there is a fix on the splutterfish website somewhere. It was mainly found to be a problem with brazil
oh… 
sorry!
didn’t know about that.
dont apologise soreal!
I have been using the affinity fix on max 8 and vray and it makes no difference. It must be vlados good coding!