1) Message boards : Number crunching : The new look bugs (Message 17679)
Posted 2 Aug 2007 by Philip Martin Kryder
Post:
OK Login problem fixed we hope, was a silly problem and it is now fixed.

Also you should be able to subscribe to threads, get your account key sent to you or anything else that sends an email.

With the width thing this has been mentioned once or twice and I fixed it a while ago and cannot see any scroll bars in IE, FF, Safari, Opera, Camino on Mac and Win at any resolution, please do a hard refresh (Ctrl + F5) to make sure you have the newest version of the CSS


I still see scroll bars.
Will send you a screen shot via HTML email.

Is there any "last updated info" to send you to help you debug it?
Phil
2) Message boards : Number crunching : Please note: this project rarely has work (Message 17090)
Posted 25 Jun 2007 by Philip Martin Kryder
Post:
Yes we are still working on the transition here but if there were work units to be done they would be up and you would be crunching them. The users who generate the jobs are working on a bunch more but they are not ready yet.


Thanks, but...
It would be nice to see the 1.6.2007 home page updated more often.


You may understand this, but just in case you or others don't, 1.6.2007 in the context of how dates are handled in UK / Europe means June 1, 2007, not January 6, 2007.


does anyone use 2007/06/01?
3) Message boards : Number crunching : Trojan used by dishonest BOINC cruncher (Message 16383)
Posted 21 Feb 2007 by Philip Martin Kryder
Post:
Is this why there was such a massive change in BOINC rankings today?
4) Message boards : Number crunching : SOME greedy users (Message 16074)
Posted 8 Jan 2007 by Philip Martin Kryder
Post:
Is it still the case that LHC does not currently grant credits for work done?

There was a rumor to that effect.
Phil
5) Message boards : Number crunching : Can anyone explain ...... (Message 15618)
Posted 22 Nov 2006 by Philip Martin Kryder
Post:

And a proper operating system would not let tasks find out about other tasks either, in my opinion.


Absolutely.


6) Message boards : Number crunching : Can anyone explain ...... (Message 15586)
Posted 20 Nov 2006 by Philip Martin Kryder
Post:
....

EDIT: What could be a problem is that the quota is not reduced for an invalid result, so these rogue machines can get through up to 500 WU every day, without being quota chopped the way they would be if the results were returned as "Error".

....


Is there not also a possible problem that the max errors per work unit could be reached, thereby invalidating all results for that WU.

I suppose that it is a very unlikely problem - given high number of errors allowed relative to the quorum size.

max # of error/total/success results 10, 20, 10
7) Message boards : Number crunching : Projects to mix with LHC (Message 15469)
Posted 16 Nov 2006 by Philip Martin Kryder
Post:

....
Philip, as for the request about a table of which project would go well with what cpu, one of the things to remember is it's not all about the cpu.



I hit a hard ram issue with Worldgrid cancer and a disk issue with CPDN (it was temporary). There's also the fact that seti is starting to put up some large variable sized workunits out there.


Also in regards to workunit deadlines, do you keep the machine running 24/7 or turn it on every couple of days. How many projects and and how do you want to share the time on the cpu?


I know your question is a about a single processor celeron, but what about the multi cpu machine (I'm using 4 work pcs that have HT and boinc counts these as 2 cpu machines).
....
William


I run my single machine 24/7 with boinc engaged 100%.
How is that relevant?
Even if it affects the table somewhat, the table would still be a useful indicator of which machine.

Yes, memory, disk etc will affect the table, but they will only broaden the gaussian distribution about the mean.
We should still be able to rank projects by processor (or processor by project).

Multi core and multi chip machines should have their own row or column in the table.




8) Message boards : Number crunching : Projects to mix with LHC (Message 15453)
Posted 14 Nov 2006 by Philip Martin Kryder
Post:
On one of the other boards I once asked which projects are best suited to which processors.

Does anyone have any kind of data on that?

Some CPUs seem to do better with certain workloads.


It may be that my 2.53 celeron is better at Rosetta than LHC or vice versa.

It would be nice if BOINC would look through the data on the results on all the different machines and give a project ranking for effectiveness by each type of CPU.

Or, simply allow us to click on a link from our cpu to a page listing all the available projects ranked in order by the relative effectiveness of the particular CPU.
9) Message boards : Number crunching : Did everyone get work 02 Nov UTC? (Message 15355)
Posted 4 Nov 2006 by Philip Martin Kryder
Post:
....
John's advice is to give LHC a double resource share compared to your typical other projects....



So, resource share is "catered for" in the assumptions underlying the formula.
And, also explains where the N+1 comes from in the denominator....
10) Message boards : Number crunching : Did everyone get work 02 Nov UTC? (Message 15349)
Posted 4 Nov 2006 by Philip Martin Kryder
Post:
....
(1) set the cache to 2 hours. (1 day/12 hours = 0.0833333333333333333333333333333333334) It fits.
....


Why 2 hours instead of say 70 minutes? (.05)
11) Message boards : Number crunching : Did everyone get work 02 Nov UTC? (Message 15348)
Posted 4 Nov 2006 by Philip Martin Kryder
Post:
....
Hope that helps. I appreciate the level of detail in your questions, here and in other threads, which indicate that you are really engaging with the points made. R~~


