Posts by Henk Haneveld

1) Message boards : Number crunching : BOINC Manager 7.2.39 now available ! (Message 1479321)
Posted 19 Feb 2014 by Profile Henk Haneveld
Post:
The checkpoint interval will be active only for new started tasks.

When the task starts for the first time BOINC allocates slot for it and creates init_data.xml in it (e.g. in <BOINC_Data>\slots\0\).
That is the file from which the app will read the checkpoint interval:
<checkpoint_period>77.000000</checkpoint_period>
<disk_interval>77.000000</disk_interval>


No, not true.

I have tested this, You can change the value of the interval on the fly for work in progess.
However the new interval only becomes active after stopping and restarting Boinc.
2) Message boards : Number crunching : BOINC Manager 7.2.39 now available ! (Message 1478270)
Posted 17 Feb 2014 by Profile Henk Haneveld
Post:
The setting for "write checkpoint to disk every xx seconds" seems to be ignored.

Even when the setting is set to for example 300 seconds there is still a checkpoint about every minute for Seti. Simap checkpoints at exact 60 seconds interval.

Where did you set it? Which location/venue did you set it on? Is that host on the same venue? Are you using local preferences? local preferences override web preferences.

Claggy


First I set it on the serverside for the venue that the host uses and did a update to load the changed settings. When that did not work, I created a local preference file (there was not one before) but that did not work either.

Both times I did a reload of the cc_config file that has a entry for the checkpoint_debug flag.

However it is working now. My host does not work 24/7 but is shutdown overnight.
After the startup this morning it did work with the set interval. It seems that a complete shutdown and restart is needed to load this setting. This is a bit of a surprise because I thought that all settings were refreshed, while Boinc is running, by updating and/or reloading setting files.
3) Message boards : Number crunching : BOINC Manager 7.2.39 now available ! (Message 1478114)
Posted 16 Feb 2014 by Profile Henk Haneveld
Post:
The setting for "write checkpoint to disk every xx seconds" seems to be ignored.

Even when the setting is set to for example 300 seconds there is still a checkpoint about every minute for Seti. Simap checkpoints at exact 60 seconds interval.
4) Message boards : Number crunching : Boinc 6.10.36 is now the Recommended version for Windows and Mac (Message 977000)
Posted 9 Mar 2010 by Profile Henk Haneveld
Post:
In previous versions if a project had no more work its STD was reset to zero.

In this version that does not happen anymore.

Can somebody confirm that this is part of the fixes in workfetch mentioned in the release notes or is there somkind of problem with this new version.
5) Message boards : Number crunching : BOINC 6.10.32 (Message 968232)
Posted 5 Feb 2010 by Profile Henk Haneveld
Post:
I am running in "high priority" mode to finish some work on time.

It looks like this BOINC version has a problem with EDF sorting.
It skipped the fist couple of results to be processed and then started working in high priority on a result with a later date.

I have gone back to the 6.10.18 version.

Actually, if the change does what I expect, it's a big improvement, because it means that BOINC will finish a WU when before it would shift between "at risk" work units.

I don't think "EDF" has truly been "EDF" for a while.

It would have been interesting to stick with 6.10.32 and see if it produced a reasonable result (work returned on time).

That's what test versions are for.


When starting the later result Boinc ignored a partial finished result with a earlier date. When it finished the result, Boinc again started a result with a later date still ignoring the partial result. So it does not finish work in progress first.
6) Message boards : Number crunching : BOINC 6.10.32 (Message 968132)
Posted 4 Feb 2010 by Profile Henk Haneveld
Post:
I am running in "high priority" mode to finish some work on time.

It looks like this BOINC version has a problem with EDF sorting.
It skipped the fist couple of results to be processed and then started working in high priority on a result with a later date.

I have gone back to the 6.10.18 version.
7) Message boards : Number crunching : Panic Mode On (24) Server problems (Message 933693)
Posted 16 Sep 2009 by Profile Henk Haneveld
Post:
If a project backoff for uploads is in progress in Boinc 6.6.38 it is visible in the projects tab.

