Posts by pschoefer

21) Message boards : Questions and problems : [Discussion] 4th Generation BOINC credit system (Message 69140) Posted 24 Apr 2016 by pschoefer Post: The justification for holding onto the team membership requirement is purely for the ability to kick cheating users from the team. [...] When an user's CPID is detected as invalid due to leaving the team, it'll be 24hrs before the next superblock can register their returned presence in the team, so if a cheater doesn't notice they may be prevented from earning rewards for days. OK, so it's basically the only straw you can catch until the lifeboats arrive. I understand. Why don't you remove the projects from the whitelist before the damage is done, i.e. removing all projects where cheating occured? The damage done by a single project isn't significant - 26 projects & 50k Gridcoin per day = 1923 GRC per project. So say someone is faking 25% of an individual project's team RAC they're earning approx $4.80/day fraudulently. The damage done to Gridcoin might insignificant, but how about the damage done to the project and the BOINC platform as a whole? If a small project without lots of experience and manpower fails to react to cheating fast enough, it'll lose both the enthusiast crunchers (because they feel that the project is treating them unfairly and is not well-maintained) and the Gridcoiners (because they don't get Gridcoins anymore), leaving only a few participants really dedicated to that project. It's easy to lose credibility, but hard to get it back. As soon as (again) someone finds a way to manipulate results in order to get more credit, projects might decide that distributed computing is not the way to go for them anymore. In more extreme cases, there might be bad publicity for BOINC. We already had someone distributing BOINC via a trojan. Also, a long-time top producer at SETI@home did run BOINC on school computers without permission (since he did not benefit financially, he was seen as a modern Robin Hood by some commentators... imagine the same story if he got money or Gridcoins for all that work). I'm not saying that all of this will happen just because someone offers cryptocoins for credits (after all, my examples are from the past when there was no *coin). But if people are cheating when there are only funny points and badges at stake, why should they stop if there is additional incentive? Somehow a picture crosses my mind that the people behind Gridcoin try to build an additional floor onto a house (BOINC), but while they know a lot about their building materials (cryptocurrencies), they don't yet understand the statics and the architecture of the house. There's no company behind the development of Gridcoin, just a group of volunteers (from around the world) that have been arguing over the consensus mechanisms, reward mechanism calculations, how to store BOINC statistics on the blockchain, and more. According to the points you mention, that group of volunteers appears to have discussed all the stuff that seems to be important for cryptocurrencies, but not that much about the problems and unwanted effects of it on BOINC. Exactly what I wanted to describe with my picture. Sure a large quantity of Gridcoin users likely haven't gone through the BOINC documentation to thoroughly understand it, but I doubt the majority of everyday BOINC users have done the same either. You're certainly right, and the majority (of all users including Gridcoin users) is also playing fair. The problems are caused by a small minority which understands BOINC well enough to know all the problems and use that knowledge for bad things. Anyone doing more than just crunching should understand BOINC and the influence of their actions on BOINC as good as that minority.
22) Message boards : Questions and problems : [Discussion] 4th Generation BOINC credit system (Message 69040) Posted 18 Apr 2016 by pschoefer Post: I think he brings it up because "cheating" can impact Gridcoin payouts. So, there is a financial and stability issue with their cryptocurrency payout system that they are probably hoping to fix. But, I have not read up on it much as I don't care about cryptos all that much. Indeed, the main reasons for pursuing the discussion/development of the 3rd gen credit system are the following: 1. Cheating the BOINC credit system allows users to earn Gridcoin fraudulently - this undermines the integrity of Gridcoin's Distributed Proof of Research reward mechanism. 2. I'm campaigning for the removal of the team 'gridcoin' membership requirement in the gridcoin system in order for all BOINC users to earn Gridcoin, not just one team. Due to the recent discovery of cheaters within and outwidth team Gridcoin, the team membership requirement has temporarily been deemed a neccessary evil in order for team founders to kick discovered cheaters from team gridcoin (cutting off cheaters from earning gridcoin fraudulently). 3. Despite team founders being able to kick users from the team, it's difficult to prove cheating (especially when users hide their hosts). This places team founder users in a difficult centralized position of power. To be honest, I don't know too many details of how Gridcoin works and my interest in it is not strong enough that I'd want to do much research on it. But as I might just not see the obvious, I'd like to know where exactly you see that team membership requirement being necessary to hold off cheaters from getting Gridcoins. What happens with a user's Gridcoins if he leaves or is kicked from team Gridcoin? Does he lose them? Does he keep them but can't use them for anything anymore? If he keeps them and still can use them, the "damage" has already been done at the time the user is kicked. Additionally, AFAIK, there's no way to prohibit a kicked team member joining the team again (it can only be closed for all not-members). Even if there was a way, the cheater might just create a new account. If cheating gets unmanageable, removing individual affected projects from the whitelist (ending distribution of gridcoin for work completed for a project) is a highly likely outcome. Well, although the Gridcoin homepage says "The BOINC RAC system has existed for many years and has proven uncheatable.", it just hasn't. I've been BOINCing for more than ten years and I've seen more or less massive cheating going on all the time. Over the years, almost all projects were affected. Faked benchmarks on projects using the first, benchmark-based credit system, and the CreditNew lottery in recent days were only the tip of the iceberg. In at least one case, even the scientific results were compromised... and back then, there were only credits and badges, Gridcoins might be an additional incentive for some. Why don't you remove the projects from the whitelist before the damage is done, i.e. removing all projects where cheating occured? Somehow a picture crosses my mind that the people behind Gridcoin try to build an additional floor onto a house (BOINC), but while they know a lot about their building materials (cryptocurrencies), they don't yet understand the statics and the architecture of the house.
23) Message boards : Questions and problems : [Discussion] 4th Generation BOINC credit system (Message 69039) Posted 18 Apr 2016 by pschoefer Post: I would like to start with a list of requirements a new CreditSystem should have. I would also like to centralize the discussion and not have two places with different people (here and at cryptocointalk). Lastly I wold also like to point to this proposal that came shortly after the rise of BitcoinUtopia: http://boinc.berkeley.edu/trac/wiki/CreditGeneralized I think there are at least two expectations on what a credit system should do: First, of course, users should be able to compare themselves with each other. Without some numbers reflecting the work they have done, there would be no competition, no challenges or races, no funny badges, etc., i.e. less incentive for many users. Second, from a more scientific point of view, it would be nice to have some project-wide and even BOINC-wide numbers reflecting the performance in FLOPS, bandwidth, etc. Publications could easily compare the project's performance with supercomputers and if someone asks about the total performance of the BOINC network, we would have a real answer instead of a rough estimate. Obviously, to match the second expectation, more quantities have to be measured, just like the CreditGeneralized proposal suggests. To match the first expectation, however, the credit system should follow the KISS principle. The CreditGeneralized proposal definitely isn't KISS and opens new cans of worms: - If only FLOPs are counted, how to deal with applications doing mostly integer arithmetics? Should they just grant less credit in this category or should we (again) count some FLOP equivalent unit rather than actual operations on application level? Of course, if we wanted to count actual operations, all applications would have to be modified, which certainly is not going to happen. - Regarding storage usage: Some projects need lots of disk space just to store some data that is not used all the time, while there are also applications that do many read and write operations. What exactly would we want to measure? Why? How? - Regarding network usage: How to stop a funny guy reattaching to Rosetta@home after every finished workunit, just to have their huge database file downloaded every time again in order to get as many network credit as possible? Just don't count sticky files? If yes, why? - Any number measured on the client side might be cheated. Just saying, "We'll figure out how to make them cheat-resistant", doesn't solve this problem. It might be possible to make it ridiculously hard to manipulate the measurements, but I'm sure that eventually someone will come up with a manipulated BOINC client or find out how the measured numbers are transferred to the server. Therefore, I'd suggest disentangling the "competitive" and the "scientific" credit systems: - Measure FLOPS, memory usage, disk usage, network usage, whatever you like, on per-host level. The results might be shown on the host details page (like it is already the case for some information, e.g. hostname, on_frac, active_frac). Compute the total numbers on project level and show them on the server status or the home page. Don't create any leader boards with it and don't export per-user or per-team data to keep the incentive for cheaters as low as possible. - For competitive reasons, keep track of something that is close to what the CreditGeneralized proposal calls "Project-defined credit". Leave it entirely to the projects in which way they want to grant credits. For most projects, this would likely be just what they already do. For new projects, make it as easy as possible for the administrators to implement their own system. As a starting point, the most easy credit system you can think of (i.e., just counting valid workunits, which is of course unfair in case of workunits with variable lengths... but, to be honest, the current CreditNew "system" also works best for fixed-length workunits) might be set as a standard until the administrators implement something they like better. Of course, this approach only bypasses the first of the "undesirable consequences" mentioned in the CreditGeneralized proposal (i.e., "Credit no longer measures FLOPs", which is not a problem any more because FLOPs can be derived from the separated FLOPS measurements instead). It fixes neither "The [BOINC-wide] competitive balance between volunteers is lost." nor "The competitive balance between projects is lost.". But I think that these goals are unreachable anyway (hard enough to find fair solutions for multiple subprojects of the same project) and they're not even too problematic: - Obviously no problem for single-project competitions. If you are crunching project A instead of project B because you get "more credit" on A, you simply don't get any credit on B and won't win any competition there. - It is already proven that multi-project competitions that work nicely without "cross-project parity" are possible (DC Vault, Formula BOINC, BOINC Pentathlon). More traditional third-party long-term stats may apply any normalization they like, normalization doesn't need to be done by the projects. Of course, they're also free to continue showing meaningless sums (the sum is just like giving 'three fruit' to someone... he won't know if he will be full after eating them before he learns if it's three strawberries or one melon and two oranges). - In real life, there are similar problems for which you can find arbitrarily many 'fair' solutions depending on the point of view. Should the football player really earn lots of money because he can do his job for a shorter period of time and has a higher injury risk than the old people's nurse? Life still goes on. Finally, my suggestion doesn't attack the problem that the "Project-defined credit" might be cheatable. But as it leaves the credit system up to the individual projects, there's neither a general solution nor should that topic be discussed here. However, my suggested as-simple-as-possible standard system is at least resistant to manipulation of benchmarks or computing time.
24) Message boards : The Lounge : BOINC Pentathlon 2016 (Message 68852) Posted 7 Apr 2016 by pschoefer Post: The seventh BOINC Pentathlon is around the corner. As usual, SETI.Germany invites all BOINC teams to find out which team copes best with the challenges of five disciplines at five projects between May 5 and May 19. While there are no major rule changes this year, it is ensured that there will be only one winner after the shared gold medal last year. Furthermore, the Pentathlon pages have undergone an optical refresh, all the rules and later on the stats are there, as well. Many questions are answered in the FAQ. Each team that wants to participate can sign up and enter four project suggestions using this registration form until April 27. Later registration is possible until May 2, but without the possibility of suggesting projects. Therefore, explore the interest within your team and sign up. We're looking forward to your participation in the BOINC Pentathlon! :)
25) Message boards : The Lounge : BOINC Pentathlon 2015 (Message 61438) Posted 7 Apr 2015 by pschoefer Post: Once again, SETI.Germany invites all BOINC teams to the BOINC Pentathlon. For the sixth time, the winner is battled out in five disciplines at five projects between May 5 and May 19. After the introduction of Marathon and Sprint in the last couple of years, there will be a new discipline in this year, again. Details will be announced prior to the beginning of the Pentathlon, for now I can reveal that it will run for at least five days at a CPU project. Each team that wants to participate has to sign up using the registration form at http://www.seti-germany.de/boinc_pentathlon/anmeldung.php until April 27. The teams may suggest one GPU project and three CPU projects, please see this page for details. All information is available on the Pentathlon page at http://www.seti-germany.de/boinc_pentathlon/22_en_Welcome.html, while you can find the answers to many questions in our FAQ. Looking forward to seeing you at the Pentathlon! :)
26) Message boards : The Lounge : BOINC Pentathlon 2014 (Message 53525) Posted 5 Apr 2014 by pschoefer Post: For the fifth time, SETI.Germany invites all BOINC teams to the BOINC Pentathlon, a competition inspired by the Pentathlon in ancient Greece. Between May 5 and May 19, five disciplines at five different BOINC projects are held to find the overall winner. Each team that wants to participate has to sign up using the registration form at http://www.seti-germany.de/boinc_pentathlon/anmeldung.php. Registration is open until April 27. For all but the Marathon discipline, the teams may suggest their favorite project when signing up. A list of possible projects is available at http://www.seti-germany.de/boinc_pentathlon/25_en_Disciplines.html, you may suggest other projects as long as you think they are able to handle the increased load. Note that projects that were part of last year's Pentathlon are excluded for this year. For more information including the full rules, please visit the BOINC Pentathlon page at http://www.seti-germany.de/boinc_pentathlon/22_en_Welcome.html. Please spread the word and gauge the interest within your team. Looking forward to seeing you at the Pentathlon! :)
27) Message boards : News : BOINC 7.0 released to public (Message 43347) Posted 9 Apr 2012 by pschoefer Post: There's also a massive work fetch bug. Was this version tested before releasing it to public?
28) Message boards : BOINC client : massive work fetch bug in 7.0.25 (Message 43342) Posted 9 Apr 2012 by pschoefer Post: Just switched to the new recommended version... and it's definitely nothing I would recommend. ;) My system: i7 980X + ATI HD 5850 + NVIDIA GTX 470 Active projects: - PrimeGrid (only on NVIDIA) - Collatz Conjecture (only on ATI, so ATI is currently idle because of downtime) - WUProp@Home - EDGeS@Home (CPU; Resource Share 0, because I used it as backup project during last PrimeGrid Challenge and did not change it back afterwards) Work buffer settings: <work_buf_min_days>0.0000000</work_buf_min_days> <work_buf_additional_days>0.0100000</work_buf_additional_days> While PG on NVIDIA and WUProp (nci) run nicely, the client keeps requesting EDGeS work for CPU and ATI... of course, it can't get work for ATI there, but it gets one more CPU WU on each request. 320 WUs and counting, about 12 hours of work according to BOINC's own estimation... that's 0.5 days, way more than 0.01 days. At least I did a backup before the update, so I can switch back to 6.12.34 for now.
29) Message boards : BOINC client : Connected Frac = -1.000000 (Message 12087) Posted 15 Aug 2007 by pschoefer Post: I will test another project, as soon as I can access it again, to see if it is a problem with the host and/or PrimeGrid's server-update. Works well with ABC@home, so it is a PrimeGrid problem. I'll ask over there again.
30) Message boards : BOINC client : Connected Frac = -1.000000 (Message 12050) Posted 13 Aug 2007 by pschoefer Post: The connected frac should have nothing to do with anything. It is suposed to measure how often you are connected to the internet, but it has never worked properly on *nix and is not reliable on windows. So as far as I know it is ignored. The other time stats may have a bearing on your problem though. The other time stats are normal, and since this is the only difference to my other hosts, I thought this might be the problem. OK, this host is running WinXP on a RAM Disk, while the other ones are on Win2k, but before last week it worked well... I will test another project, as soon as I can access it again, to see if it is a problem with the host and/or PrimeGrid's server-update.
31) Message boards : BOINC client : Connected Frac = -1.000000 (Message 12046) Posted 13 Aug 2007 by pschoefer Post: Hi all! Last week my C2D, which is running with BOINCpe, started to get only one WU per request, although much more work is requested and I did not change the preferences. There are two projects attached: Pirates@Home and PrimeGrid. Here's a part from the logfile: 06.08.2007 10:03:48\|PrimeGrid\|Sending scheduler request: To fetch work 06.08.2007 10:03:48\|PrimeGrid\|Requesting 325679 seconds of new work 06.08.2007 10:03:53\|PrimeGrid\|Scheduler RPC succeeded [server version 511] 06.08.2007 10:03:53\|PrimeGrid\|Deferring communication for 7 sec 06.08.2007 10:03:53\|PrimeGrid\|Reason: requested by project 06.08.2007 10:03:55\|PrimeGrid\|[file_xfer] Started download of file llrTPS_7055979 06.08.2007 10:03:56\|PrimeGrid\|[file_xfer] Finished download of file llrTPS_7055979 06.08.2007 10:03:56\|PrimeGrid\|[file_xfer] Throughput 425 bytes/sec 06.08.2007 10:04:03\|PrimeGrid\|Sending scheduler request: To fetch work 06.08.2007 10:04:03\|PrimeGrid\|Requesting 325041 seconds of new work 06.08.2007 10:04:08\|PrimeGrid\|Scheduler RPC succeeded [server version 511] 06.08.2007 10:04:08\|PrimeGrid\|Deferring communication for 7 sec 06.08.2007 10:04:08\|PrimeGrid\|Reason: requested by project 06.08.2007 10:04:10\|PrimeGrid\|[file_xfer] Started download of file llrTPS_7054620 06.08.2007 10:04:11\|PrimeGrid\|[file_xfer] Finished download of file llrTPS_7054620 06.08.2007 10:04:11\|PrimeGrid\|[file_xfer] Throughput 512 bytes/sec ...and so on... At that time I was using BOINC 5.8.15, I updated to 5.10.13 at first, now 5.10.18, but still the same behaviour (my other host's are running fine and getting lots of PG-WUs per request). I also tried different prefs, but nothing changed. Today I discovered <connected_frac>-1.000000</connected_frac> in the client_state.xml. Because this is the only difference form my other host's (there it is 0), I think that this is the reason. I tried to manually set it to different values from 0 to 1 (client closed before that), but after restarting the client, it was -1 again.
32) Message boards : BOINC Manager : Where have all the messages gone...? (Message 11884) Posted 30 Jul 2007 by pschoefer Post: After reading some old BOINC logs of mine, I find some useful messages missing in newer versions of BOINC. Since 5.8.x we have two times "starting task" (I still don't see any sense in that), "resuming task", "restarting task" and "computation finished". But while switching from one task to another one, there used to be the following message: 2006-09-12 15:52:03 [SETI@home Beta Test] Pausing task 01my06aa.17871.305.972158.3.126_0 (left in memory) Next examples: 2006-10-18 09:44:06 [---] Using earliest-deadline-first scheduling because computer is overcommitted. 2006-10-18 09:44:06 [---] Suspending work fetch because computer is overcommitted. 2006-10-18 12:46:24 [---] Resuming round-robin CPU scheduling. 2006-11-25 18:03:15 [---] Allowing work fetch again. OK, the EDF scheduling has become more complicated with 5.8.x, but it would be great, if there was at least a message when work fetch is suspended/allowed. And last but not least (and -unfortunately- NOT missing ;)) something about the error messages. I think it was in some of the 5.8 versions... Error messages where easy to see, as they were displayed in red. Now you might not see some error messages, because all messages are black. :\|
33) Message boards : The Lounge : Really, who likes the new BOINC logo? (Message 11840) Posted 28 Jul 2007 by pschoefer Post: At first sight I did not like the logo, but now I start loving it. :D The old logo was just some kind of ink blot with the letters BOINC on it. Now you can interprete those blue arms as seperated things (e.g. computers), which unify into one whole thing (i.e. the orange circle). That's exactly, what BOINC is! :)
34) Message boards : BOINC Manager : Problems with 5.8.15 (Message 9618) Posted 16 Apr 2007 by pschoefer Post: If you click Retry or Update project or similar, it enables network again for 5 minutes. I'm tired of asking for that stupid "feature" to be removed. It's really a useless feature that should be removed. I had the following problem with it: After all Workunits were crunched I set all projects on "no new tasks", enabled network communication, reported the WUs and disabled network again. Then I allowed the projects to fetch work again, and lots of WUs were downloaded, although network communication was DISABLED.
35) Message boards : BOINC Manager : Problems with 5.8.15 (Message 9371) Posted 5 Apr 2007 by pschoefer Post: The problem with two instances of Internet Explorer 6 is still there in BOINC 5.8.16 :( If you look back a couple posts in the thread, it's not a problem with BOINC. It's a problem with the version of libCurl that is used. The libCurl programmers have been informed. Yes, of course. But it could have been that the libCurl-problem was fixed and the new solution was built in in BOINC 5.8.16 ... btw: Is there any overview of the changes between the 5.8.x releases, like the one of 5.4.x?
36) Message boards : BOINC Manager : Problems with 5.8.15 (Message 9360) Posted 5 Apr 2007 by pschoefer Post: The problem with two instances of Internet Explorer 6 is still there in BOINC 5.8.16 :(
37) Message boards : BOINC client : Trouble with router (Message 9060) Posted 24 Mar 2007 by pschoefer Post: I don't know if you can believe it, but I could not at the first sight... I made a firmware update (manually, because the router didn't find the new version automatically), and it works now. Thanks for your support, although I finally solved the problem on my own.
38) Message boards : BOINC Manager : Trojan boinc installation by rogue member (Message 9016) Posted 23 Mar 2007 by pschoefer Post: Anyone else find David Braun at Predictor@Home's response to this matter puzzling? I have to say I did. We reopened the discussion. It cannot be that the oldest BOINC project supports abusing!
39) Message boards : BOINC Manager : graphically blind (Message 8987) Posted 22 Mar 2007 by pschoefer Post: hi I have been running boinc w/o being able to display any graphics since I started used my new IBM/T60 laptop. I am now using 5.8.15 but it was the same issue for 5.8.11 and 5.8.16. I have a single user install, when I upgrade, I first remove (via add/remove programs) and a couple times I also went as far as renaming the boinc folder. note that I have been a Seti then boinc user for a couple years now so I am not a complete idiot with this. I was running fine on my previous laptop and the ONLY thing which has changed is well, just that. the Laptop. I have the latest LENOVO/ATI display driver and it does support openGL. what else ? it's frustrating to crunch the numbers in a blank screen. sometimes, I have the boinc logo bouncing around with the project(s) percentage but nothing else. any idea ? thank you Are you not able to start the graphics via the BOINC manager, too, or is only the screensaver not working? Which projects are you running? To give you a piece of advice: Forget about the graphics, they're just eating performance.
40) Message boards : BOINC client : Trouble with router (Message 8837) Posted 17 Mar 2007 by pschoefer Post: Remember this is all outgoing. Are there any ports needed for incoming connections? I spoke to an expert from Netgear today at Cebit, and he could only imagine that BOINC needed some ports forwarded.

Previous 20 · Next 20

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.