Welcome to MilkyWay@home

Posts by Ananas

1) Message boards : Number crunching : 196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED (Message 63475)
Posted 28 Apr 2015 by Ananas
Post:
This is not a client configuration problem, it is a workunit problem.

The project can define a max. disk usage per workunit, each workunit that fails to stay below this limit will be aborted by the BOINC core client.

The only thing you could do against it would be to patch your core client so it ignores this limit - but then a workunit running wild would not be recognized.

p.s.: usually all workunits of the same batch have the same disk limitation. Even though it is possible to calculate an individual limit for each single workunit, I doubt that too many projects do that.

OOPS, sorry ... I thought your problem was related to the rsc_disk_bound value (as mentioned in the starting post) but this doesn't seem to be the case.

Several years ago I made this thing, maybe it helps. Note that BOINC will probably still not get along well with NTFS compression, i.e. BOINC uses the physical disk space for the calculation, ignoring the compression potential.
2) Message boards : Number crunching : What is the cause of these 'validate errors' (Message 63078)
Posted 25 Jan 2015 by Ananas
Post:
... results are "born" with quorum and replication = 1, which is increased during their lifetime.

Situation changed, my host seems to be classified "reliable" now and results are accepted without having a wingman.

So that configuration setting does have the potential to increase the overall project performance.
3) Message boards : Number crunching : What is the cause of these 'validate errors' (Message 63075)
Posted 25 Jan 2015 by Ananas
Post:
Thanks, that explains it - and it explains, why results are "born" with quorum and replication = 1, which is increased during their lifetime.
4) Message boards : Number crunching : What is the cause of these 'validate errors' (Message 63072)
Posted 25 Jan 2015 by Ananas
Post:
Just out of curiousity : Unlike all other projects, the validator here seems to grab a workunit when only one out of two required results are back. Is there a reason for that and does a single result with a wingman that is still "in progress" even have a chance to be valid if the quorum is higher than 1?

To me this looks like a strange behaviour of the validator (or transitioner). I sometimes have results with quorum=2, initial replication=2, only one result back but that one has the status "Completed, validation inconclusive" instead of the status "Completed, waiting for validation" that I would expect for a result that isn't ready for a first validator attempt yet.
5) Message boards : News : Scripting to remove WUs from certain searches (Message 37461)
Posted 17 Mar 2010 by Ananas
Post:
Why don't you just fix the BOINC bug that allows a host to always have the full quota with only 2% valid results?

void SCHEDULER_REPLY::got_good_result() {
    host.max_results_day *= 2;
    if (host.max_results_day > config.daily_result_quota) {
        host.max_results_day = config.daily_result_quota;
    }
}

void SCHEDULER_REPLY::got_bad_result() {
    host.max_results_day -= 1;
    if (host.max_results_day < 1) {
        host.max_results_day = 1;
    }
}


would better be

void SCHEDULER_REPLY::got_good_result() {
    host.max_results_day += 1;
    if (host.max_results_day > config.daily_result_quota) {
        host.max_results_day = config.daily_result_quota;
    }
}

void SCHEDULER_REPLY::got_bad_result() {
    host.max_results_day /= 2;
    if (host.max_results_day < 1) {
        host.max_results_day = 1;
    }
}


The only problem would be that other BOINC bug, that applies only to a few projects : WUs that are cancelled on server side reduce the host quota instead of beeing quota-neutral.
6) Message boards : News : Bad New Searches (Message 37302)
Posted 13 Mar 2010 by Ananas
Post:
Something new I noticed - no GPU here, just a Xeon L5520, but that probably makes it easier to see what happens as it happens a bit more slowly ;-)

The new WUs cross the 100% easily. One has been at 141% after 3:45 and now starts to go backwards (currently 135%, it lost 5% within the last 5 minutes), some other WUs are not showing progress at all after nearly 3 hours.

I will let it run though (unless beeing told to abort it) - they all haven't crossed the average runtime of previous results yet.

p.s.: The 140% result is de_14_3s_free_5_82853_1268435031, those stuck at 0% are 11_3s and 12_3s ones.

p.p.s.: I do have a few valid 11_3s, 13_3s and 14_3s (const and free) already, so they are not necessarily doomed ;-)
7) Message boards : Number crunching : Invalid WU's After Database Crash? (Message 32967)
Posted 3 Nov 2009 by Ananas
Post:
Same here, a bunch of invalid results using astronomy_0.20_x64_SSE3.exe
8) Message boards : Number crunching : server crash (July 29) (Message 28533)
Posted 29 Jul 2009 by Ananas
Post:
Weak account key, not much risk.

People can join their computers to that key but not modify or even take over the account.

The weak one is thought to be used in public places.

p.s.: and how is he supposed to edit out the key if you quote it ;-)


oops, I see that he has posted the original one _and_ the weak one, sorry, now I feel a bit stupid :-/
9) Message boards : Number crunching : server crash (July 29) (Message 28524)
Posted 29 Jul 2009 by Ananas
Post:
um ... not everything OK, I hope it's just the BOINC cache or an index :

A bunch of tasks from earlier today have been marked "no longer usable" and exactly those are affected and my PC's task list was empty.

My user task list was _not_ empty, but if I opened the older tasks, the PC they are attached to is not mine, e.g. :

http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=63855306

from my task list is attached to

http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=73028

belonging to DrMASH

Tasks that I downloaded just now have the correct host entry.
10) Message boards : Number crunching : MD5 checksum errors (Message 10200)
Posted 9 Feb 2009 by Ananas
Post:
The second boxes that received those WUs didn't have problems. Maybe my BOINC just had a timeout, the MW web site is quite sluggish. Several downloads did work, but several in a row failed, that's why I assumed it might be the configuration for a certain set of results.
11) Message boards : Number crunching : MD5 checksum errors (Message 10185)
Posted 8 Feb 2009 by Ananas
Post: 
<core_client_version>5.10.28</core_client_version>
WU download error: couldn't get input files:
<file_xfer_error>
  <file_name>/stars-79.txt</file_name>
  <error_code>-119</error_code>
  <error_message>MD5 check failed</error_message>
</file_xfer_error>


Probably a WU configuration problem, the filename starts with a slash
12) Message boards : Number crunching : Host page errors (Message 5225)
Posted 15 Sep 2008 by Ananas
Post:
Strange things sometimes happen if you configured your hosts for this project through the host dialog or BOINCview, but your host is connected to an account manager (e.g. BAM) that doesn't know about that.

I'm not using an account manager, but it seems that it is a one-way thing, i.e. changes you make on the host side do not get sent to the account manager.

So if you use an account manager, be careful to make all project connections only there and avoid the host side configuration.




©2024 Astroinformatics Group