Select project and click the properties button.
8) Message boards : Number crunching : Astropulse Errors II-Optimized version 5.03! (Message 923180)
Posted 2 Aug 2009 by Profile Henk Haneveld
Post:
The factor of 1.3 in BOINC (called hard_app) by which the raw estimate for AP work is increased before comparing to the 30 day deadline was clearly inadequate for this case. There was also a change made in the ap_splitter code to 25 day deadline which has only been applied at SETI Beta so far.


I find it strange there is a possibility that AP deadlines will get shorter when the MB deadlines have been doubled with the recent change.

There are now MB results with a deadline off something like 50 days with a runtime less then a quarter off a AP result.

It would be beter to cut back on the deadlines for MB.
9) Message boards : Number crunching : Panic Mode On (21) Server problems (Message 919371)
Posted 19 Jul 2009 by Profile Henk Haneveld
Post:
Note that in the last hour - at about 06:30 on a Sunday morning, Pacific time - somebody has disabled the Astropulse splitters, put an extra 200 GB of data online (4 'tapes'), and restarted the splitters.

Any more volunteers for the Sunday morning staff shift?


Great that somebody is willing to do that but in the current situation not very usefull.

It would have been better to shutdown the splitters for a while to let the project run out of work and restart the upload server giving everybody the opportunity to return all the finished work they have sitting on there hosts.
10) Message boards : Technical News : Working as Expected (Jul 13 2009) (Message 918036)
Posted 15 Jul 2009 by Profile Henk Haneveld
Post:

Perhaps the best interpretation is "number of tasks that were within 36 hours of deadline when this problem started". If you run a cache that tight, you run the risk of being caught out.


These tasks will be marked as resends. If you are still able to download work then when then upload server comes back online it is possible that the original
task is uploaded before you can crunch the resend.

It may be wise to check if work in your cache, a couple of hours after upload restart, really needs to be crunched or can be aborted as a unnecessary third or higher result.
11) Message boards : Number crunching : Panic Mode On (19) Server problems (Message 917170)
Posted 12 Jul 2009 by Profile Henk Haneveld
Post:


The reason is simple. The feeder process sends out a 100 results every 2 seconds. Split in 97 MB and 3 AP. Based on the file size this is about 36MB for MB and 25MB for AP.

With no AP to send the amount of data to download dropped with close to 40%.


Does the feeder send 100 MB if no AP is available?


As far as i know the setting of 97/3 is fixed so if no AP is available then only 97 MB are send.
12) Message boards : Number crunching : Panic Mode On (19) Server problems (Message 917102)
Posted 12 Jul 2009 by Profile Henk Haneveld
Post:
Not to say that the AP rollout isn't contributing, but it must be via a different mechanism this time.


The reason is simple. The feeder process sends out a 100 results every 2 seconds. Split in 97 MB and 3 AP. Based on the file size this is about 36MB for MB and 25MB for AP.

With no AP to send the amount of data to download dropped with close to 40%.
13) Message boards : Number crunching : I am not understanding (Message 914681)
Posted 6 Jul 2009 by Profile Henk Haneveld
Post:
.....and there's the community of Pentium 4, stock application, going about the rest of their lives and enjoying the sunshine. That second community is more than capable of sucking the pipe dry at AP splitter rates, as Grant has shown.


There is also the problem that AP505 is still very new and that a lot of people who recieve one need to download the EXE files to run it.

If my memory is correct this caused a lot of network problems the last time there was a version change.
14) Message boards : Number crunching : Less than 100k Astropulse in the field (Message 910852)
Posted 24 Jun 2009 by Profile Henk Haneveld
Post:
Run only the selected applications

SETI@home Enhanced: yes
Astropulse: no <= 5.03 version
Astropulse v5: yes <= 5.05 version


I don't think this is correct.

Astropulse = AP 4.xx
Astropulse v5 = AP 5.03

There is not yet a option for AP 5.05


