Posted 6 hours ago by
Bikeman (Heinz-Bernd Eggenstein)
I notice the Raspberry Pi app has updated to 1.06 now. Were there problems with 1.05 or some further improvements?
There was a small bug fix, and the new app was compiled with a different toolchain (cross compiled on an Intel x86 Linux host like the Android (and Windows) app versions). Before that, it was a bit cumbersome to build the app on the Raspberry Pi itself, and it didn't integrate well into our automated continuous integration solution (Jenkins).
I expect no significant performance change.
Cheers
HB
Posted 1 day ago by
Bikeman (Heinz-Bernd Eggenstein)
Hi
Thanks for the feedback.
We are still fine tuning and fixing things, so expect some hickups. We are aware of the app selection problem, and we fixed some work generation problem.
Please keep testing this, at this point in testing we *want* to see errors and problems (better now than later in production :-) ).
Cheers
HB
Posted 2 days ago by
Bikeman (Heinz-Bernd Eggenstein)
Hi!
I think it's too early for funeral eulogies wrt. Intel Atom. There are (more than) rumors that Samsung will use Atoms in some future tablet and possibly even smart phones. I guess they know what they are doing. We'll see.
Cheers
HB
Posted 2 days ago by
Bikeman (Heinz-Bernd Eggenstein)
Both tasks finished and uploaded normally, waiting for validation now.
Good!!
Looking at performance the new tasks take almost twice as long as the gravity wave search currently running on Einstein, I assume this is by design.
Indeed. The code is more or less the same, but the parameters of the tasks which tell the code 'where' to look for what kind of signals, is radically different. In fact, there has probably never been so much difference between a E@H run to the previous run in this respect, so we are now verifying and possibly tweaking the set-up of this run, and that's what the test here on Albert is all about. The final run parameters on Einstein might be different, but hopefully we got it about right in the first attempt already :-).
Thanks for testing and feedback,
Cheers
HBE
Posted 3 days ago by
Bikeman (Heinz-Bernd Eggenstein)
Nice!!!
Thanks for the feedback.
Cheers
HB
Posted 3 days ago by
Bikeman (Heinz-Bernd Eggenstein)
Year, sorry, there seems to be a general problem. I'm not sure we'll be able to fix this before Tuesday (Monday is a public holiday here), so for now I have "deprecated" the new S6Directed apps. Feel free to suspend or cancel any that you received alraedy.
Cheers
HBE
Posted 3 days ago by
Bikeman (Heinz-Bernd Eggenstein)
since actual GPU use is so low (~20%) can you allow us to change the GPU utilization factor in settings?
I guess eventually we'll do that, probably with a separate setting as this app consumes more RAM on the graphics card than the BRP4 (or future BRP5) tasks. So those who are able to execute (say) 4 tasks of BRP4 in parallel might only be able to run 3 of the FGRP2 tasks in parallel, hence separate settings.
Cheers
HB
Posted 4 days ago by
Bikeman (Heinz-Bernd Eggenstein)
Interesting, thanks for additional data. We'll have to look deeper into this.
Cheers
HB
Posted 5 days ago by
Bikeman (Heinz-Bernd Eggenstein)
I have a SIV picure that shows how it looks.
I saw in post in previous version that similiar thing was found.
Hmm.. that stuff looks odd. The card with the highest load according to the diagram over a timeline has a low temperature, while another GPU with only intermittent load has a very high temperature, and the second GPU doesn't have a temperature reading at all, even tho all GPUs are very similar (Cypress GPU). So I'm not quite sure which part of the data from this tool can be trusted, because there are obvious inconsistencies.
Cheers
HB
Posted 10 days ago by
Bikeman (Heinz-Bernd Eggenstein)
It still hasn't quite finished the 1st one yet (its on 96% after 30 hours). I will provide links once it completes.
Now its finished. 31 hours and 45 minutes. Link to wu is here
Cool, validated against an Android (NEON) task that took a bit less than half as long to finish.
Cheers
HB