Posts by Bikeman (Heinz-Bernd Eggenstein)

WARNING: This website is obsolete! Please follow this link to get to the new Albert@Home website!

41) Message boards : Problems and Bug Reports : Test project Albert@Home now uses HTTPS (Message 112517) Posted 9 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: With the website, I would guess (haven't checked) that the cookie is set when user logs on and gets deleted at log off. Does it change for every page served? Does it change during a session? Does it need to be protect seeing as its already on the users pc. See my message over at Einstein@Home. For best security, you will want to have the whole session under HTTPS, not just the logon page. Cheers HB
42) Message boards : Problems and Bug Reports : Test project Albert@Home now uses HTTPS (Message 112515) Posted 8 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: I've posted some comments in the same thread over at Einstein. Basically if you switch to https most proxy servers will act as pass thru which means they lose their caching ability. I would suggest only certain bits of the system use https (eg scheduler, website logon) rather than the whole lot. That is certainly a point to consider, but OTOH, what caching would be affected by this exactly? For the forum, no caching by the proxy is useful and therefore none should be allowed anyway (you don't want to get a view of the forum as it was minutes ago...it has to be "live"). Also, just having the logon page secured but then later transfer the session credentials (cookies etc) in plain text doesn't help security: it might help against intercepting the password but not against hijacking a session ... The other big remaining family of web accesses would be downloads. For a single host per proxy, downloading the same file more than once should be a rare thing. But yes, this might be an issue for big "farms" that share one caching proxy. We could indeed exempt those downloads from https. Cheers HB
43) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112512) Posted 7 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Hi fellow Raspberry Pi fans ;-) I have released a new test version (1.04) which should be quite a bit faster than the previous one. In general the performance should be somewhere between that of the Android ARMv6 (VFP) 1.03 version and the ARMv7 (NEON) 1.03 version (scaled by clock rate). There were no fundamental changes, just compilation option settings. If I find the time to write API wrappers, I will later try the FFTS library which is now used on Android over at SETI@Home, but for now, the version sticks to the good old FFTW. Cheers HB
44) Message boards : Problems and Bug Reports : FGRP application v 1.07 (OPENCL) feedback thread (Message 112511) Posted 7 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Hi Thanks for the feedback. I have been running the new version for the past two days. I am actually seeing significantly better performance compared to the previous version I ran a while back. This is surprising, we didn't change anything that should have a significant effect on performance. We made the logging less verbose which might help performance a tiny bit, but not more. Some volunteers might see performance increases or even decreases because the tasks are now actually running on the GPU intended by BOINC for it and not the one picked erroneously by the app before (which might be busy with other tasks already), but I understand your host here at Albert has only one GPU installed, so this should not happen in your case. In Linux via a GTX 680 and quad core processor - HT disabled, I have seen the following runtimes: 1-task - ~796 seconds per task 3-tasks - 885-963 seconds per task Note however that setting the nr of concurrent GPU jobs in the profile currently has NO effect on the FGRP app, we didn't enable this feature for the Fermi search, yet. So one would need a app_info.xml or app_config.xml file for the FGRP app. I'm wondering whether BOINC is running BRP4 jobs and FGRP jobs in parallel in a "mixed" configuration (e.g. FGRP needs 1 GPU, BRP4 0.333 GPUs. Will BOINC let all BRP4 tasks finish and hold of running new ones before letting FGRP crunch?) Cheers HB
45) Message boards : Problems and Bug Reports : Test project Albert@Home now uses HTTPS (Message 112509) Posted 3 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: We switched back to HTTP for now, there could be intermittent glitches because of further tests to fix the certificate problem, tho. Cheers HB
46) Message boards : Problems and Bug Reports : Test project Albert@Home now uses HTTPS (Message 112503) Posted 3 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: I see...I notified our admin at the UWM . Cheers HB
47) Message boards : Problems and Bug Reports : Test project Albert@Home now uses HTTPS (Message 112497) Posted 3 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Dear volunteers We have switched our test project, Albert@Home, to use HTTPS instead of plain HTTP. This applies not just to the Web pages, but also to the communication between the BOINC client and the project site. We'd like to use this as a test to see if this would cause any problems for volunteers (proxies, (personal) firewalls, etc). If you have any problems (unable to connect, unable to get tasks, warning messages while browsing the site.....anything that is unusual), you might not be able to post in this forum on Albert, so please feel free to report at Einstein@Home, e.g. here: http://einstein.phys.uwm.edu/forum_thread.php?id=10095 Cheers HB
48) Message boards : Problems and Bug Reports : FGRP application v 1.07 (OPENCL) feedback thread (Message 112496) Posted 3 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Good to hear that! The plot is a good demonstration of what the current app does. Like the very first GPU version of BRP4, it uses the GPU only for some parts of the computation (FFT) and the rest is handled by the CPU. Needless to say, we will try to improve this in future versions. Cheers HB
49) Message boards : Problems and Bug Reports : Wrong GPU reported in output file. (Message 112491) Posted 2 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Hi all, Thanks for your patience, hopefully the bug discussed in this thread is finally fixed in this new version discussed here: http://albert.phys.uwm.edu/forum_thread.php?id=8975. Thanks for the testing!!! Cheers HBE
50) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112490) Posted 2 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Hi all, A new test version (1.07) of the FGRP#2 OpenCL app is out now. For feedback, plese go to this new thread: http://albert.phys.uwm.edu/forum_thread.php?id=8975. Thanks to all the testers who reported their observations wrt. the previous version. I hope you give this new one a try as well. Cheers HBE
51) Message boards : Problems and Bug Reports : FGRP application v 1.07 (OPENCL) feedback thread (Message 112489) Posted 2 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Dear all, I just released 10 different new app versions for FGRP#2, with version number 1.07: OSX OpenCL x (ati , nvidia) Win x (32 bit, 64 bit) x (ati, nvidia) Linux x (32 bit, 64 bit) x (ati, nvidia) This new version contains bug fixes only, performance should be the same as in previous version. Bugs addressed: - Failure to run on the correct GPU (the one assigned by the BOINC client) for hosts that have more than one OpenCL capable GPUs installed - Too verbose log output so that the beginning of the log would be truncated when uploaded to the server - Error handling was incomplete in previous version. So now you should be able to see in the results view of the web interface that the app logs the brand/type of the graphics card it uses in the log (as with BRP4), and you can check that this makes sense. Thanks go especially to Richard Haselgrove and others who experienced the GPU detection problem, reported it here and helped in tracking it down. Sorry it took (me) so long to fix this. Please report any problems or other feedback in this thread. Cheers HBE
52) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112486) Posted 1 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Will the new version work on cards with 512Mb, do you know? (ref. Message 112402). Memory requirements will be unchanged, sorry. HB
53) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112483) Posted 1 May 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: This is not a problem or bug but there is no other thread possibility then news. The FGRP (gamma ray) via ATI are finished in around 1350 seconds on a old HD5870 card. On cpu via Einstein@home (also gamma ray, I thus I think the same)it takes my pc around 8200 seconds to finish. So a good improvement. Thanks for the feedback. Yes, the good old HD 5850 and 5870 are quite fast, if only they would consume less power :-[ . I'm quite satisfied with the performance for the moment, but there still is some work to do under the hood (fixing a bug of mine in GPU detection, reducing verbosity of log, error handling needs to be more robust ....). But I think I can put out a new fixed version tomorrow latest. Cheers HB
54) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112482) Posted 30 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: First Valid result on my Galaxy S 1 mini with app 1.03(VFP) http://albert.phys.uwm.edu/results.php?hostid=6955&offset=0&show_names=0&state=3&appid= long runtime but valid :) Congrats :-) Good to have some ARMv6 testers here! Given the speed of the devices, it takes some time to get enough validated results (say, around 200) that you will want to see before being confident that cross validation with ARMv6 works. I have one of the few other ARMv6 Android devices on Albert and the run-time is roughly the same. Cheers HB
55) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112481) Posted 30 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: New SETI@Home app version Added by: matszpk , 2013-04-29 21:45 This version (0.1.1) of SETI@Home application brings new support for VFP based on LibFFTS (instead PFFFT) and improved support for NEON. You can expects 20%-30% speedup on a ARM processors with VFP. Could this help our app as well or is it already in use? It's interesting to read, in the discussion on SETI@Home, that libFFTS is considerably faster than FFTW for ARM. So yes, this could be interesting. FFTW was our natural choice for the initial app version on ARM because we use it for all CPU versions so far. But that doesn't mean it has to be that way, e.g. the BRP4 GPU versions use different FFT libs, obviously, for CUDA and OpenCL. And all those versions validate against each other quite happily. OTOH the libFFTS seems to be quite new and maybe it needs to settle and mature a bit longer. Thanks for the pointer Cheers HB
56) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112476) Posted 28 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: My Galaxy S2 needed 102h for the first one, a v1.02, for some meagre 63 credits. But it gave me the required 100h for bronze in WUProp in a single WU, that's fine ;) I just reseted the project and got a v1.03 (NEON), and it's now, that's after 1:36h, at 13%. So this one will take about 12h, an more than eightfold decrease in crunch-time! cool!! To be fair, the newest non-NEON app version, "1.03 (VFP)" seems to be twice as fast as the old 1.02 , so that would mean a factor of 4 between NEON and non-NEON on the same hardware. Still impressive. I've even seen a Galaxy S2 do a task in about 9hrs when crunching on one core only. When crunching on 2 cores, the phone needed some additional cooling (I think Bernd took a photo of the cooling solution :-) ) to keep it below 45 deg C (the level configured in the test to trigger app suspension for thermal protection). Personally I think a (CPU) runtime of up to ca 16 hrs per task would be ok. This would mean that if the device is allowed to crunch for only a few nights per week while connected to a charger, it would easily make the deadline of 14 days for BRP4(U) tasks. Thanks for the feedback Cheers HB
57) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112466) Posted 24 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Is NEON a standard feature of the arm7 devices? My task list shows that they are crunching 1.03 NEON apps, but computer details don't say anything about NEON. edit: wikipedia says NEON is standard on cortexA8 and optional on cortexA9 but no word about arm7. Hi One has to be careful about the ARM nomenclature: ARMvn (as in ARMv6, ARMv7) designates a generation of CPU architecture. ARMn (as in ARM7 or ARM11) designates a family of ARM processors belonging to the same architecure, but an architecture can comprise more than one family (it's more like individual models or lines of similar models). So for example the processor of the Raspberry Pi is actually an ARMv6 (architecture) and at the same time an ARM11 (family) CPU.... This is further complicated by the fact that ARM (the company) is not really a chip manufacturer: they do not produce chips themselves (like Intel does), they just license the design to others (Apple, Samsung, NVIDIA, ...whoever) who then build their own CPUs. The ARM designs are modular, so you can add certain optional modules from the ARM "design portfolio" (like NEON) to your CPU or not, so NEON will be on some (most) ARMv7 CPUs but not on others. Cheers HB
58) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112459) Posted 24 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: p2030.20120226.G194.26-02.01.S.b6s0g0.00000-792-4 using einsteinbinary_BRP4U version 103 (VFP) in slot 0 Yes it runs brp single dm 1.03 but it looks like itÂ´s how you said with neon doubled as fast as with 1.02 sorry that i aborted the 1.02 so you have no comparison I see. No, you are not running a NEON version, you are running the new 1.03 VFP version. The Neon version would show up as "einsteinbinary_BRP4U version 103 (NEON)" now after 9:48:06 it has crunched 11,273 percentage of the task isnÂ´t that good for this machine? Should be normal for this type of hardware. 600 Mhz isn't that fast, and ARMv6 is basically a 10 year old design. More modern ARMv7 with NEON and higher clock rates can be up to ca 9 times as fast (!). Thanks for testing HBE
59) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112454) Posted 24 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Hi I'm confused... But what i can see now in crunching time is that with the 1.03 app it takes a little less then 1h to crunch 1% so i have done with that phone in 20h 20 ore more then 20 percentage of the task so itÂ´s how you said Bikeman. The armv6 runs with doubled speed with this NEON app instead of app 1.02 Are you saying you are running the 1.03 app on your ARMv6 device??? That shouldn't work.... the 1.03 app version is compiled for ARMv7 CPUs with NEON, and ARMv6 CPUs don't come with NEON. Sure enough, your CPU doesn't report the NEON feature in the scheduler request CPU features: swp half thumb fastmult vfp edsp java Theoretically, Android could emulate NEON (and ARMv7) instructions by catching the "illegal instruction" interrupt that would occur in such a situation and then emulate the instruction in software, but that should be sooooooo sloooooow. Cheers HB
60) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112453) Posted 24 Apr 2013 by Bikeman (Heinz-Bernd Eggenstein) Post: Hi HB, Any idea when us Raspi users will see this new version? I currently get about 48 hours a work unit using the old app with a medium overclock. There can't be a NEON version for Raspi (it has an older ARMv6 w/o NEON), and the new version for the Android ARMv6 was all about compiler settings. I played around with those settings for the Raspi compile but didn't see any significant performance increase so far. I'm looking into other ways of (moderately) speeding it up, tho, so there might be a new version "soon". ;-) Cheers HB

Previous 20 · Next 20

This material is based upon work supported by the National Science Foundation (NSF) under Grant PHY-0555655 and by the Max Planck Gesellschaft (MPG). Any opinions, findings, and conclusions or recommendations expressed in this material are those of the investigators and do not necessarily reflect the views of the NSF or the MPG.

Copyright © 2024 Bruce Allen for the LIGO Scientific Collaboration