Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
Message boards :
Project Staging Area :
AVX builds of pfgw/llr
| Author |
Message |
|---|
rogueVolunteer developer
Send message
Joined: 8 Sep 07
Posts: 1256
ID: 12001
Credit: 18,565,548
RAC: 0
 
|
|
I need to make a request to everyone here. Please do not use builds of llr or pfgw that have not been released by Jean or me. There are two major reasons for this.
The first is version control. When Jean or I make any changes to our code base, such as upgrading gwnum, we change the release number. This is necessary so that when someone says llr 3.8.7 or pfgw 3.6.1 that we know the precise version of gwnum linked with that version. Right now we have multiple versions of llr 3.8.7 and pfgw 3.6.1, each with a different version of gwnum.
The second is correct results. We have never taken the first release or two of a new version of gwnum. The reason is that they tend to be alphas (or pre-betas) and are known to produce bad results. We have discovered that gwnum v27.2 can produce incorrect results. I have up to three months of re-testing due to my own build of pfgw + gwnum v27.2 because of these bugs in gwnum v27.2. I discovered it by accident this past weekend. I only released with gwnum v27.4 because the ones from v27.2 had been fixed and v27.4 supposedly fixed the problems with AMD Bulldozer.
Right now we have a problem. Some of you are running builds of llr/pfgw not released by Jean or me. You need to stop running those builds as soon as you can.
If you have done any tests with pfgw 3.6.1 + gwnum v27, it is likely that your results are invalid, which in turn could lead to a lot of rework for projects that rely on pfgw. Unfortunately because of the first issue above, there is no way that we can know who is running which build or which build was used for each PRP test. For PRPNet, the version of pfgw and llr is tracked, but it doesn't track the version of gwnum linked with pfgw/llr.
Those of you running llr are in the same boat. Jean hasn't released an official build of llr + gwnum v27. Although unofficial builds might return correct results, they are much more likely to be wrong than the official build.
If you have any issues with this or questions about it, feel free to ask. | |
|
|
|
|
Could you point/link me to the AVX versions that we should be using.
Thanks in advance.
____________
147*2^1392930+1 was my first prime number found, others have followed :) | |
|
|
|
|
The latest llr is built with gwnum 27.4. I have never seen any invalid results. What problems has been adressed with llr/pfgw? | |
|
|
|
|
Could / would this explain why I have seen invalid / inconclusive results over the last several weeks on my AMD non-AVX system running the stock apps provided via BOINC (no app_info file); a system that has almost NEVER seen invalids and currently running CUL, WOO, and PSP llr's?
____________
There's someone in our head but it's not us. | |
|
rogueVolunteer developer
Send message
Joined: 8 Sep 07
Posts: 1256
ID: 12001
Credit: 18,565,548
RAC: 0
|
The latest llr is built with gwnum 27.4. I have never seen any invalid results. What problems has been adressed with llr/pfgw?
I don't know what bugs existed in earlier builds of v27, but I know they existed because I experienced them firsthand with my own build that I was testing.
This does not change my recommendation. Jean has his own reasons for not releasing. It is possible that he has found other issues.
The point is that Jean and I do a certain amount of testing before we release. If someone "jumps the gun" it is very likely that they have not done any testing thus exposing too many people to the risk of a bad build. | |
|
rogueVolunteer developer
Send message
Joined: 8 Sep 07
Posts: 1256
ID: 12001
Credit: 18,565,548
RAC: 0
|
Could / would this explain why I have seen invalid / inconclusive results over the last several weeks on my AMD non-AVX system running the stock apps provided via BOINC (no app_info file); a system that has almost NEVER seen invalids and currently running CUL, WOO, and PSP llr's?
I don't have an answer for your question because I don't know what build of llr is supplied with BOINC. | |
|
|
|
Could / would this explain why I have seen invalid / inconclusive results over the last several weeks on my AMD non-AVX system running the stock apps provided via BOINC (no app_info file); a system that has almost NEVER seen invalids and currently running CUL, WOO, and PSP llr's?
I don't have an answer for your question because I don't know what build of llr is supplied with BOINC.
Let me clarify (hopefully) - I am not concerned that there is a problem with the stock versions - I am curious as to whether my "invalids" are in fact valid, but don't happen to match the matching invalids deemed to be valid based purely on the fact that two matching wrongs do make a valid wrong. (I apologize in advance for purposefully butchering that sentence, I am sure it will not translate well)
I realize the odds of a false prime are effectively nil and that issue has no bearing on this discussion.
The reason that I am asking is that the number of completed results finally deemed invalid (read as differing residues) on a per test basis seems to be increasing on the longer running llr's.
For example:
My system completes work unit 123 using the official release - states that it is not prime - returns a residue of 9999. Result is marked pending.
System 2 completes the same work unit using unofficial release X - states it is not prime - returns a residue of 8888. The two completed tasks are marked inconclusive.
System 3 completes the same work unit using unofficial release Z - states it is not prime - returns a residue of 7777. The three completed tasks are marked inconclusive.
System 4 completes the same work unit using unofficial release X - states it is not prime - returns a residue of 8888. Results one and three are marked invalid. Results two and four are marked valid.
No real harm other than the "valid" results are incorrect and unlikely to ever be validated. My result, the only correct result, is tossed and I have wasted 2+ days compute time.
____________
There's someone in our head but it's not us. | |
|
|
|
No real harm other than the "valid" results are incorrect and unlikely to ever be validated. My result, the only correct result, is tossed and I have wasted 2+ days compute time.
If your wingmen were using unofficial versions of llr, you would see "anonymous platform" on the app column, because those versions demand an app_file (that causes the "anonymous platform label). If you only see the name of the app (e.g. "PPS (LLR) v 6.10"), then they are using the same stock app you are. If your residues did not match with a wingman not using anonymous platform, then that was not caused by different versions of llr. Looking at your host's tasks (only the invalid and inconclusive ones), you can see that all of them have different residues than those of at least one wingman also using stock app.
I've seen errors like that on very long tasks (Cullen and SoB) on a host that did thousands of consecutive PPS without a single error. | |
|
|
|
|
To quote rogue and make sure that this thread gets back on track
Please do not use builds of llr or pfgw that have not been released by Jean or me.
No real harm other than the "valid" results are incorrect and unlikely to ever be validated. My result, the only correct result, is tossed and I have wasted 2+ days compute time.
If your wingmen were using unofficial versions of llr, you would see "anonymous platform" on the app column, because those versions demand an app_file (that causes the "anonymous platform label). If you only see the name of the app (e.g. "PPS (LLR) v 6.10"), then they are using the same stock app you are. If your residues did not match with a wingman not using anonymous platform, then that was not caused by different versions of llr. Looking at your host's tasks (only the invalid and inconclusive ones), you can see that all of them have different residues than those of at least one wingman also using stock app.
I've seen errors like that on very long tasks (Cullen and SoB) on a host that did thousands of consecutive PPS without a single error.
Agreed - The long tasks are susceptible to many external issues - and had I thought about it for more than 30 seconds I would have noticed, as you did, that my "case" did not fit the facts - but it does provide a bit of food for thought.
I do apologize for diverting this thread from it's very real and important message -
____________
There's someone in our head but it's not us. | |
|
|
|
|
Hi,
Could you send me links to some of the WUs that you have seen your results declared invalid by two other matching residues - I'd like to check them!
Cheers
- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime! | |
|
Message boards :
Project Staging Area :
AVX builds of pfgw/llr |
