@Richard: this is good news. However, note there is another validation problem in BRP4: The Android (10 and up, actually the latest ARM CPUs) devices seem to decide on their own whether and when to use FMA in the FFT(W), at least I couldn't find a way to disable it there. If your results happen to be compared with two such devices, chances are that your results will be found invalid, although being the "more correct" ones.
I'll keep feeding up the data, but I'll have to leave the interpretation to you. In particular, you still have wingmate data display suppressed on the website, so I can't see what any problems are until the 'inconclusives' resolve into valid or invalid.
Another invalid - workunit 663476189. Again, two ARMs ganging up on the interloper...
Talking of ARM devices - my own ARM tablet 12858658 seems to have stopped requesting tasks since I started this test. Would it be fair to blame that on the battery overheating in this current weather? I think I'll turn it off and try again when things are cooler.
I don't understand these folk without air conditioning. My Aunt lives in a similar area to you Richard, and she thinks it's perfectly ok to go to sleep with the house at 28C! Above 20C and I just don't doze off.
You should be able to see the battery temperature in something like CPU-Z (they have an android version). Boinc defaults to not letting it get above 40C, although assuming you have it plugged in, it shouldn't heat the battery at all?
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
Yes, it was in its normal place, downstairs away from direct sunlight. When I unplugged the power cable, it noticed, and said the computation would resume with power.
The slightly curious thing is that it requested work from WCG (got none), but wouldn't request work from Einstein. It was running, viewable on remote monitoring.
Another show. (Bernd, let me know when you have enough data from this machine)
All (324)
In progress (49)
Pending (70)
Valid (147)
Invalid (8)
Error (0)
Valid is going up nicely, and invalid remains at 8, but the interesting one is the one that's missing (nudge - wishlist!)
Inconclusives have shot up to 50 - I presume as the slower ARM devices, possibly weekend-only crunchers, report in.
One interesting invalid was 663579045 - there's an anonymous platform app (again on ARM) in the mix. I know that for Gravity Wave - locality scheduler - work, two 'unreliable' apps aren't allowed on the same workunit: has anything like that been considered here?
As the weather gets cooler, I'll see how my UHD 620 GPU fares with the Beta app: it was even worse on the old app. But it's an ultraportable laptop with a weak cooling system - I don't want to have to replace the fan again!
So, like - to get my head around this - we don't know the actual form, or even the presence, of an FMA function until runtime and only then by looking at result characteristics ? For instance : can we ( simply! ) test or establish whether/not the FMA uses a higher precision for intermediate values ( which would be nice) ? This is all down to the 'wiggle room' within the OpenCL spec, right ?
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Our first invalid - workunit
)
Our first invalid - workunit 662999449. Me and three assorted ARM devices, one of which was also marked invalid. Look at those runtimes!
@Richard: this is good news.
)
@Richard: this is good news. However, note there is another validation problem in BRP4: The Android (10 and up, actually the latest ARM CPUs) devices seem to decide on their own whether and when to use FMA in the FFT(W), at least I couldn't find a way to disable it there. If your results happen to be compared with two such devices, chances are that your results will be found invalid, although being the "more correct" ones.
BM
I'll keep feeding up the
)
I'll keep feeding up the data, but I'll have to leave the interpretation to you. In particular, you still have wingmate data display suppressed on the website, so I can't see what any problems are until the 'inconclusives' resolve into valid or invalid.
next time edit your post
)
next time edit your post deleting everything and put in 2 dots, ie periods, and the 2nd post will disappear
Thanks, Mikey. Another
)
Thanks, Mikey.
Another invalid - workunit 663476189. Again, two ARMs ganging up on the interloper...
Talking of ARM devices - my own ARM tablet 12858658 seems to have stopped requesting tasks since I started this test. Would it be fair to blame that on the battery overheating in this current weather? I think I'll turn it off and try again when things are cooler.
I don't understand these folk
)
I don't understand these folk without air conditioning. My Aunt lives in a similar area to you Richard, and she thinks it's perfectly ok to go to sleep with the house at 28C! Above 20C and I just don't doze off.
You should be able to see the battery temperature in something like CPU-Z (they have an android version). Boinc defaults to not letting it get above 40C, although assuming you have it plugged in, it shouldn't heat the battery at all?
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
Yes, it was in its normal
)
Yes, it was in its normal place, downstairs away from direct sunlight. When I unplugged the power cable, it noticed, and said the computation would resume with power.
The slightly curious thing is that it requested work from WCG (got none), but wouldn't request work from Einstein. It was running, viewable on remote monitoring.
One to investigate one cooler morning. It rests.
Returning you to your
)
Returning you to your scheduled technical news - evening report.
All (242)
In progress (47)
Pending (66)
Valid (97)
Invalid (3)
- leaving 29 inconclusive (that's why we have to run these tests).
The third invalid was like the second - two ARMs outvoting me.
Another show. (Bernd, let me
)
Another show. (Bernd, let me know when you have enough data from this machine)
All (324)
In progress (49)
Pending (70)
Valid (147)
Invalid (8)
Error (0)
Valid is going up nicely, and invalid remains at 8, but the interesting one is the one that's missing (nudge - wishlist!)
Inconclusives have shot up to 50 - I presume as the slower ARM devices, possibly weekend-only crunchers, report in.
One interesting invalid was 663579045 - there's an anonymous platform app (again on ARM) in the mix. I know that for Gravity Wave - locality scheduler - work, two 'unreliable' apps aren't allowed on the same workunit: has anything like that been considered here?
As the weather gets cooler, I'll see how my UHD 620 GPU fares with the Beta app: it was even worse on the old app. But it's an ultraportable laptop with a weak cooling system - I don't want to have to replace the fan again!
So, like - to get my head
)
So, like - to get my head around this - we don't know the actual form, or even the presence, of an FMA function until runtime and only then by looking at result characteristics ? For instance : can we ( simply! ) test or establish whether/not the FMA uses a higher precision for intermediate values ( which would be nice) ? This is all down to the 'wiggle room' within the OpenCL spec, right ?
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal