1) Message boards : News : Server Intervention 10-Feb-2014 (Message 27131)
Posted 10 Feb 2015 by Antjest
Looks like similar problem happened to already uploded files which couldn't validate and got ignored when additional result is returned:


and some that couldn't validate:

2) Message boards : Number crunching : Daily quota (Message 23671)
Posted 8 Nov 2011 by Antjest

I am re-opening this thread as today my computer (dual core) reach the limit of 80/day/core since there were a lot of very short WUs.

This limit has nothing to do with invalid results and it was set because of certain users nagging in the past that they can not get any WUs as others process them so fast. If I recall corectly limit then was 10 or 20/day.

Since on one computer can only be one WU per core at the same time this limit of WU/day can be lifted and set the limit for invalid results (if it's not already in place) for faster project processing.
Otherwise some computers will be idle or work for backup project (like mine for the next 14+ hrs) because of this unnecessary limit, while there will still be WU available.
( ATM there are no WUs, except resends )
3) Message boards : Number crunching : Tasks v530.09 crashing (Message 23453)
Posted 11 Oct 2011 by Antjest
530.10 is much less efficient than 530.09 on my core2quad.
It's 15-33% slower and lower core temps also indicates less power is used by proc.

I had no problems with 530.09 windows xp on my two o/c computers (so far only one invalid and that was my fault with some manual intervention in boinc manager).

Perhaps other guys o/c too much or have some other hardware problems with computer.
4) Message boards : Number crunching : credits for WU's of latest batch? (Message 15886)
Posted 24 Dec 2006 by Antjest

You partly answered yourself.

The answer to why they are invalid, prolly is that there is something wrong with your rig, either too much overclock or too much dust and proc or RAM or mobo became unstable due to overheat.

5) Message boards : Number crunching : information should not be that difficult (Message 9750)
Posted 31 Aug 2005 by Antjest

Issuing each unit five times for a quorum of three seems excessive. Reducing the number of issued units from five to four would increase available computing power by 20% and speed up returns accordingly. I wonder why they haven't done this...


I agree with this one.
And with five days deadline it can be send out quick enough to additional client if needed.
Reducing quorum to two might do the trick as well as results in LHC must be exactly the same.

I believe this is the next step in achieving higher throughput rate at LHC.

6) Message boards : Number crunching : information should not be that difficult (Message 9747)
Posted 31 Aug 2005 by Antjest
For some reason, they have gone to an insanely short deadline.

People complained bitterly at Einstein because of this....

I know I would never stay at Einstein with the short deadlines, because I want a large cache - more than a couple of days.


This are perfect example of statements made by WU collectors.

I don't understand why you need so many results on your puter when they are stored on server. And when they run dry on one project the others will get more attention. That is why BOINC was made.

And for those who want to squeze a little more credit when everyone run dry.
I get a lot of spam about different enlargements. Perhaps you should try one to boost your ego. Boinc credit obviously can't do the job anymore.

7) Message boards : Number crunching : Pending Credit (Message 9650)
Posted 25 Aug 2005 by Antjest
<blockquote>I have a number of results pending where 3 or 4 other computers have been granted credit.

Mine show as pending with Validate State - Initial.

eg: Work Unit nos: 1817001, 1803443, 1862214, 1866442.

Any Ideas.</blockquote>

You probably have too long queue and in time you process your results the quorum has been long reached and file deleter cleared them from database. It has been known that file deleter does this.
So you never gonna see credit for those results.

I suggest you reduce your queue to have no more results for LHC that you can process in a day or two with your puter.

8) Message boards : Number crunching : Even shorter deadlines? (Message 9557)
Posted 22 Aug 2005 by Antjest

Mostly I do just leave BOINC to get on with it. The theory is good, but with computers actually missing deadlines it seems that the practice isn't quite there yet.</blockquote>

Then my guess is, you are still using too large queue for this computer.

And as a long time dial-up user I see no difference in connecting once a week for 35mins or every day for 5mins. You do check your e-mail daily ?

Except for the holidays. But then your computer can have one too :)
9) Message boards : Number crunching : only 10 k WU's left (Message 9216)
Posted 8 Aug 2005 by Antjest
> Would like to say in all due respect you are seemingly extremist in your
> view. 1st off if you care about the "science" did you ever think that maybe a
> 3 quorum also gives the scientists more accuracy ( or less sometimes) making
> them question the validity of certain results? Also the 2 results that may
> come in after the quorum might shed more light on a wu's problem.

Somebody had to go on opposite side of the majority on Boinc projects boards.
Alex explained very well why so many CC had to be made. Many features only for queing/deadline although I respect the one who are doing it. The only feature I find usefull in 4.19+ version are abort WU and no new work. Deadline problems can easily be adjusted with "connect to" (by user or by admins).
And in case of one project goes dark, there are others (purpose of Boinc).

In LHC only 2 results can be used for quorum, because results must be equal (not just close enough as in SETI) or don't validate. It was so at the begining and due to 0 credit problem it was changed to quorum 3 / send 5 .

>(tough to adjust work que now with 2 out of 4 on 4.72)It is downloading more >work than I want. (3 day) Give it time ...seems to be working here....have >already adjusted down to a whole 9 days of work (for Colt) hope to refine it >to 1 or 2 days in future(at least now I have hope)

This is exactly what is not wanted in LHC. At the moment looks like admins were trimming amount of work with estimated time. Now collectors can queue even more (not saying you are one of them). So admins must find another way to stop that.

At the end everybody are running Boinc projects by choice and admins must decide what's good for their project.

10) Message boards : Number crunching : only 10 k WU's left (Message 9202)
Posted 6 Aug 2005 by Antjest
As I see it LHC is a project that needs fast turn around and not long local queues for people obsesed with credit after everybody else run dry.

So ideal cruncher is the one that downloads one WU, proces it, return it and then dowload another. OK, perhaps three at a time. There is no use that someone sends results back after 10 days and after 4 have procesed it. Some users have set connect to 10 days and do multiple projects.

So, I believe that server should be set in the way nobody gets more than 0,5 days at the time. It could be also set to initialy send to only three people and quorum of two is enough as identical results must be produced. With deadline like 5 days or even less, throughput will dramatically improve.

And for those who only think about credit. We are doing this the way program manager and science requires. If you don't like it, there are many other projects you can devote your CPU time.

11) Message boards : Number crunching : only 10 k WU's left (Message 9159)
Posted 4 Aug 2005 by Antjest

I am still getting 14days deadline, but calculation estimate has returned to previous state. So basically, 10days cache is again cca 3 days worth.

You might consider changing to 7 days deadline and connect to max 5days if you want quick result turn-over, so queues will not be longer than 1 day and reduce of initially sent results to 3 and quorum of 2 as it was before.

Or any other combination you see fit for quick turn-around.


> are you sure you are getting a 14-day deadline? Is everybody else getting this
> also?
12) Message boards : Number crunching : Strange! (Message 8885)
Posted 24 Jul 2005 by Antjest
I remember that times. I got many 0 credits. And many resets to make things work again. But now in production mode we can do more science work if 5th result would not be sent or sent later or just in case of errors.

All those 0 credit errors are gone now, at least I haven't seen any lately and since LHC crunching results must be exactly the same, they can return to the first WU sending policy, send 3 quorum 2 and even more WU's can be crunched.
They have many in the pipeline as they said.

At the end, I like to do more science, and credit comes second. At least here in LHC.
Or maybe I am sentimental cause this is European project or that I have a cousin in Switzerland :)


> @Colt... LHC had a 3 validate system and
> quorum at 2 but this got out of control when 0 was reported by some users due
> to a problem with sixtrack program and many paticipants got 0 credit when
> crunching a 100 credit workunit,remember?.... sometimes a good reason to over
> validate... Beta was a lot of fun...many of us lost a LOT of Boinc credit but
> thats not my primary concern or the others who have crunched from the
> beginning. The science is the X factor :)
13) Message boards : Number crunching : Strange! (Message 8813)
Posted 22 Jul 2005 by Antjest
I wasn't asking anything and what you did is just speculate.
We can speculate further.
If I would want faster crunching I would also consider shorter deadlines
(like Einstein or even shorter) or combination of number of sent WU with deadlines to achieve most effective throughput.


