Posts by John McLeod VII

1) Message boards : Number crunching : Team Points STOLEN!!!!! Over 6 Million Points! (Message 54508)
Posted 15 Jul 2008 by John McLeod VII
Post:
First of all there were some versions of the server software that did not send an email to the founder if there was a team transfer initiated if the founder had turned off emails.

Second, one of the upgrades turned off all emails from the projects.

A later version of the server instantiated emails for founder change requests, but even if this was installed after the founder request was made, there would not be an email made as it is only sent when the founder change request was made.
2) Message boards : Number crunching : BOINC thread: Questions re scheduler & v5.8.x (Message 37752)
Posted 13 Mar 2007 by John McLeod VII
Post:
You are correct a better way to do this may be needed for projects with multiple classes of tasks. The other way should still be good for projects where there is less variation in task complexity. I sent an email to the developer's list pointing to this thread.

It might be a good idea to have a where clause on the query to find work that includes such things as the time between connections, RAM size, and HD space allowed. However, that is not exactly my area of expertise.
3) Message boards : Number crunching : Increase in New Users (Message 30079)
Posted 27 Oct 2006 by John McLeod VII
Post:
Just a fun thought, what if Seti finds extraterrestrial life and its goal is achieved? (Finds over remaining out of work because it's only natural that other life forms exists up or down there)

Where would all those users divert their computing power? Oh my... Yes...



No, because most the members would not even notice they had ;-) Also there are always more ET type things to find.

Then we would get to start trying to decode the signals...
4) Message boards : Number crunching : Excessive long term debt (Message 29728)
Posted 21 Oct 2006 by John McLeod VII
Post:
Tried to reset the debt to 20, but it bumped right up to 3.5 million when I started BOINC again.

Try setting it to about the median of the other projects (which should be moderately large negative numbers.

I have seen the jump before, but I cannot seem to figure out where it could be going wrong.
5) Message boards : Number crunching : Running World Community Grid and Rosetta! (Message 25002)
Posted 26 Aug 2006 by John McLeod VII
Post:
I,m running Fightaids@Home, which seems to be running as a independent project program that I had downloaded from the world community Grid site.I'ts running in the background along with Rosetta. There does not seem to be a noticable slow down on my processors.If I'm loosing rosetta credits so be it.

This is quite likely the trouble. UD and BOINC probably run the science application at slightly different proirity levels. If UD is running at a slightly higher priority level, then it will get ALL of the spare CPU time. A suggestion is to attach to WCG through BOINC and select FA@H as the project you wish to run. This will allow BOINC to do the control. To do this, you will have to detach from the UD version of FA@H.
6) Message boards : Number crunching : BOINC setup in corporate environment (Message 24894)
Posted 25 Aug 2006 by John McLeod VII
Post:
meeting scheduled for thursday next week. I'll be away for the weekend but I'll put together a doc that I'll take with me with the proposal etc.

Has anyone got any firm details on the AD install and connection process? I assume that the sensible way to run it would be to run it under it's own specific account with minimal priveledges? What read-only and write access to other folders would BOINC need - e.g. Windows folder or just its own? I might be going overboard but I'd rather be able to lay any fears to rest on the spot!

Network utilisation I think i'm on top of - need to check that info about proxies in the latest versions - thanks FC.

Create a special BOINC account. Run as a service.

The special BOINC account needs read/write access to the BOINC directory (where ever you put it) and about nothing else. It needs to read the location where the windows core executables reside, but it does not need write access here.

BOINC installs fairly neatly as an image. The only gotcha is that if you install as a service, you have to take the registry along as well. Joining a project during install is as simple as copying the correct account_*.xml file into the BOINC directory, stopping BOINC (if already started) and restarting. The way I would create the image is to install BOINC as a service, stop BOINC, copy the account_*.xml files needed. This is the image. You will also need some portion of the registry so that it is registered as a service (I have not looked into that).

Good luck.
7) Message boards : Number crunching : Silly Newbie Tricks - Suspending a work unit (Message 24320)
Posted 23 Aug 2006 by John McLeod VII
Post:
Yes, let the rest of the debt system etc. work out the details down the road. My understanding is it waits until a checkpoint is reached. So, may not be a completed model or completed WU... but means that no work is lost, even if you aren't keeping in memory or turn off the machine!

