[boinc_dev] Games with BOINC? "Fold.it" game uses Rosetta @ Home core, with some minor BOINC framework inheritances ...
Games with BOINC? "Fold.it" game uses Rosetta @ Home core, with some minor BOINC framework inheritances ... uTorrent's mining of BitCoins is not exactly novel, but the initial implementations (due to lack of informing even Beta users) upped the program to borderline Malware with many Anti-virus programs. Turning off the crypto currency mining is not an option in the "Advanced Options", so there is still some work to be done to make the implementation fully street legal. BitTorrent Sync does not yet to BitCoin mining, but it may soon anyway. BitTorrent INC -- at least with respect to the lawful setup and running of some of its programs ... really should be doing "Class Action Lawsuits" with respect to some of its programs vs some Anti-virus entities like "Norton" (part of Intel-INC) and others ... BitCoin Utopia is however, quite legal and well within the terms of the way the BOINC framework can be used. The global macro-economy is a fragile one, so for a scientific project to use or depend somewhat on any cryptocurrencies is a reasonable "self protection measure" ... Because BOINC's framework is entirely of US origin, its terms (and terms enforcement) outside the US "are really only within the terms of nation where the localized BOINC project server resides" -- and in spite of some of the recent changes in the framework governance of the BOINC system not much has changed. Max Power, CEO DSN @ H -Original Message- From: Nicolás Alvarez Cc: BOINC Development Subject: Re: [boinc_dev] Games with BOINC? Informed consent for this kind of stuff is hard to get. Did you know uTorrent mines litecoins for BitTorrent, Inc's profit in the background? It's right there in the middle of the legal terms. -- Nicolás 2015-08-24 15:22 GMT-03:00 Jacob Klein <jacob_w_kl...@msn.com>: > He never said "without user's consent", and in fact later clarified that > he would have the user's consent. > This is a legitimate question, with no malicious intent, so far as I know. > Try not to make assumptions. > > > From: nicolas.alva...@gmail.com > > Date: Mon, 24 Aug 2015 15:18:57 -0300 > > To: henri.heino...@gmail.com > > CC: boinc_dev@ssl.berkeley.edu > > Subject: Re: [boinc_dev] Games with BOINC? ___ 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] Easier fixes needed than the points system : Move the BOINC SSL aka TLS to Elliptic Curves (as it is a simi-closed SSL ecosystem)
Easier fixes than the points system : Move the BOINC SSL aka TLS to Elliptic Curves (as it is a simi-closed SSL ecosystem) https://www.youtube.com/watch?v=33RbRid1deo It would be nice if Berkley Uni were a Signature Authority but it is not. ___ 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] 4 classes of credit are enogh, if computing is a complex number ... or a tuple
Yes, the basic proposal for updating the BOINC Credit System is sound ...
but due the basic fact that GPUs that are so like CPUs ... it would seem
that a complex number or a tuple for Computing Credit .
The whole BitCoin minting with ASICs issue that is forcing this long overdue
distinction -- is caused by the fact that BOINC's job of measuring CPU
performance with BINARY MATH OPERATIONS was dismal from the beginning.
Binary Math Operations on a CPU are not really Integer Math, but still
subject to Integer Math control logic. Unlike Floating Point Math that
requires some overhead to keep the numbers sane (up to 2% of CPU time for
some kinds of algorithms {climate prediction?, protein folding?} , but
usually 0.1% to 0.5% of CPU time) ... binary math has no such overhead.
Binary Math registers also vary in size, and so do the supporting
instruction sets. Performance varies wildly.
? ! ?
In any case : There was no BOINC benchmark that measured a CPUs (or GPUs)
ability to do binary math operations.
There is one existing project that was affected by this quirk before
BitCoins came around :
Rainbow Table Generation (something, something ... I forget its name )
!
YES, the basic idea below will fix the problem.
NO, it will not be adequately workable unless the Computing Credit becomes a
Vector or Tuple.
!
MP DSN @ H
PS :
Do some background research to make certain that the BOINC implementation is
not like anything patented. The possibility for conflict here is slim, but
there are 2 or 3 other distributed computing systems like BOINC that are
private or closed source.
So, I propose that, rather than trying to shoehorn everything into one
number, we keep track of multiple types of credit. In particular, I propose
4 types:
Computing credit: general-purpose FLOPs, i.e. what we have now.
Storage credit, measured in byte/seconds (possibly multiplied by
availability).
Network credit, measured in bytes, the sum of upload and download.
Project-defined credit. Projects can define and grant this however they
like. For BU, this would be proportional to hashes.
-- Other projects, like Wildlife@home, might grant credit for a human
activity like annotating video.
-- We'll add APIs so that project validators can grant the new types of
credit. We'll figure out how to make them cheat-resistant.
The BOINC database will maintain each of these types of credit for each
host, user, and team. It will store both total and recent average for each
type.
Wherever we show credit on project web sites - leader boards, user and team
pages, etc. - we'll show one or more credit types; the choice of types will
be configurable by the project.
The new types of credit will be included in the XML statistics files
exported by projects. Statistics sites (such as BOINCStats) will be extended
to show the new types of credit.
-Original Message-
From: David Anderson
Sent: 11 August 2014 23:48
Subject: [boinc_projects] Credit revisited
A proposal for extending BOINC's credit system to handle
special-purpose computing (such as BitCoin mining)
as well as storage and communication:
http://boinc.berkeley.edu/trac/wiki/CreditGeneralized
___
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] Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ...
Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ... It’s a layer cake -- “allows the creation of” [Binary Math Ops] – [Integer Math Ops] -- if your CPU only understands INTs -- Floating Point can be emulated with Int Math and Binary Ops [Binary Math Ops] – [Integer Math Ops] -- [Floating Point Math Ops] -- ^ ^ If the CPU does native Floating Point ^ ^ -- If all integer control logic is removed, Binary Math Ops go at true clock speed -- Int and Float math will never really reach true clock speed, as there is an inherent overhead as both are based on Binary Math Ops (and Microcode based CPUs are worse for speed for this reason) This is why ASICs do binary hashes so fast, yet Cray XPs struggle in massive parallelism to perform Floating Point at anything like real clock speed. Moral : When in doubt go to the fundamental underlying framework to help solve a problem, if no other solution is working. MP DSN @ Home PS : I have designed a CPU, but C is for Climate ... http://www.scribd.com/doc/209133631/Climate-Prediction-Coprocessor My feeling about this is that computing credit should be measure general-purpose FLOPs, i.e. FLOPs that are usable by most science applications. FFT FLOPs are not general-purpose. So the right thing would be for SETI@home to grant both computing credit and project-defined credit. CPU and GPU jobs would be granted both; jobs done by ASICs or FPGAs would be granted only project-defined credit. Similarly, BU could grant computing credit for mining jobs done by CPU or GPU; but for ASIC jobs it would grant only project-defined credit. Of course this is all subjective and fuzzy; you might argue that GPU FLOPs are not general-purpose because some apps don't map well to GPUs. But we need to draw a line somewhere, and I think that, with the advent of OpenCL, GPUs can be considered general-purpose. ___ 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] Faulty reasoning in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ...
Binary math operations are easy to spot, as they do not look like Int math operations Typically -- AND | OR | XOR | XAND | NOT | SHIFT_L | SHIFT_R | ROTATE_L | ROTATE_R -- RESET_REGISTER ... but this is used by Int and Float not just Binary Math but included for Turing State Machine reasons -- Shift and Rotate also exist in versions without CARRY -- https://en.wikipedia.org/wiki/Category:Digital_circuits : this really applies here -- https://en.wikipedia.org/wiki/Boolean_algebra : tools of the trade -- https://en.wikipedia.org/wiki/Boolean_algebra_(structure) -- https://en.wikipedia.org/wiki/Bitwise_operation -- https://en.wikipedia.org/wiki/Binary_adder : it does not operate in the int domain at all -- https://en.wikipedia.org/wiki/Bit_manipulation Unlike Int and Float math or logic, Boolean Algebra registers ARE NOT BOUND BY IEEE or other FLOATING POINT MATH STANDARDS -- 256 bit wide registers : fine -- 1024 bit wide registers : good -- 2048 bit wide registers : hey, that's a lot of logic gates ... Moral : IF and ONLY IF the instruction logic uses Binary Math operations, that instruction set logic can be implemented in Logic Circuits that can run at clock speed. Logic Circuits can be made to have a 'data flow archecture', speeding up the instruction logic by many orders of magnitude. MP DSN @ Home -Original Message- From: McLeod, John Sent: 12 August 2014 05:55 To: Max Power ; BOINC Developers Mailing l...@berkeley.edu Subject: RE: [boinc_dev] Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ... I am not at all certain I understand your distinction between Binary Math and Integer Math. By Binary Math do you mean control logic? If not, what do you mean? Almost all integer math can be done in machine registers now since the narrow machines are 32 bits (+/- 2*10^9) and wide machines are 64 bits (+/- 9*10^18). There are only a few kinds of calculations that have intermediate or final results larger than that. It is not that hard to produce a math class that can do arithmetic to 128 bits - which should be sufficient for just about everything other than encryption. -Original Message- Subject: [boinc_dev] Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ... Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ... It's a layer cake -- allows the creation of [Binary Math Ops] - [Integer Math Ops] -- if your CPU only understands INTs -- Floating Point can be emulated with Int Math and Binary Ops [Binary Math Ops] - [Integer Math Ops] -- [Floating Point Math Ops] -- ^ ^ If the CPU does native Floating Point ^ ^ -- If all integer control logic is removed, Binary Math Ops go at true clock speed -- Int and Float math will never really reach true clock speed, as there is an inherent overhead as both are based on Binary Math Ops (and Microcode based CPUs are worse for speed for this reason) This is why ASICs do binary hashes so fast, yet Cray XPs struggle in massive parallelism to perform Floating Point at anything like real clock speed. Moral : When in doubt go to the fundamental underlying framework to help solve a problem, if no other solution is working. MP DSN @ Home My feeling about this is that computing credit should be measure general-purpose FLOPs, i.e. FLOPs that are usable by most science applications. FFT FLOPs are not general-purpose. So the right thing would be for SETI@home to grant both computing credit and project-defined credit. CPU and GPU jobs would be granted both; jobs done by ASICs or FPGAs would be granted only project-defined credit. Similarly, BU could grant computing credit for mining jobs done by CPU or GPU; but for ASIC jobs it would grant only project-defined credit. Of course this is all subjective and fuzzy; you might argue that GPU FLOPs are not general-purpose because some apps don't map well to GPUs. But we need to draw a line somewhere, and I think that, with the advent of OpenCL, GPUs can be considered general-purpose. ___ 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] Adding BOINC API versioning, sometimes BOINC version number not entirely adiquate
I agree that the BOINC API needs to have some sort of version testing
interface. Just using the Client Version Number and a lookup table outside
the API interface is doable now, but there would be some heavy lifting to
build the table with information valid from V4 to V-Current.
General principals that should be followed for an API numbers interface
1. The Version Numbers API should return an xml structure.
-- PRINTABLE ASCII aka ASCII-6 should be the encoding standard (written as
ASCII-8, to the file system).
-- No oddball control chars permitted! Ding!
-- It should all be strings not binary encoded data, conserving memory is
not that hyperimportant here.
2. You should not have to use the Version Numbers API [at all] if there is
some wrapper-centric reason that makes it impossible.
-- The API versions xml structure should also be rendered as a static
readable file in each project's data or binary working area.
3. The Version Number API should itself have version numbers, and should
have expansive enough in its data structure to cope with Beta testing of
modifications of the API. Vaguely like ... { struct API_nums { {array
[Version, API, nums, hex_string(CRC32-mpeg())]; } } ...
4. As far as I can tell, it is too late to patch the API to add in some
mechanism for version numbers support. Having set aside nonsense values in
the API to return version numbers could be considered, but where or how the
version numbers would be returned is beyond my imagining. This is the Kuldge
solution, and it is not a pretty one.
-Original Message-
From: Raistmer the Sorcerer
Subject: [boinc_dev] Feature request: to add BOINC API versioning
Please implement BOINC API versioning in the way it done for BOINC client
releases.
This will allow to link scientific apps vs known API set with known features
and issues.
___
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] BUG ALERT : BitCoin Utopia is giving out workunits when the client setting is no new work units, ... and generally behaving daft ...
BUG ALERT : BitCoin Utopia is giving out workunits when the client setting is no new work units, ... and generally behaving daft ... This platform is affected, but lots of other platforms are affected ... and the problem may be a 7.2.42 bug and or a server bug at the other end ... I am just relaying this bug alert for someone else. 18 Jul 14 13:56:33 | | Starting BOINC client version 7.2.42 for windows_x86_64 18 Jul 14 13:56:33 | | log flags: file_xfer, sched_ops, task 18 Jul 14 13:56:33 | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6 18 Jul 14 13:56:33 | | Running as a daemon 18 Jul 14 13:56:33 | | Data directory: C:\ProgramData\BOINC 18 Jul 14 13:56:33 | | Running under account boinc_master 18 Jul 14 13:56:33 | | No usable GPUs found 18 Jul 14 13:56:33 | | Host name: admin-PC 18 Jul 14 13:56:33 | | Processor: 4 GenuineIntel Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz [Family 6 Model 42 Stepping 7] 18 Jul 14 13:56:33 | | 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 syscall nx lm vmx tm2 pbe 18 Jul 14 13:56:33 | | OS: Microsoft Windows 7: Home Premium x64 Edition, Service Pack 1, (06.01.7601.00) 18 Jul 14 13:56:33 | | Memory: 3.91 GB physical, 7.83 GB virtual 18 Jul 14 13:56:33 | | Disk: 195.32 GB total, 83.80 GB free 18 Jul 14 13:56:33 | | Local time is UTC -7 hours 18 Jul 14 13:56:33 | | VirtualBox version: 4.3.10 18 Jul 14 13:56:33 | Asteroids@home | URL http://asteroidsathome.net/boinc/; Computer ID 58820; resource share 100 18 Jul 14 13:56:33 | rosetta@home | URL http://boinc.bakerlab.org/rosetta/; Computer ID 1552733; resource share 110 18 Jul 14 13:56:33 | Poem@Home | URL http://boinc.fzk.de/poem/; Computer ID 160188; resource share 100 18 Jul 14 13:56:33 | NRG | URL http://boinc.med.usherbrooke.ca/nrg/; Computer ID 3022; resource share 100 18 Jul 14 13:56:33 | fightmalaria@home | URL http://boinc.ucd.ie/fmah/; Computer ID not assigned yet; resource share 100 18 Jul 14 13:56:33 | climateprediction.net | URL http://climateprediction.net/; Computer ID 1226576; resource share 200 18 Jul 14 13:56:33 | convector.fsv.cvut.cz | URL http://convector.fsv.cvut.cz/; Computer ID 3662; resource share 105 18 Jul 14 13:56:33 | SLinCA@Home | URL http://dg.imp.kiev.ua/slinca/; Computer ID 7316; resource share 100 18 Jul 14 13:56:33 | Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 9495716; resource share 100 18 Jul 14 13:56:33 | NFS@Home | URL http://escatter11.fullerton.edu/nfs/; Computer ID 347861; resource share 100 18 Jul 14 13:56:33 | LHC@home 1.0 | URL http://lhcathomeclassic.cern.ch/sixtrack/; Computer ID 10300033; resource share 100 18 Jul 14 13:56:33 | Milkyway@Home | URL http://milkyway.cs.rpi.edu/milkyway/; Computer ID 456083; resource share 100 18 Jul 14 13:56:33 | pogs | URL http://pogs.theskynet.org/pogs/; Computer ID 541; resource share 100 18 Jul 14 13:56:33 | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID 6720130; resource share 100 18 Jul 14 13:56:33 | SZTAKI Desktop Grid | URL http://szdg.lpds.sztaki.hu/szdg/; Computer ID 341380; resource share 100 18 Jul 14 13:56:33 | Bitcoin Utopia | URL http://www.bitcoinutopia.net/bitcoinutopia/; Computer ID 3562; resource share 100 18 Jul 14 13:56:33 | Cosmology@Home | URL http://www.cosmologyathome.org/; Computer ID 167440; resource share 100 18 Jul 14 13:56:33 | Enigma@Home | URL http://www.enigmaathome.net/; Computer ID 108508; resource share 100 18 Jul 14 13:56:33 | malariacontrol.net | URL http://www.malariacontrol.net/; Computer ID 563008; resource share 100 18 Jul 14 13:56:33 | | General prefs: from http://bam.boincstats.com/ (last modified 21-Apr-2013 16:19:01) 18 Jul 14 13:56:33 | | Computer location: home 18 Jul 14 13:56:33 | | General prefs: using separate prefs for home 18 Jul 14 13:56:33 | | Reading preferences override file 18 Jul 14 13:56:33 | | Preferences: 18 Jul 14 13:56:33 | | max memory usage when active: 2405.06MB 18 Jul 14 13:56:33 | | max memory usage when idle: 2405.06MB 18 Jul 14 13:56:33 | | max disk usage: 4.00GB 18 Jul 14 13:56:33 | | max CPUs used: 2 18 Jul 14 13:56:33 | | max download rate: 61440 bytes/sec 18 Jul 14 13:56:33 | | max upload rate: 40960 bytes/sec 18 Jul 14 13:56:33 | | (to change preferences, visit a project web site or select Preferences in the Manager) 18 Jul 14 13:56:33 | | Not using a proxy ___ 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] What is this row over US net neutrality? Net Neutrality (or lack thereof) is not the greatest threat to Distributed Computing...
What is this row over US net neutrality? As Alistair Cooke (or someone similar) is no longer around to explain the nature of the problem, I am slightly at a loss as to what the row is about. Net Neutrality (or lack thereof) is not the greatest threat to Distributed Computing ... at best it does not even make the top 20 reasons why Distributed Computing is under threat (in the US or EU or the Asia-Pacific region). There is at least one screen saver that hints of other problems, but it is under development -- and its contents are volatile to change. http://cbc-am/dsn-at-home.scr Not that it is related, but it is estimated that the Snoden files cost the US Tech Sector about 1200 million USD in Asia this past Quarter and for the whole of 2014 may reach 3800 millions USD in losses. The BOINC system (client or server) is still ‘shackled to the corpse of the x86’ but this is supposedly getting better as time goes on. The whole technology used by BOINC may not be the same in 10 years ... but the global finance system risks could eliminate 1/3 of all BOINC users in 6 months or so it goes. ___ 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] How much will this -- or any upcoming EU bans onpersonal data -- affect BOINC project databases ... that store but a fragment ...
Your proposed solution sounds like overkill, considering how little personal information is stored by the BOINC databases. You are broadly right about elites and 'in country operation', this business realpoltick seems almost eternal. There are no easily reached Russia based BOINC projects, so no experts can be contacted ... ironically there is a BOINC project in Ukraine. A boffin at the RU Academy of Sciences, that has had a chance to read the law ... probably would recommend almost no changes. (Login Information + Computer Information Personal Information) -- A lot of BOINC Computer Information has nothing to do with the work units per se, or how they are managed ... -- Login information has to have some minimal complexity to allow for logins at all, save for storing IPs not much other data is personally trackable ... -- if you have [on the whole] less than maybe 5 to 10 records of account information that probably does not count -- diagnostic usable information is not necessarily personal information MP DSN @ Home PS : As Kiev, Ukraine is so close to Vienna (a rat's nest of spys since 1945), its problems may not be coming from the East. If this is the case, its problems will take some time to resolve. I blame the whole crisis on the lack of a decent ionspheric plasma display like the famous one in Norway (Sweden? Finland?) on the YouTube that happened some years back. -Original Message- From: Charles Elliott A long time ago, somewhere I read that the key to doing business successfully in a foreign country is to find out what the elites are trying to accomplish there and then do business in a way that helps them to accomplish it, as long, I suppose, you can do that without violating your own important cultural values. Someone could contact the Russian ambassador and ask him/her what Russia really wants, or ask Rastimer to contact his Duma representative to see what it wants. If all Russia wants is to have the sanctions lifted, we may have to wait until the Ukraine situation is clearer. In any case, how hard could it be to ask one of the Russian universities to host a duplicate of the information on all Russian participants? Charles Elliott -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Bernd Machenschalk Sent: Monday, July 7, 2014 6:32 AM To: boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] How much will this -- or any upcoming EU bans on personal data -- affect BOINC project databases ... that don't really store but a fragment ... At first glance I find the article pretty ambiguous in its attempt to translate the Russian law into English. E.g. it first speaks of Internet companies (which BOINC or BOINC projects certainly aren't), and later about Websites. personal date is also unspecified. Does someone on this list has access to the actual law text and can provide a more precise translation? Best, Bernd On 07.07.14 12:13, Max Power wrote: - --- How much will this -- or any upcoming EU ban on personal data -- affect BOINC project databases ... that don't really store but a fragment ... This probably has to do with the Snoden Files, that have revealed that storing data in a US or EU cloud is as good as giving the data to the NSA or GCHQ. - --- http://rt.com/politics/170604-russia-personal-data-servers/ ___ 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] Applications absolutly not updating % work done ... cleanmobility.now 6.06 of http://qmcathome.org/
Applications absolutely not updating % work done at all : This month it is cleanmobility.now 6.06 of http://qmcathome.org/ -- 6.05 or 6.04 would update % done at reasonable intervals – by no means perfect or linear – but better than nothing -- Now, nothing but silence -- Based on the behaviors of 6.05 etc ... one could guesstimate runtime completion, but this is not possible Oddly this extent of bad application behavior is quire rare, maybe one release version in 25 per year does this. It could just be caused by a malformed (botched syntax etc ...) settings file, per each work unit – so fixable. MP DSN @ H ___ 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] MemSet and C++ Classes, or the tragedy of the BOINC client not being written in ADA 95 ...
MemSet and C++ Classes -- or the tragedy of the BOINC client (and Server) not being written in ADA 95 (or whatever version it is currently at) ... The real tragedy is that the BOINC Client and Server are not written in ADA. ADA forces people away from a lot of the syntactical nonsense that most other languages permit. You cannot even compile an ADA project unless it is self consistent. JAVA comes close to ADA in its enforcement of not allowing the programmer to do incoherent things typical mistakes. Neither JAVA or ADA are perfect. Yet the upper level 'assembly language' mistakes that C, C++ etc permit without question are not so easy to do in ADA. One would think that Berkley Uni (that gets gobs of defense research funding) would have forced most of its 'mission critical' computer projects to be written in ADA. Sadly, because SETI @ Home was written in C++ ... BOINC became written that way. Now the middleware that runs SETI, Rosetta, etc ... is C++. It is like being shackled to a corpse... -- In the 1st World War, a German officer (but many Germans in the later years of the war) described the relationship between Austria-Hungary and Germany as Being Shackled to A Corpse (in translation, it is often Fettered to A...). -- C++ and BOINC are related in this way. It causes no end of grief. C++ is still at best an upper level assembly language. MP DSN @ H -Original Message- From: Nicolás Alvarez Cc: boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] MemSet and C++ Classes. 2014-01-09 10:50 GMT-03:00 McLeod, John john.mcl...@sap.com: In short, don't use memset on any structure that includes a class. The class constructor may intentionally set internal variables that are not 0. The implementation of each class may vary from platform to platform, and may vary over time. These bugs can be hard to track down. Much better is to use classes and constructors / destructors for everything. The built in default constructor if you don't declare one is supposed to set all values in the class to 0 or null. The built in destructor does nothing. Here are five real (fixed) bugs caused by memsetting things that aren't supposed to be memset: http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=8728c049 [...] http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=3db80eb5 ___ 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] A viable alternative to the infinitely variable Client ID problem (that on VM systems creates thousands of IDs), but for most hosts only changes each update ...
A viable alternative to the infinitely variable Client ID problem (that on VM systems creates thousands of IDs), but for most hosts only changes each update ... The one project this seems to affect directly : Einstein @ Home -- but any project with a large user base has the “Client ID flux problem” ... The Current state of things 1. Each time you update or upgrade a BOINC Client, a new Client ID gets generated. Mostly this only happens less than 5 times per year -- so not much database cleaning is needed. Mostly the project users do this with the “Merge CPUs” section of the project website, relating to tracking how many PCs the user has registered to that project. 2. Running BOINC in fixed and stable VMs does not induce extra Client ID generation to any extra extent. 3. In “Cloud” computing, VMs getting assigned BOINC images induce extra Client ID generation each time. Here is where the massive database bloat seems to be. There is a lot of DB user record cleaning and maintained involved as when this happens it happens in the millions. The solution TURN THE “Client ID” into some kind of tuple ... 1. A less volatile Client ID structure would be something like this -- Client_ID_tuple (“DE00KK”, md5(CPUID_record_all_bits), md5(GPU_ID), md5(OS-String), md5(BOINC-bild-id), md5(Client_ID(old))) -- “DE00KK” to “DE99KK” is for version numbers, this is standard Morse Code notation. -- Depending on what the xml syntax will permit, each tuple element could be separated by “|” or “;” or “,” ... -- 3 x MD5s would not consume too many more bits the SHA hash used now -- It is expected that on VMs ... that all three of these fields will not change each time a BOINC image is moved from one VM to another. -- The old Client_ID generation code would only be needed to run each time one updates to a new BOINC client version. The other signature elements in the tuple would not change, but on VMs at least only 2 of them might change. Some database logic could see the defect and merge the proper records. -- The bytes consumed here is hopefully no more than 3x the current Client_ID, but as this may save millions of regenerated Client_IDs from being generated and stored this is a modest cost. 2. Dragons a. CPUID is an x86 dependency, so for ARM or other CPU designs some other kind of CPU fingerprinting will be required. The Methods used for each CPU type will vary, so feel free to standardize on something sane and workable. b. On different OSes, the “OS-String” may be put in places different from the Linux / BSD / OSX / Windows locations. However, even QNX and Minix3 puts this string in a place that is within the standards of POSIX. Some edge code may be required on each OS. c. BOINC-build-id is the only component that is standardized here. It will only change each update. d. GPU_ID will need to have some preset values to indicate that no usable GPU is available. Otherwise use the standardized string that identifies the GPU within its API. There will be some edge code issues here. On VMs, direct use of the GPU may be mostly impossible -- but the outcome will hopefully always be “No GPU found”. e. Some VMs may forbid x86 CPUID instruction use, so a preset value will be needed to indicate this. This may be the one easy way to hint that a BOINC client is running in a VM. f. Some way will have to be found to change the Client_ID(old) a lot less often. With each update it should change, but changes should otherwise happen no more than 4x per year. Taking an md5() snapshot of it will reduce the bits required to store it. I don’t know if this will fix the problem, but it may at least get part of the way. MP DNS @ H ___ 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] Estimated Time Remaining, frictional reporting : Duration Correction Factor CLIENT + Duration Correction Factor SERVER is a good autonomous solution ...
Estimated Time Remaining, frictional reporting : Duration Correction Factor CLIENT + Duration Correction Factor SERVER is a good autonomous solution for all parties involved. This approach allows for some sensible Artificial Intelligence to be done at the Client. -- The Client probably has better knowledge about possible work unit completion [and overall progress] than the project server ever will. -- This is sort of the nature of distributed computing, when one is using different kinds of computers to run the numbers. The Client can build up a behavioral database [on a per application basis], and use statistics for deriving Duration Correction Factor CLIENT. The Client -- Server hint data structure -- The Client need only pass back to the server 2 or 3 numbers to correct Duration Correction Factor SERVER. -- If the Server does not support decoding the data structure it will be ignored. -- BOINC Server version numbers can be used to turn off or on this hinting, thus avoiding unnecessary traffic generation, will I hope this is possible... -- How or where this will be transmitted, received and processed (and used) I do not know. The Data Structure -- Version number : Unsigned Byte -- Certainty (%) : (Unsigned or Unsigned) Byte (5 decimal to 95d in steps of 5), signed to use sign as parity bit... -- Seconds Delta : Signed Int ~= 9 hours differential possible per communication; Math = [32k/60]/60 -- Sample age seconds : Unsigned Byte (only use 100 to 180 decimal, mostly 101 to 123 used), resample greater than 67s -- Reserved for future use : Unsigned Int, could provide the last unsigned int of Unix Time (signed int64) timestamp of sample time -- Optional : Sequence Number : Byte -- aka how many times has a correction been sent after UTC 00:00 ... Keep it under 100! -- Checksum : CRC-16-CCITT, CRC32-mpeg if Client ID and Application Hashsum are used. -- So under 80 bits, certainly under 100 bits. -- Adding the Client ID (and Application Hashsum) will up the bits used, but still keep the traffic overhead to under 1000 bits. Meanwhile, Duration Correction Factor SERVER is still available. Modifying Duration Correction Factor SERVER (to accept hints from Duration Correction Factor CLIENT) may take some re-designing, but can evolve over time. Possibly 2 or 3 correctional constants might be needed at Duration Correction Factor SERVER, but can only be derived from real time Client performance data. MP DSN @ H -Original Message- From: McLeod, John Sent: 13 February 2014 13:09 To: Jon Sonntag Cc: BOINC Developers Mailing List @berkeley.edu Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... Another is to have the client reinstate some form of Duration Correction Factor – so that the client did not have to wait for the server to update the estimates. It might make sense to make the DCF for projects that use the server side calculation react faster than the DCF for projects that do not. This would also have to be done with the understanding that the server side correction is in effect so new downloads would start with no DCF applied at first. ___ 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] When running Einstein @ Home (or other apps?), and accessing the Notices tab -- the user interface program often dies
When running Einstein @ Home (or other apps?), and accessing the Notices tab -- the user interface program often dies. When you run the user interface program again, the Notices show up just fine. This seems to be true with the Virtual Box version, but VB is probably not part of the problem. The VB network seems to consume some traffic, even when you have no VBOX applications – and the program does not explain why this is so. -- Checking for updates only requires about 2kb. -- This is in the default installation state, so no VB apps at all. 25 Nov 13 18:02:35 | | cc_config.xml not found - using defaults 25 Nov 13 18:02:35 | | Starting BOINC client version 7.2.28 for windows_x86_64 25 Nov 13 18:02:35 | | log flags: file_xfer, sched_ops, task 25 Nov 13 18:02:35 | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6 25 Nov 13 18:02:35 | | Data directory: C:\ProgramData\BOINC 25 Nov 13 18:02:35 | | No usable GPUs found 25 Nov 13 18:02:35 | | Processor: 4 GenuineIntel Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz [Family 6 Model 42 Stepping 7] 25 Nov 13 18:02:35 | | 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 syscall nx lm vmx tm2 pbe 25 Nov 13 18:02:35 | | OS: Microsoft Windows 7: Home Premium x64 Edition, Service Pack 1, (06.01.7601.00) 25 Nov 13 18:02:35 | | Memory: 3.91 GB physical, 7.83 GB virtual 25 Nov 13 18:02:35 | | Disk: 195.32 GB total, 109.17 GB free 25 Nov 13 18:02:35 | | Local time is UTC -8 hours 25 Nov 13 18:02:35 | | VirtualBox version: 4.2.16 ___ 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.