Well thank you for the kind words and the effort to explain.
A lot to contemplate.

Is it correct that Resource share is not considered at all in your formulas?


I have several projects.
One of them, SZTAKI seems not well behaved.
Sometimes the WUs don't complete in anywhere near the estimated time.
Sometimes they seem to not complete at all.
So I suspend it "a lot" and run it every few weeks to see if it is doing any better.



12) Message boards : Number crunching : Did everyone get work 02 Nov UTC? (Message 15340)
Posted 3 Nov 2006 by Philip Martin Kryder
Post:
[quote]....
John Keck advocates that wih N projects the max cache to keep all the projects hungry at all times is 0.4 * Deadline / N; I suggest a somewhat larger setting of Deadline / (N+2).
..../quote]

Can you explain why these magic numbers were chosen?

And what the difference between your suggestion and his is designed to optimize?

Also, where does one find the value of Deadline?

And finally, is N the number of currently ACTIVE (not suspended) projects or total projects?
13) Message boards : Number crunching : Did everyone get work 02 Nov UTC? (Message 15327)
Posted 3 Nov 2006 by Philip Martin Kryder
Post:
....
So, apart from those two reasons, did anyone else miss out this time?

River~~


Yup - my cache was full with other projects....
no work for me this time.



14) Message boards : Number crunching : When you see work is around ... (Message 15281)
Posted 1 Nov 2006 by Philip Martin Kryder
Post:
Hi Ingleside,

thanks for the useful injection of fact.

#1, time between successful send of work and the next, is clearly too low. At the smallest this should be about the time it takes to crunch a short task on a fast box, and on a project with sparse work this could afford to be longer (as all clients, fast and slow, should have other projects' work anyway if they are on LHC).

R~~


Is this based on your goal of distributing work as widely as possible among as many different machines as possible?

15) Message boards : Number crunching : When you see work is around ... (Message 15257)
Posted 31 Oct 2006 by Philip Martin Kryder
Post:
Sorry for the multiple posting everyone.

I have just discovered that I was posting onto an offline copy of the forum under the impression that my first three attmepts had not posted successfully.

Anyway Mondays long outage has finally convinced me that this is not a human issue, nor an issue of clients set not to crunch during working hours. So that leaves some kind of server problem, or a more general client problem (perhaps related to the way clients can get back in for a second helping inside a minute).

River~~


or, it could be that the admins are simply limiting connections to match capacity...
16) Message boards : Number crunching : When you see work is around ... (Message 15235)
Posted 30 Oct 2006 by Philip Martin Kryder
Post:
...Absolutely so. Error 1040 comes from mySQL and if I remember rightly the number of connections is set in the MySQL config file.

But my point is that if they doubled, or even multiplied the limit by 10, or x100, the rush for work might well still overwhelm it.
....


Why should they (the admins) INCREASE the number of connections?

If, as you assert, the server is failing due to overload, then reducing load by throttling the number of concurrent connections is "the right thing to do."

The clients will pick up the work as they are able to connect.



17) Message boards : Number crunching : When you see work is around ... (Message 15213)
Posted 28 Oct 2006 by Philip Martin Kryder
Post:
...

They should still be on a 4hr backoff.
....
R~~


Some of us here in the Americas work as much as - well 8 hours in a day - some even more;-)
so even with a 4 hour back off, they might all be ready to ask for work at the same time...

It looks like the admins are limiting concurrent connections.
Isn't that what the 1040 error implies?

18) Message boards : Number crunching : When you see work is around ... (Message 15212)
Posted 28 Oct 2006 by Philip Martin Kryder
Post:
....
But if you -- any reader -- are tempted to do this, please at least keep rule 2 and 3 (see my original post).

River~~


Is English your first language?

The use of the word "rule" in this context of volunteer computing, is often offensive to some.

Perhaps you mean "suggestion."
19) Message boards : Number crunching : When you see work is around ... (Message 15195)
Posted 27 Oct 2006 by Philip Martin Kryder
Post:
....
5 (fact): the backoff algorithm contains a random element specifically to ensure that if all clients have been left running for several days without manual intervention, their db accesses will be spread evenly around the clock
....

Is it possible that many machines are "at work" machines and that they are NOT actively seeking work during the day (because the are set to not seek work when they are actively being used in their business function).

Then, when their business user goes home, they begin to actively seek BOINC work?
20) Message boards : Number crunching : When you see work is around ... (Message 15194)
Posted 27 Oct 2006 by Philip Martin Kryder
Post:
....
7 (observation / rebuttal) These boards contain a count of the numbers of views of these threads. These do not jump sufficiently over a 24hr period for it to be forum access killing the db
....


Might it be the case that if server capacity is the limiting factor, that it automatically limits the total "count of the number of views?"

If any attempt is made to have more views than the server has capacity, then that in itself would prevent the counts from jumping.
Are we not masking the "peak" concurrent loads when we look at a 24 hour accumulation?

Without continuous graphs of the number of concurrent connections, we can't know whether the counts are limited by capacity limitations or by the lack of demand for connections.
Or can we?
If so, how?


Next 20


©2023 CERN