Simple way to extract maybe 5% more useful work out of the existing machines. Depends up often you end BOINC or were losing work that hadn't been checkpointed.

If anyone has a link to the details of this upcoming BOINC feature, please post a link.

The 5.5 CPU scheduler waits for the next checkpoint later than 10 seconds before the check (there is some asynchronous code, and several seconds can disappear if the host is slow and busy) unless there is a task the needs extra CPU time to complete on time. This may suspend a task just a few seconds before it is complete if there is a checkpoint there, but normally a checkpoint will only happen once every few minutes. Problems that had to be dealt with: tasks that run for days without checkpointing (there are projects that do this), projects that lie about how much work is left (one project I remember had tasks that had a 100 hours or so of CPU time after 100% complete was reached on some tasks).

5.5.13 also implements work fetch that does not fetch a full queue from each project, and keeps the queue full even if there is a risk of late work. The user has indicated that the CPU would probably be idle if there was not enough work to keep it busy.
8) Message boards : Number crunching : Multiple project processing... (Message 24319)
Posted 22 Aug 2006 by John McLeod VII
Post:
Also resource share dictates how much of your CPU time to give to each project over the long term. Example. Project A share 50 and Project B share 100. Project A will have the CPU 1/3 of the time and Project B will have the CPU 2/3 of the time. If possible, it will be 2 hours of B and 1 of A (depending on the switch time). If one of the projects has anticipated deadline trouble, that project will get extra CPU time now, but will not be allowed to download new work for some time in order to let the other project catch up on its CPU time.



Thats pretty cool, I didn't know that. I just set one of my rigs onto 3 smaller projects to run for probably a year without me being able to touch them.

Thank you.

I was the developer that did most of the work on the current CPU scheduler.


Cool. Can you confirm that the 5.5.x versions switch only after a checkpoint and try to finish a WU before switching if it is near completion?

1) There is no attempt made to wait for a task to finish other than waiting for the next checkpoint. So, if things are running normally, and there is no checkpoint between the re-schedule and the end of the task, it does wait.

2) Tasks normally wait for the first checkpoint after their first allotted time slice since a start from paused. The exception to waiting is if a project requires extra CPU time, in which case it is more important to get started on that task than to wait for a checkpoint that might never come. The second exception is if the task has checkpointed within the last 10 seconds (seconds, not minutes).

Yes, this is in the later 5.5 versions starting, around 5.5.7 I believe. However, please note that 5.5 builds are for Alpha testing, and carry a higher risk of severe problems (for example, the current build will not install on Win 9X).
9) Message boards : Number crunching : Multiple project processing... (Message 24197)
Posted 21 Aug 2006 by John McLeod VII
Post:
Well phooy. I guess I'll just crunch Rossetta by itself then.

Always a choice.
10) Message boards : Number crunching : Silly Newbie Tricks - Suspending a work unit (Message 24196)
Posted 21 Aug 2006 by John McLeod VII
Post:
With BOINC 4.x I could suspend the project then exit BOINC and a checkpoint would be forced so that on restart the current model would begin where it left off. On BOINC 5.4.9 I've noticed that this doesn't always work. Seems to be a flakey bug in it.

I don't think you are correct on that. BOINC has no way to force applications to perform a checkpoint. Checkpointing (and the lack thereof) has been a problem for many BOINC projects.
[/quote]

This is correct. Whenever a project application wishes to checkpoint it asks the BOINC client if it is time yet. If it is time for a checkpoint, the project checkpoints, and if it is not, the project is not supposed to checkpoing. There are a couple of projects that ignore this CPDN checkpoints once every 5 to 60 minutes ignoring the checkpoint timer, and it is common for the first cut of checkpointing in Alpha level projects to miss this detail. The most recent one of these checkpointed about 5 times per second on a fast machine.
11) Message boards : Number crunching : A Challenge (Message 24193)
Posted 21 Aug 2006 by John McLeod VII
Post:
Luckily, it looks like the cross project parity is a non-issue. The new system grants what appears to be in the range of parity with others out there. Since no work needs to be done by the project to modify the new system, I don't see what is left to discuss on this topic.

