Getting tasks not selected in Einstein@Home preferences
10 Feb 2016 7:44:13 UTC
Topic 198417
(moderation:
My computer and BOINC run 24/7, and I've been running two instances of Binary Radio Pulsar Search (Parkes PMPS XT) and one instance of Gamma-ray pulsar search #4 without any problems. This morning after I moved my mouse to take my monitor out of power saving mode I watched the CPU usage in Task Manager climb from its usual value of ~34% to 60%, then 100%. I suspended the project and set NNT. Back in the Tasks tab I saw four instances of Gamma-ray pulsar binary search #1 had started. In Einstein@Home preferences I found that the check box for the latter was checked. I unchecked it, aborted all the #1 tasks, set ANT, updated the project and resumed. More #1 tasks downloaded and the CPU usage shot up to 100% again. I followed the same procedure as before and went back to Einstein@Home preferences. Gamma-ray pulsar binary search #1 was still unchecked, but I noticed that Run CPU versions of applications for which GPU versions are available was checked. That was a surprise also, since I remember unchecking that some time ago when I had checked Binary Radio Pulsar Search (Arecibo, GPU) due to a dearth of Parkes PMPS XT tasks. So I unchecked Run CPU versions of..., aborted all the #1 tasks, set ANT, updated the project and resumed again. I'm still getting Gamma-ray pulsar binary search #1 tasks, so I have again set NNT. I don't know what's going on or what to do. Help!
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
Getting tasks not selected in Einstein@Home preferences
)
You say you only allow one instance of FGRP4. How are you controlling that? I imagine you may be using app_config.xml and have specified max_concurrent to be just 1 for FGRP4. If so, you could use exactly the same method for FGRPB1.
FRGP4 is going to finish shortly so you wont have the option to use it for much longer. FGRPB1 will soon be the only CPU app until the first of the advanced LIGO GW tasks arrive. That may be a little while yet. A lot might depend on what's in the big announcement on Thursday. We may all get killed in the pandemonium that might follow :-).
FGRPB1 was started as a beta test run. You only should have received any at the start if you had allowed test apps. When a new run like this is added, you are automatically selected to use it if you had selected the run it will replace - FGRP4. This is so that people (not paying attention) who were doing FGRP4 will automatically switch over to FGRPB1. The entry for the new run is visible before the new run starts so you can deselect it if you need to before it goes live.
One small gotcha is that if you do deselect it but have the option to allow test apps to run, you will still get those tasks despite deselecting the option. Allowing test apps means ANY test apps that are available and not just limited to your selected science runs.
Quite recently, the flood gates have opened for FGRPB1 and there now seems to be a continuous supply. Initially my hosts were getting these, but then I noticed they stopped. I'm guessing they stopped because they are probably no longer labelled as beta test tasks. I noticed this a couple of hours ago so I tested the situation by selecting FGRPB1 (previously not selected) and immediately I started getting these tasks. This seems to support my supposition about what has happened (removal of beta test status).
If you have any difficulty in working out how to limit FGRPB1 to a single task like you had for FGRP4, please respond with the details and we will help you get set up for the new run. Please note the the 'Run CPU versions of ...' has nothing to do with your situation because there is no FGRPB1 GPU app.
Cheers,
Gary.
RE: Quite recently, the
)
Nope. They are still marked Beta until FGRP4 is finished.
Ok, so it was just a
)
Ok, so it was just a coincidence that you started generating new tasks just after I noticed that my hosts had stopped getting FGRPB1 and had gone back to FGRP4 :-). I 'allowed' FGRPB1 for the first time since I had disallowed it some days ago and immediately saw new 2-week deadline FGRPB1 tasks. The 2-week deadline was the clincher for my wrong assumption :-).
So, if the tasks are still beta, the OP must have allowed beta test apps and this is why he can't turn off FGRPB1. His solution is to use the same mechanism for restricting FGRPB1 as he uses for FGRP4 - whatever that mechanism is. That way he should have a peaceful transition when FGRP4 runs out and FGRPB1 takes over.
Cheers,
Gary.
Maybe I too have a problem. I
)
Maybe I too have a problem.
I selected
Binary Radio Pulsar Search (Arecibo): nein
Binary Radio Pulsar Search (Arecibo, GPU): nein
Binary Radio Pulsar Search (Parkes PMPS XT): nein
Gravitational Wave search O1 all-sky tuning: ja
Gamma-ray pulsar search #4: nein
Gamma-ray pulsar binary search #1: nein
with beta apps set to yes
Last request was
2016-02-11 10:48:57.7813 [PID=25763] Request: [USER#xxxxx] [HOST#9133530] [IP xxx.xxx.xxx.234] client 7.6.22
2016-02-11 10:48:57.8085 [PID=25763] [send] effective_ncpus 4 max_jobs_on_host_cpu 999999 max_jobs_on_host 999999
2016-02-11 10:48:57.8085 [PID=25763] [send] effective_ngpus 1 max_jobs_on_host_gpu 999999
2016-02-11 10:48:57.8085 [PID=25763] [send] Not using matchmaker scheduling; Not using EDF sim
2016-02-11 10:48:57.8085 [PID=25763] [send] CPU: req 185.40 sec, 0.85 instances; est delay 0.00
2016-02-11 10:48:57.8085 [PID=25763] [send] Intel GPU: req 0.00 sec, 0.00 instances; est delay 0.00
2016-02-11 10:48:57.8085 [PID=25763] [send] work_req_seconds: 185.40 secs
2016-02-11 10:48:57.8085 [PID=25763] [send] available disk 6.47 GB, work_buf_min 0
2016-02-11 10:48:57.8085 [PID=25763] [send] active_frac 0.999941 on_frac 0.383993 DCF 1.487042
2016-02-11 10:48:57.8095 [PID=25763] [send] [HOST#9133530] is reliable
2016-02-11 10:48:57.8095 [PID=25763] [send] set_trust: random choice for error rate 0.000010: yes
2016-02-11 10:48:57.8095 [PID=25763] [mixed] sending non-locality work first (0.2959)
2016-02-11 10:48:57.8258 [PID=25763] [send] [HOST#9133530] will accept beta work. Scanning for beta work.
2016-02-11 10:48:57.8261 [PID=25763] [send] [HOST#9133530] beta work found: [RESULT#545059972]
2016-02-11 10:48:57.8262 [PID=25763] [version] Best version of app hsgamma_FGRPB1 is 1.00 ID 782 (3.60 GFLOPS)
2016-02-11 10:48:57.8262 [PID=25763] [send] [HOST#9133530] [WU#239435791 LATeah0001L_208.0_0_0.0_39200] using delay bound 1209600 (opt: 1209600 pess: 1209600)
2016-02-11 10:48:57.8281 [PID=25763] [debug] Sorted list of URLs follows [host timezone: UTC+3600]
2016-02-11 10:48:57.8281 [PID=25763] [debug] zone=+03600 url=http://einstein2.aei.uni-hannover.de
2016-02-11 10:48:57.8282 [PID=25763] [debug] zone=-18900 url=http://einstein-dl.syr.edu
2016-02-11 10:48:57.8282 [PID=25763] [debug] zone=-21600 url=http://einstein-dl2.phys.uwm.edu
2016-02-11 10:48:57.8282 [PID=25763] [debug] zone=-28800 url=http://einstein.ligo.caltech.edu
2016-02-11 10:48:57.8284 [PID=25763] [send] [HOST#9133530] Sending app_version 782 hsgamma_FGRPB1 2 100 ; 3.60 GFLOPS
2016-02-11 10:48:57.8318 [PID=25763] [send] est. duration for WU 239435791: unscaled 29199.85 scaled 113085.31
2016-02-11 10:48:57.8318 [PID=25763] [HOST#9133530] Sending [RESULT#545059972 LATeah0001L_208.0_0_0.0_39200_1] (est. dur. 113085.31 seconds, delay 1209600, deadline 1456397337)
2016-02-11 10:48:57.8343 [PID=25763] [send] don't need more work
2016-02-11 10:48:57.8343 [PID=25763] [mixed] sending locality work second
2016-02-11 10:48:57.8367 [PID=25763] [debug] [HOST#9133530] MSG( low) BOINC will delete file earth_09_11 (no longer needed)
2016-02-11 10:48:57.8367 [PID=25763] [debug] [HOST#9133530] MSG( low) BOINC will delete file sun_09_11 (no longer needed)
2016-02-11 10:48:57.8367 [PID=25763] Sending reply to [HOST#9133530]: 1 results, delay req 60.00
2016-02-11 10:48:57.8369 [PID=25763] Scheduler ran 0.059 seconds
And this is what I got:
https://einsteinathome.org/host/9133530/tasks
a Gamma-ray pulsar binary search #1 v1.00
As Christian pointed out,
)
As Christian pointed out, FGRPB1 is going to remain a beta test run until FGRP4 finishes. You have allowed beta test work so you will get these even if you have not selected the standard FGRPB1 run in your preferences. Allowing beta test work means ANY beta test tasks irrespective of your selections for science runs.
There aren't (yet) released tasks for the new GW run. Until they are released, you are bound to get just the FGRPB1 beta test tasks. After release, you will probably get a mixture. Please read this particular post in Technical News, where I have tried to explain the situation in detail.
Cheers,
Gary.
RE: You say you only allow
)
You are correct that I use an app_config.xml to specify max_concurrent to be just 1 for FGRP4. I also allow test apps to run, so I run BRP6-Beta-cuda55 for Parkes PMPS XT, since that app runs much more quickly than BRP4G. I will add FGRPB1 to my app_config.xml and specify max_concurrent of 0 until the project runs out of FGRP4 tasks, at which time I will change my app_config.xml to allow FGRPB1. I would have got back to you sooner but, while I did subscribe to the thread I never received any notification of a reply. I'll let you know if I still have problems. Thanks for responding.
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
Thanks for posting a reply.
)
Thanks for posting a reply. It's appreciated to know that you were using max_concurrent of 1. I'm very interested to know if setting a zero for FGRPB1 prevents both downloading and running of these tasks. I suspect that running will be prevented but not downloading.
It might be quite a moot point anyway since I saw a recent post from Bernd where he simply said,
Which should mean that you can now exclude these by not selecting that particular run, without having to add an entry to app_config.xml. Ultimately, you will need the entry if you wish to control this new run in the same way as FGRP4. I quite like this new run since they seem to complete a little faster than the previous run.
I'm not sure I like all these new template files - every task seems to require a new one :-). They're quite small but the servers must be suffering a little in servicing all the extra download requests. I've actually been caching them and at the start a lot were being supplied from the cache. Lately, it's virtually all new downloads with very few cache hits.
There's more than 1,000 of these so far in the local file cache I maintain. Over a couple of hours yesterday ~250 were downloaded and added to the cache while nearly 100 downloads were prevented by using a cached file. At that stage I thought this might be a useful thing to continue, just for the lowering of server load. Today, in the last hour, 100 new templates have been added to the cache and there hasn't been a single cache hit. The files are only 10KB each so the space to store them is minuscule really but if it's not saving server load, it's not worth the effort.
Cheers,
Gary.
RE: RE: Thanks for
)
Here is my app_config.xml after modifying for FGRPB1.
einsteinbinary_BRP6
0.5
.1
hsgamma_FGRP4
1
hsgamma_FGRPB1
1
When I first added FGRPB1 I used max_concurrent of 0 and there were no downloads. Strangely, after I changed max_concurrent to 1, checked the task in Einstein@Home preferences and updated the project, there still are no downloads. Server status indicates over 60,000 tasks available. Any ideas about this?
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
RE: Here is my
)
Looking at your last contact from here
[pre]2016-02-14 09:49:54.0776 [PID=30026] [version] Don't need CPU jobs, skipping version 115 for hsgamma_FGRP4 (FGRP4-SSE2)
2016-02-14 09:49:54.0776 [PID=30026] [version] no app version available: APP#27 (hsgamma_FGRP4) PLATFORM#9 (windows_x86_64) min_version 0
2016-02-14 09:49:54.0776 [PID=30026] [version] no app version available: APP#27 (hsgamma_FGRP4) PLATFORM#2 (windows_intelx86) min_version 0
2016-02-14 09:49:54.0786 [PID=30026] [version] Don't need CPU jobs, skipping version 100 for hsgamma_FGRPB1 ()
2016-02-14 09:49:54.0786 [PID=30026] [version] no app version available: APP#32 (hsgamma_FGRPB1) PLATFORM#9 (windows_x86_64) min_version 0
2016-02-14 09:49:54.0786 [PID=30026] [version] no app version available: APP#32 (hsgamma_FGRPB1) PLATFORM#2 (windows_intelx86) min_version 0[/pre]
I also see the host has many CPU tasks - FGRP4 - in progress- not sure if that helps, but maybe you host has picked up FGRP4 rather than FGBRB1 (they are more plentiful). (see server status)
RE: ... Strangely, after I
)
It's not really strange if you think about it. BOINC is now aware that it can only do one concurrent CPU task for both FGRP4 and FGRPB1. Your FGRP4 tasks are taking more than 6 hours each - about 3.6 per day. You currently have 61 in progress so that means about 17 days with your current settings. No wonder BOINC doesn't want to ask for any more CPU work.
You have a quad core i5. Are you sure you really need to restrict it to just one CPU task? If you could run two you could probably clear the backlog before deadline. What do you have for work cache settings?
Cheers,
Gary.