I can't help with that, but the idea sounds very useful :)
This optimization could done once and the results be applied to all similar devices. Drawback: you need to somehow gather and update the profiling data. Or it could be run once on the client side, then saved for future use as some Einstein file. Rerun upon CPU change. Both options might also be combined: upon loading the 1st WU ask server for profile, if it doesn't exist run this benchmark and report results as they can be used by others. You might want to gather a few samples per hardware and use the median of the results.
Might such a mechanism also be helpful for other platforms?
Your first results are in, and while variation is rather large for so few results it does appear to be significantly faster than running Android, I'd say by 10 - 20%.
Your first results are in, and while variation is rather large for so few results it does appear to be significantly faster than running Android, I'd say by 10 - 20%.
MrS
Well, the system was not left alone. I installed a printer driver, tried to find out how I can gain acces to the remote_hosts.cfg and the gui_rpc_auth.cfg. Is not as easy as in windows.
And a VNC connection was open all the time. But I leave it for today, let's see how it works when nothing else is to do.
It's a bit strange that the BOINC benchmark on the newer BOINC version under Linux is showing worse performance than the older BOINC version's benchmark under Android.
It could be related to some other CPU intensive activity on the system during the time when the benchmark was running, or the way the newer Linux ARM BOINC code was compiled. I'm not sure whether the benchmarking code has a code branch that uses NEON, I know this was at least planned to be included tho.
Since I still don't have a NEON capable ARM board under Linux (thanks to the delays of Parallella, see another thread), I would need someone to volunteer for that.
HBE
My offer is still valid. If you give me instructions I can try it on my own if you prefer that.
I've set one device to no new tasks. I found a tool to check the cpu usage and can check that afterwards. I will test that with and without BM running to see the overhead that BM brings,
Since I still don't have a NEON capable ARM board under Linux (thanks to the delays of Parallella, see another thread), I would need someone to volunteer for that.
HBE
My offer is still valid. If you give me instructions I can try it on my own if you prefer that.
I've set one device to no new tasks. I found a tool to check the cpu usage and can check that afterwards. I will test that with and without BM running to see the overhead that BM brings,
Alexander
Thanks, I'll try that later today, I'm sure we 'll find one way or another to do the "wisdom" tests on your machine. It's nothing complicated, just time consuming.
I think the performance of the ARM quad core machine of yours that does 1 WU in ca 25k ... 30k seconds is already quite impressive for an ARM CPU. Compared to, for example, the previous generation, single core ARM CPU that is used on the Raspberry Pi, the productivity is greater by a factor of ca. 15 (!!!).
The orange peak at the end is the start of the screenshot software.
Looks like the BM itself uses a lot of system resources. This is something I have seen when running Android. Crunching with native Boinc gives faster results, maybe because native boinc makes updates only once every 10 seconds and thereby uses less resources.
The file needs to be readable by the user running BOINC.
If this turns out to improve performance across most if not all ARMv7-Linux boards, we will hard-wird this wisdom into the app.
I do NOT expect this wisdom to work with Android! We are currently experimenting with wisdom files under Android as well (using OUYAs :-) ). It will also not work on Raspberry Pi's (no NEON support!), but anyway the ARMv6 BRP4 app for the Raspi under Linux already has 'wisdom' embedded in the app.
I can't help with that, but
)
I can't help with that, but the idea sounds very useful :)
This optimization could done once and the results be applied to all similar devices. Drawback: you need to somehow gather and update the profiling data. Or it could be run once on the client side, then saved for future use as some Einstein file. Rerun upon CPU change. Both options might also be combined: upon loading the 1st WU ask server for profile, if it doesn't exist run this benchmark and report results as they can be used by others. You might want to gather a few samples per hardware and use the median of the results.
Might such a mechanism also be helpful for other platforms?
MrS
Scanning for our furry friends since Jan 2002
Your first results are in,
)
Your first results are in, and while variation is rather large for so few results it does appear to be significantly faster than running Android, I'd say by 10 - 20%.
MrS
Scanning for our furry friends since Jan 2002
RE: Your first results are
)
Well, the system was not left alone. I installed a printer driver, tried to find out how I can gain acces to the remote_hosts.cfg and the gui_rpc_auth.cfg. Is not as easy as in windows.
And a VNC connection was open all the time. But I leave it for today, let's see how it works when nothing else is to do.
Alexander
I have convertet my Odroid-u2
)
I have convertet my Odroid-u2 from Android to Lubuntu
http://einsteinathome.org/host/9764941/tasks
The same board running Android was
http://einsteinathome.org/host/8007044/tasks
Processor features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
It's a bit strange that the
)
It's a bit strange that the BOINC benchmark on the newer BOINC version under Linux is showing worse performance than the older BOINC version's benchmark under Android.
It could be related to some other CPU intensive activity on the system during the time when the benchmark was running, or the way the newer Linux ARM BOINC code was compiled. I'm not sure whether the benchmarking code has a code branch that uses NEON, I know this was at least planned to be included tho.
Cheers
HB
RE: Since I still don't
)
My offer is still valid. If you give me instructions I can try it on my own if you prefer that.
I've set one device to no new tasks. I found a tool to check the cpu usage and can check that afterwards. I will test that with and without BM running to see the overhead that BM brings,
Alexander
RE: RE: Since I still
)
Thanks, I'll try that later today, I'm sure we 'll find one way or another to do the "wisdom" tests on your machine. It's nothing complicated, just time consuming.
I think the performance of the ARM quad core machine of yours that does 1 WU in ca 25k ... 30k seconds is already quite impressive for an ARM CPU. Compared to, for example, the previous generation, single core ARM CPU that is used on the Raspberry Pi, the productivity is greater by a factor of ca. 15 (!!!).
Cheers
HB
I made some screenshots
)
I made some screenshots showing the cpu usage
first one is BM running and 4 wu's running
https://dl.dropboxusercontent.com/u/50246791/BM%20and%204%20wus%20running.png
Second one is BM running and the wu's put on hold
https://dl.dropboxusercontent.com/u/50246791/BM%20running%20wus%20put%20on%20hold.png
Third screenshot shows BM shutdown and wu's on hold.
https://dl.dropboxusercontent.com/u/50246791/BM%20off%20and%20tasks%20on%20hold.png
The orange peak at the end is the start of the screenshot software.
Looks like the BM itself uses a lot of system resources. This is something I have seen when running Android. Crunching with native Boinc gives faster results, maybe because native boinc makes updates only once every 10 seconds and thereby uses less resources.
Alexander
Hi all, With help from
)
Hi all,
With help from Alex (see above), I was able to get a FFTW "wisdom file" generated on an ODROID.
It would be interesting to see what happens if one takes this wisdom file and uses it on different ARMv7 (Neon capable) - Linux boards.
The procedure is simple:
As root, create the directory
/etc/fftw
and copy-and-paste the stuff from the box below into the file
/etc/fftw/wisdom
The file needs to be readable by the user running BOINC.
If this turns out to improve performance across most if not all ARMv7-Linux boards, we will hard-wird this wisdom into the app.
I do NOT expect this wisdom to work with Android! We are currently experimenting with wisdom files under Android as well (using OUYAs :-) ). It will also not work on Raspberry Pi's (no NEON support!), but anyway the ARMv6 BRP4 app for the Raspi under Linux already has 'wisdom' embedded in the app.
Cheers
HBE
Nice to see you wising up
)
Nice to see you wising up ;)
MrS
Scanning for our furry friends since Jan 2002