http://setiathome.berkeley.edu/apps.php

regarde :)


I think there is some misunderstanding.

You point to the available applications and yes there is a AP 5.05 application for windows.

But there is no selection option available for AP 5.05 in the account preferences. This means to me that the only way to get a AP 5.05 result is to allow work from other applications.
15) Message boards : Number crunching : Less than 100k Astropulse in the field (Message 910771)
Posted 24 Jun 2009 by Profile Henk Haneveld
Post:
Run only the selected applications

SETI@home Enhanced: yes
Astropulse: no <= 5.03 version
Astropulse v5: yes <= 5.05 version


I don't think this is correct.

Astropulse = AP 4.xx
Astropulse v5 = AP 5.03

There is not yet a option for AP 5.05
16) Message boards : Number crunching : Possible 6.6.20 Problem (Message 884962)
Posted 13 Apr 2009 by Profile Henk Haneveld
Post:
I think 6.6.20 has a problem with LTD calculation.

I have 3 projects SETI,Einstein and CPDN with a resource share off 50:25:25 on a host with 2 CPU's. No Cuda.

SET runs constant on 1 CPU and the other projects switch on the second CPU.

The LTD for SETI was zero and kept that value.
The LTD for EInstein went down when the project was running and up when stopped but not as fast as when going down.
The LTD for CPDN kept the value zero running or stopped.

To my opinion the LTD for Einstein and CPDN should have worked in the same way, lower when running and back up at the same rate when stopped.

I have given up on 6.6.20 and gone back to 6.4.7
17) Message boards : Technical News : Emerald (Feb 10 2009) (Message 864290)
Posted 11 Feb 2009 by Profile Henk Haneveld
Post:

Here's another problem we've been having over the past couple weeks, and it doesn't seem to be getting better: ants.



Have a look at the Scarecrow graphs for the source.
18) Message boards : Number crunching : declining results in progress (Message 849674)
Posted 5 Jan 2009 by Profile Henk Haneveld
Post:
I think that AP has a lot to do with it.

Ap results are a lot bigger and take longer to run so there is less demand for results.
19) Message boards : Technical News : Tuesday Twinge (Sep 02 2008) (Message 804616)
Posted 3 Sep 2008 by Profile Henk Haneveld
Post:

Meanwhile, we're out of space again on the workunit server, and with no fast/easy way to add space. Eric's playing with the splitter mix to reduce the number of Astropulse workunits being generated (they are much larger than SETI@home workunits). Maybe that will help, but not immediately. This is what's mostly causing our headaches today as we can't create enough work to keep up with demand.


I think this is the wrong way around.

1 AP result file is about the size of 22 MB result files.
But to process 1 AP result takes longer then 22 MB results.

To reduce the need for diskspace you need the get more AP results to the clients not less.



Your typical result file for MB is 23-35Kb, not Mb, your typical AP result is about 45 Kb... but a MB WU is 350Kb, and an AP WU is 8Mb - and they have to store the WU, so that if someone misses deadline, they can send it out again.

MB = Multi-Beam
AP = Astro Pulse


I may have not be clear enough. I was talking about the 350 Kb and 8 Mb files.
8 Mb is about 22 * 350 Kb.

So my point still stands that it is beter to send out more AP.
20) Message boards : Technical News : Tuesday Twinge (Sep 02 2008) (Message 804490)
Posted 3 Sep 2008 by Profile Henk Haneveld
Post:

Meanwhile, we're out of space again on the workunit server, and with no fast/easy way to add space. Eric's playing with the splitter mix to reduce the number of Astropulse workunits being generated (they are much larger than SETI@home workunits). Maybe that will help, but not immediately. This is what's mostly causing our headaches today as we can't create enough work to keep up with demand.


I think this is the wrong way around.

1 AP result file is about the size of 22 MB result files.
But to process 1 AP result takes longer then 22 MB results.

To reduce the need for diskspace you need the get more AP results to the clients not less.


Next 20


 
©2025 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.