http://boinc.bakerlab.org/rosetta/forum_thread.php?id=2164#23996

Good to hear.
12) Message boards : Number crunching : A Challenge (Message 24176)
Posted 21 Aug 2006 by John McLeod VII
Post:
I was here back in the beginning, where it actually was a challenge to crunch Rosetta WU's. There was the 1% bug, the stay-in-memory-while-preempted bug, the freeze bug, other kind of bugs, and we had to tweak our settings just to be able to return valid results. Numerous was the times I had to exit my BOINC manager and start it again, sometimes even reboot my computer, in my attempts to "jumpstart" a frozen WU. It became a little easier when the graphics were developed (I still remember my first graphic WU. I had the graphics open all the time and I actually sat and looked at it from start to upload), as we then could see if a WU was alive or not, so we didn't have to abort a WU which seemed stuck. I remember the "Christmass bug", the flawed WU's that was sent out just before the devs left for their seasons holiday, so they were sent out all 11 times, as there was no devs there to kill them.

If anybody here dares to question my dedication to this project based on my RAC, I have only two words to say to that person, and that is not "Merry Christmas"!


I was also here at the very beginning. While my RAC may not be as large as other peoples, I also have stuch through the tough times.
13) Message boards : Number crunching : A Challenge (Message 24172)
Posted 21 Aug 2006 by John McLeod VII
Post:
The credit aspects as well as the science aspects of the application has to be closed.


I agree with that, but it's just a case of moving any benchmark/credit system out of the open BOINC app and into the closed science one. (Maybe we're getting confused over what we refer to as 'BOINC'?) There is no reason why a system using BOINC can't be made secure - as you say, it just requires any credit calculation to be removed from the open source bit (ok- there's a bit more to it than that as the current thread at Ralph is discussing, but in principal it's as stated).

cheers
Danny


But Danny: The Boinc Purits dont want that. When I proposed that very simple solution all I got was ..."BOINC is open source, end of discussion"

And even the science can be compromised. It was claimed here by some of the Boinc Purists that in SETI the science was tampered with. I have to take their word as valid or were they lying?

BTW I am going to be away from the computer for a while . Jury Duty Summons . So If I dont answer you it is not becase im not interested in engaging in a dialogu with you. It is becasue there is a good chance Toay I will be sequestered. Okes I dont want any clebrations on that :) ( Yes the rablerouser has a sense of humor)


The claim was that SETI CLASSIC science was compromised, not SETI BOINC science. Anyone that attempts to compromise SETI BOINC science gets 0 credits for his work.
14) Message boards : Number crunching : Simple boinc installer (Message 23980)
Posted 21 Aug 2006 by John McLeod VII
Post:
Some (most?) laptops are protected against overheating, but not all.

The simplest suggestion is to use a cheap cookie cooling rack to raise the laptop so that there is airflow underneath it.
15) Message boards : Number crunching : New Crediting system: questions (Message 23979)
Posted 21 Aug 2006 by John McLeod VII
Post:
It's known that a given simulation within a WU will vary. However, this variability will be both within a single WU and all the others of the same type. By definition, the credits will be based on the average of these results. Since it's not possible to know in advance how long each decoy will take, it should average out.

The other side of it is one WU type may grant slightly more or less credit than others. They're trying to keep that to a minimum, but as they've posted, they have tools to find people who take advantage of the system with this method.

Once the average credit/decoy is calculated, it's entirely dependant on how fast a given machine is. If Intel cpus can do more science in an hour due to features of its hardware, it will end up getting more credits (and vice-versa).

I know the results for any decoy will be an average of the decoys for that entire workunit type. But this is exactly what bothers me. Although the results will even out across the workunit they won't even out on the same machine. Some people will generate less decoys than others for the same workunit in the same amount of time possibly based only on their random number. I have seen this on my own machine after doing the same workunit downloaded multiple times. Users who have the bad luck of getting these long decoys will think it is unfair that someone with the same machine gets more credit for the same workunit for the same amount of time. And if I downloaded a whole 6 workunits at once and they end up being the same workunit and it grants a bit less credit than other workunits I would be forced to either be happy with getting less credit for all of them or to dump all of them. These are the two main issues I want resolved and I don't see that happening with the current system.

This I did not know.

