Posts by Henk Haneveld

1) Message boards : Number crunching : Transient upload error (Message 519) Posted 27 Dec 2019 by Henk Haneveld Post: Aborting those uploads will mean that after 4 resends they hit there max resend number and be removed from the server. I am not sure about that. According Boincstats (https://classic.boincstats.com/en/stats/171/user/list/8/0/0), there are all 0 in Credit / Week. Looks like nobody are able to upload tasks.[/url] That just means that the stats update are not working either. I have uploaded some off the resends and they do validate.
2) Message boards : Number crunching : Transient upload error (Message 517) Posted 27 Dec 2019 by Henk Haneveld Post: The results that are in the ready to send queue all look to be resends from before the server change. I have aborted all uploads that got stuck. I then get work form the queue, some will finish and upload others will again get stuck and aborted. It looks to me that the server change corrupted a bunch of return links for the uploads. Aborting those uploads will mean that after 4 resends they hit there max resend number and be removed from the server.
3) Message boards : News : Request for feedback (Message 311) Posted 21 May 2019 by Henk Haneveld Post: Admin, I just got a batch of new results. You are still using the to low setting of 3072MB Do you think that you have to keep the setting als low as possible because it is used as a diskquota? If you are, you are wrong. Like I said before it is a killswitch. Diskquota is controlled by the user and set in the general Boinc-client preferences. If a combined total of all projects/results uses more than that quota the user gets a message from Boinc. The user can then either change the quota or stop running a project with high diskspace needs if he has not enough free diskspace. So once again, please set the limit higher. I am getting a bit upset that you ask for feedback but then don't take action when information is given.
4) Message boards : News : Request for feedback (Message 310) Posted 21 May 2019 by Henk Haneveld Post: Admin, If I understand correctly what you are saying, you try to assign just the right amount of diskspace to a result. There is no need for that, the settings goal is to act as a killswitch for faulty results. Define at what amount of disk use the largest result is faulty and set that as the trigger value in the parameter for all results.
5) Message boards : News : Request for feedback (Message 308) Posted 20 May 2019 by Henk Haneveld Post: I did some deeper investigation in the results I have currently on my system. I found that for the Boinc parameter "rsc_disk_bound", that sets the disk usage limit, you use a mix of 3 values: 1024MB, 2048MB and 3072MB. Are results created by separate sources that each set there own disk usage limit? If so, I suggest that you go to a fixed value for all results of at least 4096MB.
6) Message boards : News : Request for feedback (Message 307) Posted 20 May 2019 by Henk Haneveld Post: This is just stupid. 20/05/2019 16:33:02 \| nanoHUB_at_home \| Aborting task 07219627_01_2: exceeded disk limit: 1105.91MB > 1024.00MB In my last post I asked for a raise of the limit from 3072MB to 4096MB. What do you do? You change it to 1024MB
7) Message boards : News : Request for feedback (Message 303) Posted 18 May 2019 by Henk Haneveld Post: The setting has been set higher but still to low. Try 4096 MB. 18/05/2019 10:15:54 \| nanoHUB_at_home \| Aborting task 07216014_116_3: exceeded disk limit: 3228.48MB > 3072.00MB
8) Message boards : News : Request for feedback (Message 298) Posted 13 May 2019 by Henk Haneveld Post: 13/05/2019 10:52:11 \| nanoHUB_at_home \| Aborting task 07209902_011_2: exceeded disk limit: 3226.00MB > 2048.00MB It looks like the setting for allowed disk use is to low.
9) Message boards : News : Request for feedback (Message 236) Posted 24 Mar 2019 by Henk Haneveld Post: Hello as long as there are only one or two workunits running on my pc it works fine. But with 8 concurrent wu's my machine is freezing, i had to unplug the power cord and reoot to get it going again. (yes, i am sure it was nanohub...) I would like to install an app_config.xml with <max_concurrent>4<max_concurrent> but don't know the app-name. Has anybody an working app_config.xml file? Best Regards. <app_config> <app> <name>boinc2docker</name> <max_concurrent>4</max_concurrent> </app> </app_config>
10) Message boards : News : New workunit pipeline (Message 179) Posted 31 Jan 2019 by Henk Haneveld Post: It is nice to have more work but not very usefull if half of them are rated as invalid.
11) Message boards : Number crunching : Workunit send twice to the same host. (Message 167) Posted 17 Jan 2019 by Henk Haneveld Post: I just recieved a resend for the Workunit 297901. The strange part about it was that before me it was send twice to the same host. I thought that was not possible. Is there an error in the project settings?
12) Message boards : Number crunching : Very short return time (Message 142) Posted 18 Dec 2018 by Henk Haneveld Post: There are plenty of options via BOINC Manager and app_config.xml files to limit the # of tasks. It is impossible to set a limit on results in the BOINC Manager. I don't know any way to do that in app_config.xml. Please post a example.
13) Message boards : Number crunching : Very short return time (Message 132) Posted 14 Dec 2018 by Henk Haneveld Post: We did extend the deadline to 24 hours for all new WUs. We will watch over the next few days to see if it should be extended to 48 hours. Please do make it 48 hours. However that will not fix another problem, the variable runtime of the results. They go from a few minutes to 4 hours but they all show up on my host with a estimated run time of about 20 minutes. So if my host asks for enough work for half a day I may get in reality work for 6 full days and then I will hit the dealine problem again. You have to find a way for the estimated runtime to be closer to the real runtime for each seperate result. I have already in a earlier post made the request to give users the option to limit the number of results they download.
14) Message boards : Number crunching : Very short return time (Message 129) Posted 14 Dec 2018 by Henk Haneveld Post: I just downloaded some work with a 1 day deadline I think that is still to short for users who don't run 24/7 and that the minimum workable is 2 days. But I will give it a try.
15) Message boards : Number crunching : Very short return time (Message 127) Posted 13 Dec 2018 by Henk Haneveld Post: Today I had a set of results that were all resends. All had a number _3 extension. I did a few of them but most hit the deadline and have been send out again to the next user. If this user also fails to do them on time they will hit the max results allowed number and will be killed permanently. This shows how dumb this short a deadline is. You get a lot of resends, each for a extra 8 hours wait time or the work won't get done at all. A longer deadline will get a higher success rate and will reduce network and database load.
16) Message boards : Number crunching : Short time limits require short buffer (Message 118) Posted 12 Dec 2018 by Henk Haneveld Post: A longer deadline is the only option that will work for everybody. Except perhaps the researchers. They may need a shorter time limit. Thru, but then they should make somekind of statement of that on the frontpage.
17) Message boards : Number crunching : BSOD, Stop Code: Video Memory_Management Internal (Message 117) Posted 12 Dec 2018 by Henk Haneveld Post: Hi Henk, would you mind sharing your app_config file? I have tries to build one myself but it seems I got the app names wrong. My host completely crashed /froze this morning with a black screen, after I investigated the issue I saw that BOINC hat started Naohub WUs so I guess that was the issue. With running only 1 WU at atime might solve this issue for now. Here it is: <app_config> <app> <name>boinc2docker</name> <max_concurrent>1</max_concurrent> </app> </app_config> Make sure to save it as a xml file and place it in the project directory. If you want to run more than 1 result just insert a higher number.
18) Message boards : Number crunching : Short time limits require short buffer (Message 114) Posted 12 Dec 2018 by Henk Haneveld Post: That only works if you run 24/7. If like me you don't, the short deadline will keep beeing a problem. Lets say I shutdown at 20:00 hrs and start backup at 09:00, if I then receive new work at 19:59 they will have gone past the deadline before I can even have a look at them. A longer deadline is the only option that will work for everybody.
19) Message boards : Number crunching : BSOD, Stop Code: Video Memory_Management Internal (Message 111) Posted 12 Dec 2018 by Henk Haneveld Post: It is more likely a memory problem. nanohub needs a lot of it. When nanohub started 4 results on my 8GB machine it froze. After creating a app_config.xml file to limit nanohub to run just 1 result things went ok, but 2 results was already to much.
20) Message boards : Number crunching : Very short return time (Message 100) Posted 11 Dec 2018 by Henk Haneveld Post: The return deadline of 8 hours became just even more ridiculous. A result killed itself after running for about 3,5 hrs because it hit a max runtime limit. If a result runs that long it is either a error or it has found something that needs a lot of time to figure out. A error should die much sooner, it is waisting time. A good result should get all the time it needs and not run into a runtime limit or a retum deadline.

Next 20