Double your PPD almost ?

[MtM]

Same here, I understand the position you took as well but understanding and feeling the same way in this case surely didn't happen to coincide. If you ask me, if we could prevent some runs/clone's from getting an infected gen it would have been all worth it, that is if PG would be able to seperate them with less effort then it would take to just redo all of them ( again, only if the results are really not trustworthy on which only they can give the final answer ). If they can not seperate them, or if the effort needed to do so would be just as big as having to repeat everything you are right it doesn't matter what we do now, or what we tell others to do. I'm just trying to be abit optimistic about the posibilities.

Edit: didn't see your post but thanks ihaque!

[P5-133XL]

I've already e-mailed our company contacts; we'll see what happens. Please don't fill up Scott's inbox with PMs . I'll be spending some time today trying to figure out what's going on with this driver revision.

I deleted the PM.

[shatteredsilicon]

Don't you all realize, that it probably doesn't matter if you are using the 185.20 driver or not: Because someone out there will be.

Spot on. Thus, all it takes is a single driver fsck-up and untold amounts of data are garbage. In fact, it's worse than that. If there ever was a driver release that is producing garbage, effectively no results thereafter can be trusted again until the client can detect the driver version and shut down. One might hope that the error checking would catch such issues, but if it cannot do this with 100% reliability, then the knock on effects just don't bear thinking about.

[MtM]

Don't you all realize, that it probably doesn't matter if you are using the 185.20 driver or not: Because someone out there will be.

Spot on. Thus, all it takes is a single driver fsck-up and untold amounts of data are garbage. In fact, it's worse than that. If there ever was a driver release that is producing garbage, effectively no results thereafter can be trusted again until the client can detect the driver version and shut down. One might hope that the error checking would catch such issues, but if it cannot do this with 100% reliability, then the knock on effects just don't bear thinking about.

But there is a diffrence between run/clone and generation.. Not every run and clone could have been affected at any given point in time, even if all it takes is a single generation to affect a whole run/clone. Though statistically you would be right I guess with so many people allegedly running them, and run/clone's running paralell it's almost seemingly impossible that somewhere along the line there won't be a suspicious driver to influence a gen in them.

[HD580]

Folding project 5900. 5903 and 5904 I can 100% replicate this boost when playing media on my PC:

In the second after I hit winamp play button the cards VRM's Amps hit from 22A to 55-75 and in that same second my PPD jumps by 5000points. Then it fluctuates between 55A and 75A. Not second after or before. Not 1000 PPD or 2000 but even 40%-65%. Usually from 8000PPD to 13000PPD. In the same second I hit stop (edited-->not pause), production decreases by that same amount (about 5000PPD). In that same second cards VRM's get back to 22A and starts fluctuating from 22-75A -not between 55A and 75A. Same time I hear famous squeking form the card, and the noise is very much continuous.

I can reproduce this by hitting play button and it works every single time. 100% confirmed. I can even make a videoclip of this, but this is true, believe me! This is not working on 57xx or other projects though. On these 185.xx drivers, projects 57xx works normally ie my card hits to 85celsius and VRM aperage fluctuates only marginally from 72 to 75A.

new thread we need new thread for this. I been having this since nearly the beginning of core14/59xx with 182.xx and 185.20 drivers.


viewtopic.php?f=52&t=9168
Edit by Mod:
I've tried to consolidate all of that discussion in that one place.
-b

[ihaque]

There was a bug in the core that interacted with some changed behavior in the 185.20 driver. The good news is that it doesn't appear that this particular error "contaminated" any runs; the effect here was that some results were simply not calculated (and therefore not returned), not that returned results were corrupt. Core execution was faster precisely because not all the calculations were done.

I've released an updated version (1.25) of the core that appears to fix the bug; your clients should automatically update when they get a new 59xx WU assigned, or you can manually force an update by stopping the client, deleting FahCore_14.exe, and restarting. Please reply to this thread if you still see the PPD "doubling" with the 1.25 core, as the core results are definitely missing some returned data under those conditions.

Thanks to mikeb12, Turnoz, and the F@h beta testers for helping me to unravel this issue.

[mikeb12]

That's the most refreshing news I've heard in this thread.

[Atlas Folder]

Thanks for the work and the explanation ihaque. I'm very relieved to know that this problem hasn't done irreparable harm.

Jason

[werty316]

Did the combination of core version 1.24, display drivers 185.20 and Vista x64 produce any issues, problems or errors when crunching and sending back completed data?

[ihaque]

The data that were sent back appear to be alright. The problem is that not all the data that should have been calculated and sent back actually was - it was a situation of complete credit for incomplete results.

[werty316]

The data that were sent back appear to be alright. The problem is that not all the data that should have been calculated and sent back actually was - it was a situation of complete credit for incomplete results.

Ah ok, thanks for the clarification. Too bad it was too good to be true but it was fun while it lasted

[Turnoz]

Happy to have been a part of this. Although it seemed like a huge can of worms at first, not much harm was done (except to points:P) and hopefully this will prevent similar mistakes from happening.

[powerarmour]

So I assume this means that the folks that sent in WU's using the 185.2x drivers during this period get to keep their erm *cough* 'points'...?, or will there be any retroactive finger chopping...!

[Turnoz]

So I assume this means that the folks that sent in WU's using the 185.2x drivers during this period get to keep their erm *cough* 'points'...?, or will there be any retroactive finger chopping...!

That would be hard to track down.... You would have to check what their average ppd was before and see the jump which is a lot of work.

[pmsfh2008]

I would like to 2nd the request to close this thread.
A summary of the discussion/findings should be added.
Thanks to all that contributed in bringing this to a conclusion.