320.49 driver observations

archae86
archae86
Joined: 6 Dec 05
Posts: 3157
Credit: 7223594931
RAC: 1003780
Topic 197043

This is not a fully fleshed-out observation--so rather than warning of severe trouble, I am inviting others to share experience. I operate two Windows 7 hosts using GTX660 cards. I updated both today to the currently released 320.49 drivers.

So far, one of the two hosts seems to like the drivers just fine. By chance, it is working its way through a batch of 1.36 Perseus work, which has not troubled it at all despite the fact it is running boinc 7.0.64. While the host has yet to complete a WU since the conversion, I don't see obvious symptoms of distress--though the GPU load seems mostly to stay at 98%--higher than I am used to, and there may well be trouble not yet apparent to me.

For the other host trouble was quickly apparent. This host was running Perseus 1.33 work, having finished a few 1.36 units successfully, but erroring out on rather more. The GPU loading showed about a 30% duty cycle of dropping to zero--a few seconds at a time. I believe this persisted when I stopped running TThrottle, and think it returned to normal when I reverted to nvidia driver 314.07.

However it is possible that I stumbled, and have misconstrued normal TThrottle response for a graphics driver change effect. Or it is possible that the interaction of interest is between TThrottle and the driver, not purely the Einstein application and the driver.

This was originally a warning post about 320.49 and Perseus, but as I've become less confident while writing, I've changed the title before posting to invite others to share 320.49 experiences--good, bad, and neutral.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

320.49 driver observations

Quote:


For the other host trouble was quickly apparent. This host was running Perseus 1.33 work, having finished a few 1.36 units successfully, but erroring out on rather more. The GPU loading showed about a 30% duty cycle of dropping to zero--a few seconds at a time. I believe this persisted when I stopped running TThrottle, and think it returned to normal when I reverted to nvidia driver 314.07.

Am i looking at the correct host? - but i see that host as generating some errors before the upgrade.

Here my similar experience after upgrading it seemed seemed fragile. I´m trying to get a week of no errors (no screen resetting in my case) before upgrading again.

archae86
archae86
Joined: 6 Dec 05
Posts: 3157
Credit: 7223594931
RAC: 1003780

RE: but i see that host as

Quote:
but i see that host as generating some errors before the upgrade.


Yes, of my two GTX660 hosts this one has been far more likely to generate Einstein errors. Usually this takes the form of suddenly erroring out between one and three active WUs and downgrading to much lower power/lower progress state until I notice and reboot.

I've tried to lower the clock rate slightly using OC_Guru, but it does not seem to pay very close attention to my instructions provided that way. I've left the more modern system on 320.49, and the one which had trouble has stayed reverted to 314.07.

Neither system has errored out a new WU since I made my post. The execution times are extended well above minimum by my use of TThrottle for summer-time power reduction. I roughly try to throttle back enough to compensate for the power burned by my evaporative coolers.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.