Is there any interest in FLOPs counting?
16) Message boards : Number crunching : Another solution for the credit issue that hasn't been mentioned. (Message 23921)
Posted 20 Aug 2006 by John McLeod VII
Post:
John did you read my post at all ? WCG through Boinc ?

Yes, and in WCG as in most BOINC projects, credit is not granted immediately. Instead credit is granted when a quorum is reached, so there is some variation in how much credit is granted each day. If you mean the amount of credit granted there vs the amount granted here, I have not looked to see if you are using "optimized" clients - and I am not going to look at any specific persons computers here - mostly so that my statements are not about any particular user or group.
17) Message boards : Number crunching : Cross project ID (Message 23920)
Posted 20 Aug 2006 by John McLeod VII
Post:
Thanks...I should have figured that you would be the one to answer the question!

Assuming that the project will be put on one computer how long does it take to update?

Thanks
citroja

I am assuming that you mean all of the projects on one computer.

I believe that the answer is 2 connections to each project that will change CPID (with the more recent clients 4.2 and later? that is only the new project - with older clients, it can be every project except the new one.) This is normally pretty quick, but can be enormous if a project is off line for an extended period (4 months is the record so far for an otherwise active project).

+

The time for the project to update the stats. Usually less than 24 hours, but can be much longer.

+

The time for the stats sites to get and publish the data (< 24 hours).
18) Message boards : Number crunching : Multiple project processing... (Message 23918)
Posted 20 Aug 2006 by John McLeod VII
Post:
Also resource share dictates how much of your CPU time to give to each project over the long term. Example. Project A share 50 and Project B share 100. Project A will have the CPU 1/3 of the time and Project B will have the CPU 2/3 of the time. If possible, it will be 2 hours of B and 1 of A (depending on the switch time). If one of the projects has anticipated deadline trouble, that project will get extra CPU time now, but will not be allowed to download new work for some time in order to let the other project catch up on its CPU time.



Thats pretty cool, I didn't know that. I just set one of my rigs onto 3 smaller projects to run for probably a year without me being able to touch them.

Thank you.

I was the developer that did most of the work on the current CPU scheduler.
19) Message boards : Number crunching : Another solution for the credit issue that hasn't been mentioned. (Message 23916)
Posted 20 Aug 2006 by John McLeod VII
Post:

This solution bears directly on the cross BOINC comparison issue. The credit per for a given computer should be the same no matter which BOINC project is being worked on.


Cross Boinc Comparison on one side vs Intra Project Fairness on the other.

Sorry John: Intra Project Fairness wins in my book all the time.

They can both be accomplished at the same time. There is nothing in intra project fairness that indicates that cross project fairness be thrown out the window. Intra project means (to me at least) that the same amount of work for the project earns the same amount of credit no matter what machine it was run on. Cross project fairness just takes the same principle across the BOINC projects.

To those that say that all sorts of other projects that do not run on BOINC have different credits and methods of granting credit. This is a true statement, and has absolutely no bearing on the discussion. Non BOINC projects are not part of the discussion at all.
20) Message boards : Number crunching : Another solution for the credit issue that hasn't been mentioned. (Message 23887)
Posted 20 Aug 2006 by John McLeod VII
Post:
I dont have time to read every message everywhere, but I havn't seen this recommended yet. Why not go with the system of measuring credit done based on cpu and performance as planned, but instead of lowering scores, set the benchmarks up to be equal to what the optimized clients do now.

As far as I know, it was never against the rules to be using an optimized client, so instead of punishing the people who have, instead use those levels to set the standard of what a WU is worth, and take the data back to february to RAISE everyone up to an equal level, instead of lowering everyone to an equal level.

The only problem left here is that credits will be worth more then other boinc projects, but this is an independant project that can measure its work however it wants. Statistic sites will just have to skew results as they see fit.

I hope this makes sense, and really wouldn't piss people off or have issues with a second data column or separate scoring.


Edit - I've read that credits wont be backdated whatsoever, but this idea could still apply towards future credits. Multiproject parity isn't as important as equality within a project.

This solution bears directly on the cross BOINC comparison issue. The credit per for a given computer should be the same no matter which BOINC project is being worked on.


Next 20



©2022 University of Washington
https://www.bakerlab.org