Posts by Bernd Machenschalk

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

21) Message boards : Wish List : App for Intel HD graphics? (Message 112689) Posted 10 Jul 2013 by Bernd Machenschalk Post: In general, sorry for the somewhat rushed issuing of the Intel GPUs on Einstein. We needed a bit more computing power to help the CPUs crunching through the new Arecibo data, so we decided to just have a try with the Intel GPUs, as the damage, if any, would be very limited. BM
22) Message boards : Wish List : App for Intel HD graphics? (Message 112688) Posted 10 Jul 2013 by Bernd Machenschalk Post: Edit 2: Hmm. Something seems wrong. Can't get work (on einstein): What does the scheduler log say? Can you give me a hostid that I can look up? BM
23) Message boards : Wish List : App for Intel HD graphics? (Message 112687) Posted 10 Jul 2013 by Bernd Machenschalk Post: @ BM: The settings needs rework; there is no tab to enable Intel-gpu like it is for AMD and nVidia and the GPU utilization factor of BRP apps has no effect. Setting to disable INTEL GPU was added last night. I honestly don't expect anyone to stress these poor little Intel GPUs with more than one task at a time, so the "GPU utilization factor" was disabled there on purpose. BM
24) Message boards : Wish List : App for Intel HD graphics? (Message 112682) Posted 9 Jul 2013 by Bernd Machenschalk Post: We released a BRP4 app version for Intel HD GPUs over at Einstein. BM
25) Message boards : Problems and Bug Reports : S6 Directed Search (CasA) Feedback thread (Message 112672) Posted 5 Jul 2013 by Bernd Machenschalk Post: Will take another week. The scientist that have the final word on it are away for another conference. But technically it looks good so far. BM
26) Message boards : Problems and Bug Reports : S6 Directed Search (CasA) Feedback thread (Message 112668) Posted 1 Jul 2013 by Bernd Machenschalk Post: Thanks for the feedback. There was a problem in the validator that should now be fixed. Later today I'll see what I can do about the older "validate error" results. BM Edit: I issued all "validate error" tasks that were still in the DB for "re-validation" by the new validator
27) Message boards : Wish List : App for Intel HD graphics? (Message 112640) Posted 20 Jun 2013 by Bernd Machenschalk Post: AFAIK Intel doesn't even provide an OpenCL-capable driver for Linux. BM
28) Message boards : News : Einstein@Home down (Message 112601) Posted 13 Jun 2013 by Bernd Machenschalk Post: The main Einstein@Home server crashed about half an hour ago with a filesystem error. Checking and repairing this will take a while. We are trying to keep the downtime below 24h. (since we don't have any means to notify people over at Einstein, I'm doing this here) BM
29) Message boards : Problems and Bug Reports : S6 Directed Search (CasA) Feedback thread (Message 112565) Posted 23 May 2013 by Bernd Machenschalk Post: One thing we need to test most is the workunit generator, which in a sense is very different from the ones we used before. When we find it doesn't produce the workunits as we want it, we will need to cancel the workunits and start over again, even if there is nothing technically wrong with the workunits it already produced. We try our best to detect errors as early as possible, in this case before too many tasks are sent out, but I suspect canceling S6CasA workunits will happen rather frequently in the next few days. After all, this is our test project. BM
30) Message boards : Problems and Bug Reports : S6 Directed Search (CasA) Feedback thread (Message 112546) Posted 19 May 2013 by Bernd Machenschalk Post: When I checked the project directory I found a few files that ended with "-LV" e.g. "h1_0050.80_S6Direct__S6CasAa_50.9Hz_9_0_0-LV" and I'm now wondering if these are actually the files that should have been uploaded. Yes, this is correct. This problem should be fixed with the App version 1.01 which I just issued. The files with names ending in "-LV" can and must be deleted manually, the Client can't do this. Apologies for the inconveniences. I also noticed that the plan class has a minor spelling error in the word "search". Good catch! Should be fixed now, too. BM
31) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112477) Posted 29 Apr 2013 by Bernd Machenschalk Post: cool!! 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 BM
32) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112470) Posted 24 Apr 2013 by Bernd Machenschalk Post: This is just to let you know that we are working on it. It definitely is more difficult than I first thought. It might help if someone of you having this problem could send us (or post here, stripped of any personal info you like) the init_data.xml files from the two slots of the tasks that end up running on the same device. BM I'll set up a run and send you the files (email OK?) when this GPUGrid task vacates its GPU - ~2.5 hours. Email is ok. But it will probably be enough to post the <gpu...> tags of the two files here (<gpu_type> <gpu_device_num> <gpu_opencl_dev_index> and whatever I might have missed). BM
33) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112463) Posted 24 Apr 2013 by Bernd Machenschalk Post: This is just to let you know that we are working on it. It definitely is more difficult than I first thought. It might help if someone of you having this problem could send us (or post here, stripped of any personal info you like) the init_data.xml files from the two slots of the tasks that end up running on the same device. BM
34) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112462) Posted 24 Apr 2013 by Bernd Machenschalk Post: computer details don't say anything about NEON It is not visible in "Computer Details", but when you click on the "last contact" date of your device, in the scheduler log you see: [send] CPU features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 So it's correctly detected by the Client and communicated to the Server. BM
35) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112435) Posted 22 Apr 2013 by Bernd Machenschalk Post: The current Android App version on Albert is experimental to an extent that we are not even announcing it yet for public testing. It is primarily meant to support the development of the "official" BOINC Client for Android. If that application version works with NativeBOINC, fine then, but we currently neither recommend nor support it. If you attach to Albert@Home with the latest version of NativeBOINC, you probably get v1.02 of the Android App for "BRP4U (single DM)" (as in the thread title). I would suspect this version to be rather slow (possibly even slower than the 1.01 version), especially compared to the v1.03 NEON version that's also there (but only runs on devices that support NEON). But this would probably need to be installed manually in NativeBOINC, and I have no clue on how to do that, and you will need to do that manually again and again for every new version that we publish. BM
36) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112431) Posted 19 Apr 2013 by Bernd Machenschalk Post: Thanks, that's helpful. That's as far as I could track it down, Oliver or HB should be able to pick that up after the weekend. BM
37) Message boards : Problems and Bug Reports : FGRP application v 1.05 (OPENCL) feedback thread (Message 112429) Posted 19 Apr 2013 by Bernd Machenschalk Post: I'm experiencing a some very strange bug. I've two video cards and they are working very well in Einstein@Home project. However when I try to run FGPR Opencl WUs on them I can see very strange behavior - two WU's are running on the second card simultaneously and nothing is happening on the first card. Nevertheless boinc manage shows that WUs are being processed each one on the separate cards. BOINC are having problems with their code (server, client, API - not sure which is most relevant) in that area - identifying which card is which 'device' in OpenCL terminology. Oliver might want to look at that report in connection with the current BOINC developer discussions (mainly being initiated by Charle Fenton). This is either a problem in the client or a problem communicating the device to run on from the client to the application. AFAIK we're using the exact same code in the FGRP App than in the OpenCL BRP App, and I know of no such error being reported with the latter. My guess is that it's either a bug in the OpenCL implementation in the driver (in which case using a different driver version might help) or in the client (try a different version here, too). When two such tasks are running, could you take a look at the command lines? There should be a small integer number following a "--device" option. If this number is identical for the two tasks, then this is definitely a problem in the Client. If it is different, it may be a problem in the App code or the driver. BM
38) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112407) Posted 5 Apr 2013 by Bernd Machenschalk Post: A question if I may. When is it likely this Raspberry Pi app might make it to Einstein? I have been crunching them for a bit and have been returning what appears to be valid work units (that is they have validated). From looking at my completed tasks I seem to get paired up with a cell processor quite often, but rarely it seems another Pi. Maybe I am the only Pi user apart from HBE? There was mention over at Einstein of getting another months worth of Arecibo data. Will that effect the rollout plan? The main point is that not only the application code but also the workunits of "BRP4U" differ from the current "standard" BRP4 workunits on Albert and Einstein. For Albert we generated BRP4U WUs manually, but we don't have a workunit generator that would continuously produce BRP4U workunits and won't interfere with the current BRP4 workunit generation. The rough roadmap is: 1. rollout "BRP5" (Parks Perseus Arm Survey) (and possibly the OpenCL version of FGRP2) on Einstein, to feed the GPUs there 2. limit "BRP4" on Einstein to CPUs 3. switch the "bundled" BRP4 workunits on Einstein to "single-DM" WUs that we are running here at Albert as "BRP4U" Then we can and will publish the ARM application versions on Einstein, otherwise the tasks will take too long (more than a week on an overclocked Raspberry). I currently expect this process to take about two months. The additional data from Arecibo just means that we aren't under so much pressure for step 1. BM
39) Message boards : Problems and Bug Reports : BRP4U (Raspberry Pi , single DM tasks) feedback thread (Message 112393) Posted 23 Mar 2013 by Bernd Machenschalk Post: The current ARM App won't run on Android, an Android App is being worked on an should be available after Easter. BM
40) Message boards : Problems and Bug Reports : Wrong Wu's being sent once again ... (Message 112387) Posted 22 Mar 2013 by Bernd Machenschalk Post: The application selection is a pretty difficult thing to get right, especially in what we call "mixed scheduling" - using two different schedulers for two different types of work, each of which was written with the idea of being the only one on the project (Two popes meeting ...). Indeed this does work on Einstein probably even worse than here on Albert. O certainly need to take another look at this when I find the time (currently sick@home). On Albert I hope to test a new version of the server code hopefully next week, I sure hope that things get better then. I'll try to allocate some time to look into this on Einstein, too, but currently can't promise anything. Thank you for your patience. BM

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