> The key words are "if crunched fast enough." They do this because not every
> host is going to respond within the 2 week window presently prescribed.
> Presently 3 identical results are required to validate a given WU. If they
> only send out 3 results per WU and then one additional result after the WU
> expiration date occurs (assuming 2 of 3 are complete and valid and 1 never
> replies before expiry), then it could take potentially up to 4 weeks or more
> for a given WU to be successfully processed & valided. So by initially
> sending out 5 results they reduce the chance a WU will take several weeks to
> complete. If all 5 respond and are validated successfully, all 5 hosts
> recieve credit and the WU has more valid responses to back the work.
> Hope that answers your question.
14) Message boards : Number crunching : Strange! (Message 8795)
Posted 22 Jul 2005 by Antjest
I kind of like it this way. Personaly I believe that sending out WU for 5 times is overkill and waste of resources and energy. This way WU's are sent out less times if crunched fast enough.

Whenever I have time to spare I check and abort already validated WU's that are in my cache. My believe is that everything crunched over the validated trio is unnecessary. I do that too in Einstein and Seti .

15) Message boards : Number crunching : WU with granted & pending credit (Message 7675)
Posted 13 May 2005 by Antjest
Sorry, its friday and ISP showtime.
16) Message boards : Number crunching : WU with granted & pending credit (Message 7674)
Posted 13 May 2005 by Antjest
> > It's just the over-eager file deleter program which does its work
> correctly in
> I would have thought the file deleter should not delete a file until after all
> outstanding results have been received or gone past the deadline and have
> sufficient results. I don't think a little delay is really the way to go.
> IMHO a check on the server state or the like would be better.

I believe that scientists were over-eager to get the data as soon as validated, and by mistake cleared the database so there was nothing left to compare to.
There is really nothing wrong with hw/sw.

Database was cleared late 22april or early 23april CERN time, as all my earlier results were validated and later from that batch are still pending.

For the new batch of 100k results everything is working fine.

17) Message boards : Number crunching : Odd validation (Linux Client sometimes 10x faster than Win32 ?) (Message 6456)
Posted 6 Mar 2005 by Antjest
> As I wrote, my BOINC is already fully optimized, Benchmark Results are pretty
> much equal to Win32 ones.
> The actual issue is as to why a machine running Linux either completes the
> same job more than 10x faster, or why possibly invalid/differing (my
> ultra-fast) results are labeled Valid.
> If I was running the default, unoptimized BOINC Cores, difference in Credits
> would be almost a Factor of 30-40x...

Perhaps you should try to run Win CC under Wine.

Check this thread http://einstein.phys.uwm.edu/forum_thread.php?id=1208

18) Message boards : Number crunching : Odd validation (Linux Client sometimes 10x faster than Win32 ?) (Message 6450)
Posted 6 Mar 2005 by Antjest
Boinc CC benchmarks are "better" for Win than Linux.

Try getting optimised Linux CC from SETI site, which gives similar benchmarks to Win.

There is also bug in CC with Win9x/ME, that keeps CPU timer running for all projects, even when paused.

19) Message boards : Number crunching : Downloading failed (Message 5809)
Posted 22 Feb 2005 by Antjest

Remember that the official release is CC 4.19

All further releases of CC 4.6x and 4.2x are beta or even alpha version and are not intended to be used by general public.

Whoever is not in alpha or beta can use them but should not whine if something goes wrong.
It's very boring reading about those CC not working on boards of all projects.

There is a simple solution, which will probably resolve all problems.
If it's not working go back to official CC version.

20) Message boards : Number crunching : BOINC client 4.12 is released (Message 3768)
Posted 13 Oct 2004 by Antjest
> @colt
> i can not say that is a proplem on my side
> run it on a
> pentium 3 with win xp home service pack 2
> and on a amd64 win xp home service pack 1
> all run fine
> http://www.guidowaldenmeier.de/guido/

Perhaps I forgot to say that LHC and CPDN are working fine, separate or combined but as soon as SETI is attached in any combination and try to connect to server CC jumps to 100% CPU and locks.

Next 20

©2024 CERN