I agree on the possible bad code, but in my case not with the client server sync.
Ryzom occupies about 99% of a core no matter if it's 2 or 4 Ghz, so clearly something is running at full pace which obviously doesn't need to. I'd like it stuck at 80% to have some reserves, but I doubt some skilled programmer can fix that soon - as well as the desired multi thread support.
I have an update about the behaviour tho:
Observing the CPU Graphs I saw that when it hangs the CPU load for that core goes right to the top and stays there, and the kernel times go flat down. Normal business with small moves in the graph comes back when it's working again. Looks similar to other CPU overload problems I've had with other software in the past.
I admit tho that I think Ryzom can cause that with client / server sync problems...
Remarkable is that the last played audio buffers continue playing when everything else about Ryzom stops for a while - so not all of Ryzom is hanging when it hangs.
I have observed similar freezes on all computers I've played Ryzom on, when you go AFK for let's say 10 mins, and then zoom out or look around. As if the graphic card needs to shovel back some data - or something else has forgotten something and has to wait for it to be back. The actual freezes are about the same type of freezes, but they come all the time now on the new PC. The regular PW's are not at all a pain in the ... compared to this.
Desperate as I am I go on with some details about the Hardware:
Win7Pro64 SP1 oem
Kernel: 6.1.7601.18409
DXdiag: DX11 all tests passed
Board: M5A97 R2.0 rev 1.xx
CPU: AMD FX8350 "vishera" 8 core at 4Ghz
Graphic: Quadro K2000 2GB, Driver ver: 9.18.13.4105
Disk: def. fast enough
Mem: def. enough and fast enough
I've had the Keplar monitored in background, it is close to falling asleep with rendering Ryzom.
Gonna check the size of the fans and start playing with that "overdrive" technology tomorrow. Maybe I can deactivate any dynamic clocking - would be awesome if that caused the trouble and I can get rid of it.
Ryzom occupies about 99% of a core no matter if it's 2 or 4 Ghz, so clearly something is running at full pace which obviously doesn't need to. I'd like it stuck at 80% to have some reserves, but I doubt some skilled programmer can fix that soon - as well as the desired multi thread support.
I have an update about the behaviour tho:
Observing the CPU Graphs I saw that when it hangs the CPU load for that core goes right to the top and stays there, and the kernel times go flat down. Normal business with small moves in the graph comes back when it's working again. Looks similar to other CPU overload problems I've had with other software in the past.
I admit tho that I think Ryzom can cause that with client / server sync problems...
Remarkable is that the last played audio buffers continue playing when everything else about Ryzom stops for a while - so not all of Ryzom is hanging when it hangs.
I have observed similar freezes on all computers I've played Ryzom on, when you go AFK for let's say 10 mins, and then zoom out or look around. As if the graphic card needs to shovel back some data - or something else has forgotten something and has to wait for it to be back. The actual freezes are about the same type of freezes, but they come all the time now on the new PC. The regular PW's are not at all a pain in the ... compared to this.
Desperate as I am I go on with some details about the Hardware:
Win7Pro64 SP1 oem
Kernel: 6.1.7601.18409
DXdiag: DX11 all tests passed
Board: M5A97 R2.0 rev 1.xx
CPU: AMD FX8350 "vishera" 8 core at 4Ghz
Graphic: Quadro K2000 2GB, Driver ver: 9.18.13.4105
Disk: def. fast enough
Mem: def. enough and fast enough
I've had the Keplar monitored in background, it is close to falling asleep with rendering Ryzom.
Gonna check the size of the fans and start playing with that "overdrive" technology tomorrow. Maybe I can deactivate any dynamic clocking - would be awesome if that caused the trouble and I can get rid of it.