Re: [boinc_dev] Parallella
Hi Von meinem iPad gesendet Am 15.03.2014 um 11:27 schrieb TarotApprentice tarotapprent...@yahoo.com: I am sure HBE would have run BOINC on the Parallella Still waiting for my board. I am a last minute backer for parallella Kickstarter campaign, so my board will be in the last batch :-(. Cheers HB ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Boinc on Parallella
Hi! Parallella uses an ARM 9 chip and the Raspberry Pi uses an ARM 7. Is ARM 9 just newer and backward compatible with ARM 7 , or is it a totally different instruction set? The reason I ask is that the Raspberry Pi apps use armhf (depending upon the distro I think) so would those apps work or is a new version required? The ARM nomenclature is a bit confusing. Actually Raspberry Pi uses an ARM 11 (!) type core which belongs to the ARMv6 architecture/instruction set. Parallella uses ARM Cortex-A9 cores, which belong to the ARMv7 architecture/instruction set ARMv7 is backwards compatibel to ARMv6 . Before we at Einstein@Home made a dedicated ARMv7 Linux versions, users were happily running the RasPi ARMv6 version on their ARMv7 Linux boards. David wrote: The question is whether represent it as an existing platform with a new type of coprocessor, or as a new platform. I suggest the latter. I suggest the former (coprocessor) Reasons: - Parallella is planned to come in several flavors with Epiphany chips having 16 cores (initial (current) version), 64 cores (maybe next year?), or even 1024 cores eventually. To me this will more naturally map to a scenario where the Epiphany is modelled as a coprocessor. - Even more so in the future: Future versions might come with newer ARM cores as well (say eventually ARMv8 , the 64 bit instruction set). If you model the Epiphany as a coprocessor, you can deal with all the combinations of ARM-cores and Epiphany chips in an orthogonal way (CPU and coprocessor types separately), if you model it as a platform you have to map the matrix of possible combinations to one type I guess. - The ARM on the Parallela is a dual-core, so in theory you can execute two BOINC tasks in parallel (BOINC will be running on the ARM cores, not the epiphany cores). So you have to solve the same scheduling problem as with GPUs, where some tasks might need the full Epiphany chip (the default scenario I guess) but you can still run another task on the other ARM core, e.g. a task from a project that does not support the Ephiphany coprocessor if you model it that way. Cheer HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Jon Sonntag j...@thesonntags.com To: Stephen Maclagan stephen.macla...@hotmail.com, Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu Date: 03/14/2014 05:09 AM Subject:Re: [boinc_dev] Boinc on Parallella Sent by:boinc_dev boinc_dev-boun...@ssl.berkeley.edu Parallella uses an ARM 9 chip and the Raspberry Pi uses an ARM 7. Is ARM 9 just newer and backward compatible with ARM 7 , or is it a totally different instruction set? The reason I ask is that the Raspberry Pi apps use armhf (depending upon the distro I think) so would those apps work or is a new version required? Jon Sonntag On Thu, Mar 13, 2014 at 4:35 PM, Stephen Maclagan stephen.macla...@hotmail.com wrote: The first Boinc user to get Boinc running on a Parallella has happened: http://forums.parallella.org/viewtopic.php?f=22t=1026 Since the Boinc version that apt-get gives is only Boinc 7.2.7, i've asked Gianfranco Costamagna to see if he can get his following packages fixed so they'll build for armhf: https://launchpad.net/~costamagnagianfranco/+archive/boinc https://launchpad.net/~costamagnagianfranco/+archive/firefox Then at least Parallella Boinc users can get an up to date version, and any changesets can be pushed to them reasonably quickly. (Unless the Saucy Salamander Boinc 7.2.7 can be updated to 7.2.42) Claggy ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...
Hi! The question, however, is this: is BOINC as smart as a 4th grader - can it avoid falsely claiming that work units won't finish on time, thus misleading users into aborting work units that appear to have absolutely no chance of making their deadline? Maybe the real problem is that the info BOINC manager displays as an estimate has no measure of confidence or uncertainty attached (it lacks error bars, if you want). If an estimate is just it will take 100 hrs, 10 min, 5 sec , updated every second, the user reaction will (understandably) be different compared to something like (say) 100 hrs (+/- 80 hrs). No matter what scheme is used for the estimation, there will always be some uncertainty and while I'm not familiar with the BOINC code on the projected runtime, if things like the standard deviation of runtime per task is kept (I think this was mentioned), plus some [new] project supplied measure of uncertainty of the flops estimate for a workunit, it might be possible to give a better (more useful, less misleading) estimate by including an uncertainty. Just my 2 cents. Cheers HBE - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: William bcdecbi...@yahoo.com To: Jon Sonntag j...@thesonntags.com, elliott...@verizon.net elliott...@verizon.net, Cc: BOINC Developers Mailing List @berkeley.edu boinc_dev@ssl.berkeley.edu Date: 02/13/2014 12:53 AM Subject:Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... Sent by:boinc_dev boinc_dev-boun...@ssl.berkeley.edu The question, however, is this: is BOINC as smart as a 4th grader - can it avoid falsely claiming that work units won't finish on time, thus misleading users into aborting work units that appear to have absolutely no chance of making their deadline? Signs point to NO. ~ Rightful liberty is unobstructed action according to our will within limits drawn around us by the equal rights of others. I do not add 'within the limits of the law' because law is often but the tyrant's will, and always so when it violates the rights of the individual. - Thomas Jefferson On Wednesday, February 12, 2014 5:28 PM, Jon Sonntag j...@thesonntags.com wrote: If after 5 minutes, a workunit is 10% done and after 10 minutes it is 20% done, I don't need a domain expert. A 4th grade student should be able to calculate that it will take a total of 50 minutes to complete and that 40 minutes remain. Jon Sonntag P.S. I went to a tax professional once. They charged a lot and they got it wrong. The IRS corrected it and sent me a refund. On Tue, Feb 11, 2014 at 6:18 AM, Charles Elliott elliott...@verizon.netwrote: Although I am a CS grad student, I urge you to reconsider choosing CS grad students to work on this problem and consider instead using domain experts in statistics and/or Operations Research or Systems, or perhaps even an interdisciplinary team. Old research shows that it is much more cost-effective to hire domain experts and teach them to program computers than it is to hire CS grads and try to teach them the domain. Suppose your income tax preparation was a complex process. Which would you want do it: a CS grad who wrote the fastest program possible, or a tax law expert who could save you months of work on an IRS tax audit and keep you out of jail? Charles Elliott -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David Anderson Sent: Monday, February 10, 2014 10:58 PM To: boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... In general we've put statistics-gathering into server rather than client because - it gives uniform data over the entire host population - it puts the data all in one place Currently these statistics are just the bare essentials: mean and standard deviation of elapsed time, turnaround time, and credit-related quantities. We maintain these per (host, app version) and per app version. We use them to estimate job duration and to compute credit. As you point out, there are many other types of info we could track, and many visualizations that could offered. This is an area were having a few CS grad students working on BOINC would be a big help. -- David On 10-Feb-2014 4:01 PM, Max Power wrote: Many types of distributed computing applications don't due uniform processing (and reporting on percent done) like SETI, Astropulse or Einstein ... and the biological science applications (and image rendering ones) have taken some time to discipline the reporting of percent done. What the BOINC Client does not do is use the hashsums of computing applications (as sometimes they run in pairs as in Climate Prediction) to form
Re: [boinc_dev] RFE: restart automatically all uploads of a project if one upload job was successfully retried
Hi IMO all other upload job of the same project should be retried too automatically instead manually kick every job. I would not mind if the uploads are done with some delay in between in the situation you described. Imagine a situation when a bigger project can't accept uploads for some time (say up to several days) for whatever reason (maintenance, HW failure, ). In the meantime hosts can accumulate 100s of completed results, and while BOINC will only try to upload so many files simultaneously, thousands of hosts trying to upload 100s of results in a very short timespan after the upload server comes online again can overwhelm the server. Cheers HB Von meinem iPad gesendet Am 29.01.2014 um 22:05 schrieb Toralf Förster toralf.foers...@gmx.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Today I had have 4 hanging upload jobs for WCG. After I while I restarted one of the four successfully. IMO all other upload job of the same project should be retried too automatically instead manually kick every job. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLpbQMACgkQxOrN3gB26U4UFwD8D0IaRR9LPwpomwI/nPrbMLbP scDdWLY0BQafzNkIk7YBAIrcbBVJTTyGHjNjE73SrP+SbP0paE6U9AvqBQ/9mTrP =cL/j -END PGP SIGNATURE- ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Build problem (ignoring missing jpeglib.h)
Hi! There seems to be a problem in checking the pre-requisites for compiling the graphics related parts of the BOINC API: if libGLUT and friends **ARE** installed, but jpeglib.h is missing, the configure script will output a warning saying continue building the non-graphical parts of the BOINC API, but in fact it will still try to build boinc/api/gutil.cpp , which must fail w/o jpeglib.h. The problem and a suggested fix are illustrated by the attached patch Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) 0001-Bug-fix-Do-not-try-to-compile-graphics-part-of-API-i.patch Description: Binary data ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] android: account manager support
Hi Joachim! I like the blue background design, loos very intuitive to me! I have never worked with BOINC account managers tho, I'll need to learn more about it before I can really test this. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Joachim Fritzsch joachim.fritz...@gmail.com To: Keith J Uplinger upl...@us.ibm.com, Kevin Reed knr...@us.ibm.com, Heinz-Bernd Eggenstein heinz-bernd.eggenst...@aei.mpg.de, David Anderson (UCBerkeley) da...@ssl.berkeley.edu, Rom Walton r...@romwnet.org, Carl Christensen carl...@yahoo.com, Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu, eah_andr...@aei.mpg.de eah_andr...@aei.mpg.de Date: 09/11/2013 08:01 PM Subject:android: account manager support I have committed code changes to support account managers in the Android GUI. There are a few screenshots in my dropbox https://www.dropbox.com/sh/i1ebp0xffoujx3m/H_jKaIQwNa - complete blue background indicates: account manager - blue background of project icon indicates that this project gets managed by the manager (and can therefore not be removed manually, see 31) - attaching account manager via additional button on bottom of project list (21), only shown if not already attached (22) Tested so far with GridRepublic and BAM!. Feedback welcome. Joachim ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] android -- boinc not storing cpu features (/proc/cpuinfo features)
Hi Carl Hi, I may be late to this party, but am I right in thinking boinc isn't parsing out the cpu features on Android? for example my phone supports vfp, vfpv3, and neon, but on my Einstein@home record it says No coprocessor No coprocessor here means that no GPU is detected. The Android BOINC client is checking the presence of CPU features and forwarding those in scheduler requests, e.g. we at E@H use this information to distinguish devices w/ and w/o NEON (even tho we don't show the CPU features in the web interface). Cheers HB Von meinem iPad gesendet ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] : BOINC (windows) doesn't report avx processor feature
Hi We are in the process of updating our Windows toolchain to a more recent version of Visual Studio. It isn't enough to just check if the instruction set is present, we also need to check whether the OS is saving and restoring the registers as well. Just curious, what are the plans for Linux and OSX (as you mentioned Windows specifically). Will the BOINC client also check for OS support of AVX before reporting this CPU feature? Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Rom Walton r...@romwnet.org To: Kosuke Kaizuka cai.0...@gmail.com, boinc_dev@ssl.berkeley.edu, Date: 08/16/2013 07:47 AM Subject:Re: [boinc_dev] : BOINC (windows) doesn't report avx processor feature Sent by:boinc_dev boinc_dev-boun...@ssl.berkeley.edu We are in the process of updating our Windows toolchain to a more recent version of Visual Studio. It isn't enough to just check if the instruction set is present, we also need to check whether the OS is saving and restoring the registers as well. That required a more recent assembler than what we are currently using. Once we have the updated toolchain we will finish up with the rest of the detection and get it ported over to the 7.2 branch. - Rom -Original Message- From: Kosuke Kaizuka [mailto:cai.0...@gmail.com] Sent: Friday, August 16, 2013 12:27 AM To: Rom Walton; boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] : BOINC (windows) doesn't report avx processor feature BOINC 7.2.10/7.2.11 does not detect AVX feature with Core i7-2600 Win7 Professional x64 SP1... 2013/08/16 13:06:30 | | No config file found - using defaults 2013/08/16 13:06:30 | | Starting BOINC client version 7.2.11 for windows_x86_64 2013/08/16 13:06:30 | | log flags: file_xfer, sched_ops, task 2013/08/16 13:06:30 | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6 2013/08/16 13:06:30 | | Data directory: D:\BOINC 2013/08/16 13:06:30 | | Running under account Kosuke 2013/08/16 13:06:30 | | Processor: 8 GenuineIntel Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz [Family 6 Model 42 Stepping 7] 2013/08/16 13:06:30 | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx smx tm2 pbe 2013/08/16 13:06:30 | | OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, (06.01.7601.00) 2013/08/16 13:06:30 | | Memory: 15.98 GB physical, 15.98 GB virtual 2013/08/16 13:06:30 | | Disk: 886.28 GB total, 560.33 GB free 2013/08/16 13:06:30 | | Local time is UTC +9 hours 2013/08/16 13:06:30 | | VirtualBox version: 4.2.16 2013/08/16 13:06:30 | | CAL: ATI GPU 0: AMD Radeon HD 7850/7870 series (Pitcairn) (CAL version 1.4.1848, 2048MB, 2008MB available, 6400 GFLOPS peak) 2013/08/16 13:06:30 | | OpenCL: AMD/ATI GPU 0: AMD Radeon HD 7850/7870 series (Pitcairn) (driver version 1272.2 (VM), device version OpenCL 1.2 AMD-APP (1272.2), 2048MB, 2008MB available, 6400 GFLOPS peak) -- Kosuke Kaizuka cai.0...@gmail.com ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] ARM questions
Hi! There are two floating point ABIs for arm-linux corresponding to the calling conventions used for passing floating point parameters (memory vs registers, I presume). ..and Floating point registers vs passing floats in integer registers ( split in two for doubles...gr). A really good overview on Linux ARM ABI QA can be found at Debian, most of it should be valid in general for other Linuxes: http://wiki.debian.org/ArmHardFloatPort#Background_information Here's where I start to get confused. Tell me if I've got this right. Let's see :-) The gcc default is to use the soft float ABI, GCC will use the best default for the platform it was compiled for. E.g. on Debian armhf Linux port, it will use hard float by default. More on this later. The gcc default is to use the soft float ABI, which results in the generation of calls to implement emulations of floating point path. See the section ld.so hwcaps on the Debian page linked above. Even with soft ABI, there will be a benefit for devices actually having VFP hardware, it's not like soft-ABI implies software emulation. Still the overhead is considerable (a function call, some register shuffling, for each FP op) If one specifies -mfloat-abi=softfp the compiler generates hardware floating point instructions but uses the softfp call convention. Correct. The hard float is chosen by -mfloat-abi=hard. For this a VFP is required, but it is the most efficient mode. Correct. FFTW 3.3.3, for some reason, thinks this mode is incompatible with NEON SIMD code, though. I would consider this a bug, but I kind of doubt this is a problem. Here is a report of someone claiming to have used FFTW 3.3.3 with hardfloat ABI and NEON support enabled: https://bitbucket.org/jpommier/pffft (search the page for --enable-neon ) So if I wanted to target the widest variety of devices. I'd make one executable with the default (software) FP. I'd make one with softfp including NEON code in FFTW. And I'd make one for hardfp without NEON code in FFTW. The important point is that you are NOT free to decide which ABI (hard or soft(fp)) you want to use for a given target system. The target OS is either having libraries that are expecting getting values passed the hard or the soft way. If the target system is soft-ABI, you are free to choose soft or softfp code, tho. I hope there's something in the BOINC headers or host record that would tell me which one to send. The way to communicate the ABI of the host OS is the platform string. Presence of certain hardware and instruction set features for ARM CPUs are found in the CPU capabilities, but note that detailed support e.g. for detecting NEON or VFP were added only recently to BOINC. Some legacy BOINC installaions on ARM (e.g. BOINC from the official distribution repos) will not give you this information. Android throws in another twist in that pre-ARMv7 devices can only use software floating point. Android has two ABIs defined, pre ARMv7 and Armv7, but **both** are of the soft-floating point variant (!). In general, hardfloat code will not run correctly on Android devices. See the document docs/CPU-ARCH-ABIS.html of the Android NDK. Here's the crucial quote: = I.2. 'armeabi-v7a' [...] IMPORTANT NOTE: This ABI enforces that all double values are passed during function calls in 'core' register pairs, instead of dedicated FP ones. However, all internal computations can be performed with the FP registers and will be greatly sped up. This little constraint, while resulting in a slight decrease of performance, ensures binary compatibility with all existing 'armeabi' binaries. which essentially says that even this ABI is a soft float ABI (!!). You can check the commandline option that NDK will use for gcc: even for the ARMv7 ABI it will be -mfloat-abi=softfp It's not clear from the documents whether all androidabi-v7a devices are required to have a VFP I understand the section in the quoted document above to mean that VFP is mandatory for the armeabi-v7a ABI, and NEON is optional. But yeah, the wording could be more precise. and whether their GCC port defaults to hardfp generation. See above. GCC may technically allow to set the hardfloat ABI on the commandline in the NDK build of gcc, but all the runtime libs in the NDK are soft float ABI. So no hardfloat ABI support in the NDK and Android versions targeted by the official NDK!!! It's almost getting back to the early days of SUN when every workstation had a different FPU. Indeed, the ARM-world is very modular and full of variants, and it's not just floating point : e.g. one other CPU feature that needs to be treated with care is the Thumb instruction set which can be used to minimise code size, but is not supported by all devices. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse
[boinc_dev] RAM requirent depending on plan class
Dear all, I'd like to hear comments on the following problem/idea: For Android on ARM, we at E@H have optimised our science app to require less RAM than our regular CPU app versions for x86 CPUs. OTOH, we would like to have only one application (in the BOINC terminology) for all CPU platforms, so only one suite of work generators, validators etc is needed and x86 and ARM app versions get the same tasks and can even cross-validate against each other, which we think is good. But as the memory requirements are associated to the work unit, we have to use the maximum value for all the different app versions/ plan classes. IMHO the situation is somewhat similar to the execution speed differences for different plan classes that cannot be fully modelled by the BOINC benchmark results (e.g. for CPU-GPU comparison) and I understand that the solution for this was a scaling factor that can be configured with plan classes to let the scheduler know that results are computed faster by a certain factor for a particular plan class compared to what BOINC would assume otherwise. Would it be feasible/a good idea to also have a configurable scaling factor for RAM requirements, perhaps ?? I think many projects will find that optimising for RAM size is important for Android. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] RAM requirement depending on plan class
Hi! But I think you've chosen a poor example with the CPU-GPU speed relationship Agreed, and I hope I didn't open a can of worms here because getting the RAM requirement handled better was my main concern :-) , e.g. we have a factor of about 2 between the required RAM for x86 CPUs and ARM CPUs for one application. While the speed up factor for tweaking the runtime estimates especially for GPUs might not be ideal, it seems to work kind of reasonably well at least for our project, E@H. But that's a different issue. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Richard Haselgrove r.haselgr...@btopenworld.com To: Heinz-Bernd Eggenstein heinz-bernd.eggenst...@aei.mpg.de, BOINC Developers Mailing List boinc_dev@ssl.berkeley.edu, Date: 07/23/2013 04:01 PM Subject:Re: [boinc_dev] RAM requirent depending on plan class I think we need to be careful about the scoping validity of data, and we haven't always been in the past. In this particular case, I think that it's a reasonable assumption that the RAM requirements of an application (again in the BOINC terminology) on one platform have a deterministic relationship with the RAM requirements on other platforms. All of that is knowable by the project team, and suitable for implementation on the server. But I think you've chosen a poor example with the CPU-GPU speed relationship. There is no necessary or deterministic relationship between the speed of a GPU, and the speed of the CPU of the host it's mounted in (and to confuse matters further, there's no necessary relationship between the speeds of two different GPUs in the same host). The current code assumes (as a starting point) that a generic GPU is 10x the speed of the associated CPU: I suspect that this assumption - along with a sub-optimal choice of plan_class by the server - is the underlying cause of a recent report of 'EXIT_TIME_LIMIT_EXCEEDED' errors at SETI Beta. http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2008 From: Heinz-Bernd Eggenstein heinz-bernd.eggenst...@aei.mpg.de To: BOINC Developers Mailing List boinc_dev@ssl.berkeley.edu Sent: Tuesday, 23 July 2013, 12:54 Subject: [boinc_dev] RAM requirent depending on plan class Dear all, I'd like to hear comments on the following problem/idea: For Android on ARM, we at E@H have optimised our science app to require less RAM than our regular CPU app versions for x86 CPUs. OTOH, we would like to have only one application (in the BOINC terminology) for all CPU platforms, so only one suite of work generators, validators etc is needed and x86 and ARM app versions get the same tasks and can even cross-validate against each other, which we think is good. But as the memory requirements are associated to the work unit, we have to use the maximum value for all the different app versions/ plan classes. IMHO the situation is somewhat similar to the execution speed differences for different plan classes that cannot be fully modelled by the BOINC benchmark results (e.g. for CPU-GPU comparison) and I understand that the solution for this was a scaling factor that can be configured with plan classes to let the scheduler know that results are computed faster by a certain factor for a particular plan class compared to what BOINC would assume otherwise. Would it be feasible/a good idea to also have a configurable scaling factor for RAM requirements, perhaps ?? I think many projects will find that optimising for RAM size is important for Android. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Android (was ARM questions)
One more thing: Am 23.07.2013 um 23:04 schrieb Eric J Korpela korp...@ssl.berkeley.edu: And if you're sending to android on ARMv6 with VFP or NEON, it seems to me that you are doing something that the NDK says is not supported by either ABI. I just found this on the Google Playstore: an app (or rather library I guess) that is specifically written for ARMv6+VFP to make use of hardware fp instructions, and it seems to work fine: https://play.google.com/store/apps/details?id=roman10.media.converter.v6vfp Cheers HB ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] : BOINC (windows) doesn't report avx processor feature
Hi Von meinem iPad gesendet Am 23.07.2013 um 00:18 schrieb Juha juha.sointus...@gmail.com: I'm not quite sure I understand what that article was about. Anyway, since 7 RTM, Vista and earlier Windowses don't handle the new processor registers AVX brought, I would expect that AVX science applications won't work properly on those operating system versions. That is, the science application will produce sooner or later garbage results. If that is the case then either BOINC shouldn't report AVX support on those OS versions or the scheduler should check for processor features + OS version. BOINC (or the scheduler) would have to make this decision also for Linux and MacOS, and then there is AVX2 available now... Project developers might want to look into an alternative, which would also work for legacy BOINC clients: letting the science app handle instruction set optimized code paths at runtime, I think the Intel compilers and intel libraries like IPP can do this quite well, e.g see here http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-intel-ipp-understanding-cpu-optimized-code-used-in-intel-ipp Cheers HB -Juha On 23 July 2013 00:41, Wolfgang Schwieger wolfg...@schwieger.de wrote: As you can see here http://msdn.microsoft.com/en-us/library/windows/desktop/ff919571(v=vs.85).aspx this is no problem for BOINC. ** ** When a new windows version of BOINC is available (with reporting of AVX) i will test it with WinXP/WinXP-64bit, and if it is reporting AVX…..i will test it with the PrimeGrid app ;-) ** ** --Wolfgang ** ** *Von:* Juha [mailto:juha.sointus...@gmail.com] *Gesendet:* Montag, 22. Juli 2013 23:18 *An:* Rom Walton *Cc:* Wolfgang Schwieger; BOINC Developers Mailing List *Betreff:* Re: [boinc_dev] : BOINC (windows) doesn't report avx processor feature ** ** AVX needs support from operating system and according to Wikipedia the first Windows to support AVX is 7 SP1. Should the client report all the features that could be available and leave it to the scheduler to decide what is safe to use or should the client report only those features that the entire system supports? (SSEn needs OS support as well, but since that was added in Win 95 or 98 maybe we can safely assume the support is always available.) -Juha ** ** On 22 July 2013 20:09, Rom Walton r...@romwnet.org wrote: Done. Revision: 9b2d0f992f6669d31d1996c4fc105ce22324445b Author: Rom Walton Date: 7/22/2013 1:08:36 PM Message: client: Add detection of the AVX instruction set for newer processors Modified: client/hostinfo_win.cpp - Rom -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Wolfgang Schwieger Sent: Monday, July 22, 2013 1:02 PM To: 'BOINC Developers Mailing List' Subject: [boinc_dev] : BOINC (windows) doesn't report avx processor feature Hi all, BOINC (windows) reports these processor features for a sandy bridge CPU (2600k): Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe But there is no avx entry, so PrimeGrid cannot deliver the new GeneferAVX application to windows hosts. Can you please add this line to hostinfo_win.cpp (e.g. line 1075)? FEATURE_TEST(std_supported, (std_ecx (1 28)), avx ); Regards Wolfgang Schwieger ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ** ** ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Project list icon for Intel GPU support?
Hi! I like the idea to get an indication (e.g. highlighting of projects in the list) whether or not a given project will run on the device used to attach, but OTOH volunteers typically have more than one BOINC capable device. E.g. I'd like to see a little Android logo displayed for projects that support those clients, even if that project has no work for the PC that is used to browse the list so, volunteers see what might be possible on other devices he/she owns. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Jon Sonntag j...@thesonntags.com To: David Anderson da...@ssl.berkeley.edu, Cc: BOINC Developers Mailing List @berkeley.edu boinc_dev@ssl.berkeley.edu Date: 07/19/2013 02:13 AM Subject:Re: [boinc_dev] Project list icon for Intel GPU support? Sent by:boinc_dev boinc_dev-boun...@ssl.berkeley.edu That would be simpler than adding every type of coprocessor or platform as the list continues to grow. Would it also take into account the no alt platform setting so that if a 64-bit user wants only 64-bit apps and the project doesn't have them that it wouldn't show that it has apps that will run on this client? Would the project list be filtered so that the projects that won't run at all on the client (e.g. WEP if running Windows) wouldn't even be listed if neither the CPU or GPU apps were compatible? Or maybe have that as an option in the preferences. In other words, don't taunt people by showing projects they can't use. That, or add a warning when they try and connect that says [in a bad French accent] Now go away or I shall have to taunt you a second time! ;-) Jon Sonntag On Thu, Jul 18, 2013 at 6:57 PM, David Anderson da...@ssl.berkeley.eduwrote: I'd also like to change things so that the add-project dialog shows: 1) whether this project has apps that will run on this client 2) whether this project has apps that will use this client's GPU(s) ... rather than listing all the platforms and GPUs that the project supports. -- David On 18-Jul-2013 6:55 AM, Heinz-Bernd Eggenstein wrote: Dear all, In the projects list displayed when choosing a project to attach to, would it be possible to have an icon displayed for project supports Intel-GPUs (like the ones for ATI/AMD and NVIDIA GPU support in /clientgui/res/templates ) ? (I'm not sure how much of a hassle one has to go thru for this , e.g. ask Intel for permission to use a shrinked logo) THX, Cheers HB --**--**- Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) __**_ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. __**_ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Project list icon for Intel GPU support?
Dear all, In the projects list displayed when choosing a project to attach to, would it be possible to have an icon displayed for project supports Intel-GPUs (like the ones for ATI/AMD and NVIDIA GPU support in /clientgui/res/templates ) ? (I'm not sure how much of a hassle one has to go thru for this , e.g. ask Intel for permission to use a shrinked logo) THX, Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] CPU throttling and GPU apps
Hi all! While hunting for a bug recently, we at Einstein@Home came across a question that I would like to present for discussion here: If an app has a non zero GPU share (GPU app for short), should CPU throttling (as configured thru the preferences setting Use at most x % of CPU time) be applied to it? I guess there are several pros and cons, e.g.: cons: - one one hand, GPU apps (depending on the CPU share?) get a higher OS prio (in terms of niceness) to prevent the GPU being starved. Throttling the CPU might very well cause this starvation - if a GPU app has a rather low CPU runtime share in the first place, further CPU throttling does not seem too useful. - in order to avoid GPU load to interfere with the user doing non-BOINC related stuff, there is already the setting Suspend GPU work while computer is in use. pros: I can't think about many, maybe consistency and user expectation? Volunteer reports at E@H seem to suggest that in the current BOINC client version, GPU apps are indeed CPU throttled, right? Browsing thru the source code, my initial impression is that only NCI (non-CPU-intensive) apps are excluded from throttling. Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Boinc Client Platform String for ARM devices
Hi As you mentioned the Raspberry Pi: BOINC is available in the repo of Raspian, a Debian wheezy fork, and it uses the platform string 'arm-unknown-linux-gnueabihf'. It does make sense IMHO to differentiate in the platform string between hard float (as with Raspbian) and soft float ABI platforms for the ARM CPU (e.g. the native Debian wheezy for ARMv6 CPUs), because they are not binary compatible. The project has to know what kind of executable it can send to the client, and the natural way to do so is via the platform string. Cheers HB Von meinem iPad gesendet Am 03.07.2013 um 21:10 schrieb yoyo y...@mailueberfall.de: Hello, are there some rules which platform string a Boinc client on a ARM device (not Android) should sent? Here http://boinc.berkeley.edu/trac/wiki/BoincPlatforms only Android is mentioned. But what about RasPi, Odroid or my NAS server which runs: # uname -a Linux nas02 2.6.33.2 #1 Fri Apr 26 05:33:12 CST 2013 armv5tel unknown # cat /proc/cpuinfo Processor name : Feroceon 88F6282 rev 1 (v5l) @ 2 GHz BogoMIPS: 1985.74 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: Feroceon-KW ARM Revision: Serial : I know these platform strings, but which ones are prefered?: - arm-linux-gnu - arm-unknown-linux-gnueabi - arm-unknown-linux-gnueabihf What does other projects use? kind regards, yoyo ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Can we do shared memory with no disk usage?
Hi all, Interesting. I guess it would be useful to run BOINC on a dedicated partition (e.g. ext hard disk/ USB stick) to isolate BOINC's contribution to the stats. How often is the client_state.xml file updated? It can grow to enormous sizes if you have a huge number of waiting tasks or unreported finished tasks (stderr outputs !!). Cheers HB - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Steffen Möller steffen_moel...@gmx.de To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu, Date: 06/18/2013 09:03 AM Subject:Re: [boinc_dev] Can we do shared memory with no disk usage? Sent by:boinc_dev boinc_dev-boun...@ssl.berkeley.edu Gesendet: Montag, 17. Juni 2013 um 21:29 Uhr Von: David Anderson da...@ssl.berkeley.edu An: boinc_dev@ssl.berkeley.edu Betreff: Re: [boinc_dev] Can we do shared memory with no disk usage? In situations were BOINC is causing unexpectedly large ( 1 GB/hour) disk I/O, we need to figure out the source of the I/O. -- David My little centrino laptop had SETI (official client) run over night. $ iostat -h -m Linux 3.8-1-rt-amd64 (Toshiba) 06/18/2013 _x86_64_(2 CPU) ... Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 33.80 0.17 0.39 3040 6859 $ date Tue Jun 18 00:30:06 CEST 2013 $ iostat -h -m ... Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 65.32 0.07 0.98 3387 45737 $ date Tue Jun 18 08:36:50 CEST 2013 Looking only at the last column, in those 8 hours this were (45737-6859)/1024 [1] 37.9668 GB and consequently (45737-6859)/1024/8 [1] 4.74585 GB/h another machine, running about 10 clients in parallel (all Rosetta, one WCG), had a bit less of IO ... here iostat was run twice with 1h interim sleep twin1a:~ $ date ; iostat -m -h Mon Jun 17 23:34:12 CEST 2013 Linux 3.2.0-3-amd64 (twin1a)06/17/2013 _x86_64_(24 CPU) Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 3.08 0.02 0.30 29091 504228 $ sleep 3600 ; date ; iostat -m -h Tue Jun 18 00:34:26 CEST 2013 .. Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 3.09 0.02 0.30 29091 506276 So this is about 2 GB per hour written and nothing read And yet another machine, same hardware, mostly einstein with 1 Rosetta and 1 WCG twin1b:~ $ date; iostat -h -m ; sleep 3600 ; date ; iostat -h -m Mon Jun 17 23:58:16 CEST 2013 ... Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 1.67 0.00 0.12 758482377118 Tue Jun 18 00:58:16 CEST 2013 Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 1.67 0.00 0.12 758482379914 Which means another 2 GB per hour. The machines were not running anything else but BOINC, the laptop had firefox open in the background. No BOINC graphical clients run anywhere. iostat comes with the sysstat package, for anyone out there to try. The laptop only has 1G of mem, which may lead to some swapping and account for some of the IO. Still, to me it looks mostly like some process writing a lot of status information that is not read by anyone. The missing reads for the big machines I might want to explain by large IO buffers ... there certainly have been a couple of uploads that should have caused some read, otherwise. Cheers, Steffen ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC 7.0.64 weirdness?
Hi! FWIW, we get reports of this as well on Einstein@Home, this one is for BOINC 7.0.62: http://einstein.phys.uwm.edu/forum_thread.php?id=10134nowrap=true#124926 On the server side it appears to be a request for 0 seconds of CPU and 0 seconds of GPU work Confirmed. We see this in the scheduler log: 2013-06-03 10:46:02.4045 [PID=30856] Request: [USER#x] [HOST#6119565] [IP xxx.xxx.xxx.38] client 7.0.62 2013-06-03 10:46:02.4187 [PID=30856] [send] effective_ncpus 1 max_jobs_on_host_cpu 99 max_jobs_on_host 99 2013-06-03 10:46:02.4187 [PID=30856] [send] effective_ngpus 1 max_jobs_on_host_gpu 99 2013-06-03 10:46:02.4187 [PID=30856] [send] Not using matchmaker scheduling; Not using EDF sim 2013-06-03 10:46:02.4187 [PID=30856] [send] CPU: req 0.00 sec, 0.00 instances; est delay 0.00 2013-06-03 10:46:02.4187 [PID=30856] [send] CUDA: req 0.00 sec, 0.00 instances; est delay 0.00 2013-06-03 10:46:02.4187 [PID=30856] [send] work_req_seconds: 0.00 secs 2013-06-03 10:46:02.4187 [PID=30856] [send] available disk 23.89 GB, work_buf_min 0 2013-06-03 10:46:02.4187 [PID=30856] [send] active_frac 0.99 on_frac 0.44 DCF 1.226839 2013-06-03 10:46:02.4222 [PID=30856] Sending reply to [HOST#6119565]: 0 results, delay req 60.00 2013-06-03 10:46:02.4225 [PID=30856] Scheduler ran 0.024 seconds The polling interval seems to be once per minute. Cheers HBE - Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Eric J Korpela korp...@ssl.berkeley.edu To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu, Date: 06/03/2013 07:17 PM Subject:[boinc_dev] BOINC 7.0.64 weirdness? Sent by:boinc_dev boinc_dev-boun...@ssl.berkeley.edu Some BOINC v7 clients are getting into a weird state where they contact the server every few minutes to request no work. I haven't been able to reproduce it, but people have reported that it goes away when they select read config file, even if they don't have a config file. Here's a not very detailed log that someone sent me. On the server side it appears to be a request for 0 seconds of CPU and 0 seconds of GPU work (essentially the same as requesting an update when no work is required). 5/31/2013 10:30:23 AM | SETI@home | Starting task 23jn12ab.24163.21032.12.11.50_1 using setiathome_enhanced version 609 (cuda23) in slot 2 5/31/2013 10:30:25 AM | SETI@home | Started upload of 23oc12ac.25717.18472.12.11.50_0_0 5/31/2013 10:30:28 AM | SETI@home | Finished upload of 23oc12ac.25717.18472.12.11.50_0_0 5/31/2013 11:31:14 AM | SETI@home | Computation for task 23jn12ab.24163.21032.12.11.50_1 finished 5/31/2013 11:31:14 AM | SETI@home | Starting task 23oc12ac.25646.13973.15.12.45_0 using setiathome_v7 version 700 (cuda32) in slot 2 5/31/2013 11:31:18 AM | SETI@home | Started upload of 23jn12ab.24163.21032.12.11.50_1_0 5/31/2013 11:31:25 AM | SETI@home | Finished upload of 23jn12ab.24163.21032.12.11.50_1_0 5/31/2013 11:31:28 AM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 11:31:28 AM | SETI@home | Reporting 2 completed tasks 5/31/2013 11:31:28 AM | SETI@home | Not requesting tasks 5/31/2013 11:31:30 AM | SETI@home | Scheduler request completed 5/31/2013 11:33:26 AM | SETI@home | Computation for task 26mr10ab.24819.17826.5.11.138_0 finished 5/31/2013 11:33:26 AM | SETI@home | Starting task 23oc12ac.25646.13973.15.12.40_0 using setiathome_v7 version 700 in slot 1 5/31/2013 11:33:29 AM | SETI@home | Started upload of 26mr10ab.24819.17826.5.11.138_0_0 5/31/2013 11:33:32 AM | SETI@home | Finished upload of 26mr10ab.24819.17826.5.11.138_0_0 5/31/2013 11:36:35 AM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 11:36:35 AM | SETI@home | Reporting 1 completed tasks 5/31/2013 11:36:35 AM | SETI@home | Not requesting tasks 5/31/2013 11:36:37 AM | SETI@home | Scheduler request completed 5/31/2013 1:28:09 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:28:09 PM | SETI@home | Not requesting tasks 5/31/2013 1:28:11 PM | SETI@home | Scheduler request completed 5/31/2013 1:33:15 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:33:15 PM | SETI@home | Not requesting tasks 5/31/2013 1:33:19 PM | SETI@home | Scheduler request completed 5/31/2013 1:38:23 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:38:23 PM | SETI@home | Not requesting tasks 5/31/2013 1:38:26 PM | SETI@home | Scheduler request completed 5/31/2013 1:43:30 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:43:30 PM | SETI@home | Not requesting tasks 5/31/2013 1:43:33 PM | SETI@home | Scheduler request completed 5/31/2013 1:48:37 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:48:37 PM | SETI@home | Not requesting tasks 5/31/2013 1:48:40 PM | SETI@home | Scheduler request
Re: [boinc_dev] XML parser may not null-terminate buffers (was: MD5 checksums - parsing errors on mal-formed tags)
Hi This is rather common in C code as it follows directly the (IMHO counterintuitive) definition of string handling functions like strncpy (mind the 'n' ), e.g. see man strncpy. It is the responsibility of the code calling strncpy to make sure the result is null terminated, if desired (usually it is). So for me, we are looking at a bug here. Cheers HB Von meinem iPad gesendet Am 29.03.2013 um 16:30 schrieb Nicolás Alvarez nicolas.alva...@gmail.com: 2013/3/29, Richard Haselgrove r.haselgr...@btopenworld.com: The sched_reply_climateprediction.net.xml files appear to be XML compliant, but not to conform to BOINC's restricted sub-set of XML. Two tags (that I've identified so far) are broken over two lines - nbytes and md5_cksum: both these tags have additional single LineFeed (0x0A) characters after the data and before the closing tag. The version of md5_cksum written into client_state.xml by - in my case - BOINC v7.0.59, 32-bit version, under Windows 7, consists of 40 characters: the (correct) original 32-character MD5 copied from sched_reply, plus 8 additional characters of - it appears - classic buffer overflow characters. Needless to say, the 40 character (MD5+buffer) fails to match the 32 character MD5 calculated by the BOINC client for the file: the downloaded file is rejected, and the MD5 mis-match is recorded in the event log. Bug: The BOINC XML parser returns successfully and doesn't null-terminate buffers if the element contains more data than the buffer would fit. Here is what happens in a normal situation, where md5_cksum contains exactly 32 characters: - The FILE_INFO parser calls parse_str(md5_cksum), passing it a 33-byte buffer. - parse_str verifies that md5_cksum is indeed the tag name of the last parsed tag, and calls get_aux(buf,33) to get the text after the element. - get_aux reads the first character, since it's not a '', it calls copy_until_tag to do the rest. (It also puts the first character in the buffer and adjusts the copy_until_tag args accordingly, but for simplicity we can pretend that get_aux ungetc()s the character instead; the effect would be the same) - copy_until_tag reads characters one by one, placing them in the buffer as long as they aren't '', and checking that there's still space in the buffer. - After reading the last (32nd) character of the MD5 hash, len is 1. - It reads one more character and it's a '', which indicates the text content finished. It unreads the '', puts a null-terminator in the buffer, and returns. - parse_str then verifies that the text is followed by a /md5_cksum closing tag, and terminates happily. The buffer now has the 32 characters that were inside the XML element, followed by a null terminator. Now, here's what happens if we have 33 characters in md5_cksum, starting from copy_until_tag: - copy_until_tag reads characters one by one, placing them in the buffer as long as they aren't '', and checking that there's still space in the buffer. - After reading the last (32nd) character of the MD5 hash, len is 1. - It reads one more character and it's not a '' (in this case it's a newline). It subtracts 1 from 'len', and it becomes 0, which indicates there's more data than the buffer can hold. - It returns XML_PARSE_OVERFLOW, without modifying the last position of the buffer at all. It probably contains some garbage. - get_aux propagates the error code. - parse_str only checks if get_aux reached EOF, or found the end tag (which would mean there's no text, as in foo/foo). In the case of PARSE_OVERFLOW it will just continue. - parse_str checks that the /md5_cksum tag follows, etc. and returns successfully. The FILE_INFO parser now thinks nothing went wrong, since parse_str returned success. But the md5_cksum array is not null-terminated, unless its last position already happened to contain a null character before parsing. Any code that reads file_info.md5_cksum will go past the array bounds. I didn't follow the code flow in the case the element contains even more data (ie. if it would overflow by more than 1 byte), but my guess is that it would also return successfully, truncate the data silently, and leave a non-terminated buffer. -- Nicolás ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Transferring jobs.
Hi! I guess the answer depends on what else you are doing with the hosts. One solution could be BOINC installed to a USB or otherwise portable disk and use it at different hosts. I'm not sure what limitations exist for doing this under Windows (registry entries???) but for Linux it should work. If the hosts are doing nothing else but BOINC, Dotsch/UX [1] is offering an easy solution to run BOINC and the whole Linux OS around it from a USB stick. When it's time to communicate results and download new tasks, you would physically move the stick to a different host that has Internet connectivity. I'm not sure how well Dostch runs inside a VM (obvious problems with GPU apps...), maybe that would be an option if you need to have Windows on the host and run different stuff other than BOINC there as well. Maybe even a native installation to a USB drive under Windows would work. [1] http://www.dotsch.de/boinc/Dotsch_UX.html Cheers HB From: McLeod, John john.mcl...@sap.com To: Admin Team \St.Petersburg\ st.petersburg.bo...@gmail.com, boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu, Date: 01/14/2013 02:34 PM Subject:Re: [boinc_dev] Transferring jobs. Sent by:boinc_dev-boun...@ssl.berkeley.edu Basically, the answer is it is very painful. There are several people that have tried, but they all give up after a week or two. -Original Message- From: boinc_dev-boun...@ssl.berkeley.edu [ mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Admin Team St.Petersburg Sent: Sunday, January 13, 2013 2:40 PM To: boinc_dev@ssl.berkeley.edu Subject: [boinc_dev] Transferring jobs. Hi. Maybe who will prompt? How it is possible to transfer tasks from my computer to another? On other there is no Internet. I want to carry there tasks for Boinc. It is desirable to tell more precisely. I thank. Andrey. -- Желаем Вам всем не болеть и не тужить. Всего хорошего. Администрация команды. St.Petersburg. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] [PATCH] problem in get_vendor in api/boinc_opencl.cpp
Hi all! Someone familiar with BOINC's OpenCL code should have a look at the attached patch. 1) It corrects one clear bug (use of sizeof() on a pointer var to get the length of the array pointed to...doesn't work). 2) There is another more subtle point that needs checking. In the original form, get_vendor() returns the Vendor string supplied by the openCL API call in case none of the conditions that are used to detect AMD, NVIDIA, and INTEL GPUs matches. In most cases (say, vendor =Acme), this will cause problems in the calling code because, as I understand it, get_vendor() should translate native vendor names to standard canonical names used by BOINC. So I think the intended behavior was to return CL_INVALID_DEVICE_TYPE in this case and this is another bug. However, if the openCL API returns ATI (for legacy cards/drivers ), this would actually happen to work because it coincides with the canonical vendor name used by BOINC for ATI/AMD GPUs, even tho the original code doesn't try to match ATI. The enclosed patch deals with this by adding an explicit match with ATI and otherwise returning an error if no match is found with known vendor name patterns. OK? Cheers HB 0001-Fix-for-buffer-overrun-ish-problem-in-get_vendor-cau.patch Description: Binary data ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Feature proposal: Safeguards against excessive checkpointing?
Dear all, At E@H we have one app that (at least in the GPU variant) calls boinc_time_to_checkpoint() very frequently (more than once per second, far less frequently in the CPU version). We noticed that for volunteers who changed the default checkpointing interval to something like, say,1 or 0 sec, our app will as a consequence checkpoint every second. Per task...not nice on multicores :-) As this is a BOINC global setting and some projects (current or future) might actually for some weird reasons want to do it that way, I think there is no need to change the web interface or client. But I wonder whether there should be some convenient way in the API code (at runtime or compile time) to specify an override for a sensible minimum time interval between checkpoints based on the knowledge of the app developers, e.g. the cost of preparing and writing the chekpoint file. E.g. if the checkpointing is very expensive, you definitely don't want to checkpoint every second even if the volunteers *allow* you to do that. So what are the opinions here? Would it make sense to have something either at BOINC API compile time (e.g. -DBOINC_APP_MIN_CPT_INTERVAL=10) or on the C API level to enforce a minimum checkpoint interval ? I'd rather not deal with time stuff in the app code itself if BOINC can do that for me. P.S.: In addition, the general defaulting to (effectively) 1 sec checkpointing might be not a good idea in the current code. Maybe 60 seconds??? Ideas? Opinions? Thanks in advance HBE ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Fwd: RE: help needed on BOINC
Hii David, Let me summarise a discussion we (Oliver, Bernd, me) at E@H had on this: One API that's always available is OpenGL (and DirectX on Win). We think this assumption may not hold for (near) future or even present day accelerator products, (and accelerators in general are what we should be dealing with): We doubt that NVIDIA Tesla installations (those do not even have video out) or the upcoming Intel Xeon Phi (formerly known as MIC) cards will necessarily support OpenGL or DirectX. Same holds for headless setups in general. Should we be using these (in addition to, or preferably instead of) the other APIs, to enumerate GPUs? Probably not instead of, for the reasons given above. Just our 2 cents. HB boinc_dev-boun...@ssl.berkeley.edu wrote on 07/04/2012 09:19:08 AM: From: David Anderson da...@ssl.berkeley.edu To: Rom Walton rwal...@ssl.berkeley.edu, Charlie Fenton charl...@ssl.berkeley.edu, BOINC Developers Mailing List boinc_dev@ssl.berkeley.edu, Date: 07/04/2012 09:19 AM Subject: [boinc_dev] Fwd: RE: help needed on BOINC Sent by: boinc_dev-boun...@ssl.berkeley.edu We've been enumerating GPUs first using vendor-specific interfaces (CUDA, CAL) and then OpenCL. However, there are GPU apps that don't use any of these (see below) and that work even if none of these APIs are available. To support such apps in general we need to have some other way of enumerating GPUs. One API that's always available is OpenGL (and DirectX on Win). Should we be using these (in addition to, or preferably instead of) the other APIs, to enumerate GPUs? -- David Original Message Subject: RE: help needed on BOINC Date: Wed, 4 Jul 2012 07:00:57 + From: Jin, Jennifer jennifer@intel.com To: David Anderson da...@ssl.berkeley.edu Professor David: The application is a .net based multi-media processing application. I am in China now, otherwise I can lend you a Intel PC:) -Jen -Original Message- From: David Anderson [mailto:da...@ssl.berkeley.edu] Sent: Wednesday, July 04, 2012 2:47 PM To: Jin, Jennifer Subject: Re: help needed on BOINC Jen: What application are you talking about? Is it written using OpenCL? Does it currently work with an Intel GPU? ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
