| log in |
|
1)
Message boards :
News :
N-Body 1.08
(Message 57623)
Posted 57 days ago by floyd I am seeing the Glibc errors coming across, but on older versions of the BOINC client. That´s just because older clients will be more likely to run on older systems with older glibc. AFAICS the real reason is that the application is dynamically linked - BTW the i686 binary is not - and it specifically depends on GLIBC_2.14 just as stated in the error message. To be more precise it´s just memcpy from that version. If this requirement is really necessary is up to the developers. If in doubt I´d suggest a static binary. |
|
2)
Message boards :
Number crunching :
MilkyWay tasks always on high priority
(Message 54177)
Posted 388 days ago by floyd do still show a DCF number when clicking properties in the Boinc Manager, are you saying that number is just for show? I think it is unused in projects like Milkyway and just hasn't been removed (yet?) for simplicity. Does it change? I noticed the estimated run times of queued tasks no longer do. |
|
3)
Message boards :
Number crunching :
MilkyWay tasks always on high priority
(Message 54146)
Posted 389 days ago by floyd mikey, thanks for your explanations. As far as I can tell that's all correct except the assumption in the last sentence. Unfortunately this whole DCF thing does not apply here. BOINC is moving away from the DCF concept and Milkyway seems to be an early adopter. That's why we got bitten by this non-dcf bug and other projects did not. The problem is that the boinc client doesn't even consider normal priority if the project doesn't have a DCF below 90. But in BOINC 7.0.24 and later, Milkyway does not have a DCF at all and BOINC gets the hiccups from that. In future releases this will be "DCF below 90 or no DCF", so non-dcf projects' tasks will be handled normally then. |
|
4)
Message boards :
Number crunching :
MilkyWay tasks always on high priority
(Message 54134)
Posted 390 days ago by floyd Please see this thread for information and possible solutions, but let's keep the discussion here. |
|
5)
Message boards :
News :
New Nbody Run
(Message 54133)
Posted 390 days ago by floyd As I wrote, the bug was introduced with a change in 7.0.24, so previous releases are safe from it. Of course older 7.0 versions can't be recommended, so a possible solution would be to switch back to BOINC 6 as you did. Now we all know that you can't simply downgrade from v7 to v6 (we have read the release notes, haven't we?) so here's instructions how to do it. Meanwhile the fix has been added to the source code so it will be in the next BOINC release, whenever that may me. If you can wait for that, that's another possible solution. |
|
6)
Message boards :
News :
New Nbody Run
(Message 54103)
Posted 392 days ago by floyd For those of us not experienced in editing or removing sections of the Boinc Mgr program, how do you change whatever is causing this problem. You can't. The problem is in your local Boinc installation and you'll have to recompile the code or find someone to do it for you. This is the patch I used: diff -Naur boinc_core_release_7_0_25/client/cpu_sched.cpp boinc_core_release_7_0_25_patched/client/cpu_sched.cpp --- boinc_core_release_7_0_25/client/cpu_sched.cpp 2012-04-14 10:02:12.000000000 +0200 +++ boinc_core_release_7_0_25_patched/client/cpu_sched.cpp 2012-04-22 02:14:30.000000000 +0200 @@ -470,7 +470,7 @@ // treat projects with DCF>90 as if they had deadline misses // - if (!p->dont_use_dcf && p->duration_correction_factor < 90.0) { + if (p->dont_use_dcf || p->duration_correction_factor < 90.0) { if (p->rsc_pwf[rsc_type].deadlines_missed_copy <= 0) { continue; } This is part of the code where Boinc looks for tasks to run in high priority. Basically it means, if a project uses DCF (Duration Correction Factor) and the value is somewhat reasonable, consider to leave the task alone. Otherwise it's a candidate for special treatment. Unfortunately, if a project does not use DCF, the "leave it alone" part is never reached. On the other hand 3 other projects do not have this problem and the PS tasks also do not have this problem. So why do the Nbody tasks have this issue? If a project uses DCF, which I think most still do, you won't notice anything of this. Look in your client_state.xml file, if you find a line reading "<dont_use_dcf/>" the project that it belongs to should be affected. The whole project. And I say "should" because Milkyway is the only one for me, too, so I can't verify this. But the PS tasks do have the problem, that's why I looked into this in the first place. I noticed both of my GPUs running nothing but Milkyway for half a day. Why not modify what ever the offending code is in the task rather than have us novices go monkying about in the programs behind boinc mgr? The offending code is not in the task, nor is it with the project. It is at your end and you can't change it yourself. The project could probably work around it, but you would have to do that for every single project seperately. It's more efficient to fix the problem where it is. I'll look over at the Boinc site for a contact address, if I find one I'll suggest to change this in the next release. But if somebody knows whom to inform, please feel free to point them here. |
|
7)
Message boards :
News :
New Nbody Run
(Message 54099)
Posted 392 days ago by floyd If your 4 apps continues to hog all 4 CPUs on this machine, you'll find the MIPS I donate no longer available to you. Simple guys. Back it off and quickly. You have 16 elapsed hours from the time of this post. First of all, CALM DOWN! I think this is caused by a bug that was introduced with the new dont_use_dcf command in Boinc 7.0.24. It makes the client assume that all tasks are about to miss the deadline, thus run them in high priority mode. This should affect all tasks of all projects that set dont_use_dcf. By the way, if I understand correctly how dont_use_dcf works, one should try to avoid using an app_info.xml on such projects, bug or not. |
|
8)
Message boards :
Number crunching :
New BOINC Manager = no MWAH WUs
(Message 54033)
Posted 399 days ago by floyd This change didn't make sense to me which is why I didn't try it before you suggested it. It seems like there is a limit to how many tasks you can have locally in buffer/queue and I was already there. Now that you describe it in more detail it doesn't make sense to me either. There is a limit of 40 MilkyWay GPU tasks per GPU, but you should have been able to get a new task every time one is returned. Perhaps the whole refetch mechanism isn't activated if you don't get the buffer filled to minimum in the first place? That would be "unexpected behaviour" at least. But glad it works now. |
|
9)
Message boards :
Number crunching :
New BOINC Manager = no MWAH WUs
(Message 54031)
Posted 399 days ago by floyd Thanks for that info Floyd! That made the difference. Are you sure you are talking to me? There seems to be some other Floyd around. What I wrote was meant for Mike S. Your issue seems to be something different and I don't think it is caused by those settings or the Boinc version. In fact I noticed "no work" or "work for CPU available" messages back with Boinc 6 and they went away without any change on my part. Must be some server side thing. floyd (the one, not the only) |
|
10)
Message boards :
Number crunching :
New BOINC Manager = no MWAH WUs
(Message 54028)
Posted 399 days ago by floyd Upgraded to 7.0.25. Check your settings for minimum work buffer and additional work buffer. Boinc 7 is supposed to fetch work when it runs below minimum, then try to fill up to minimum+additional. That's a change from Boinc 6 which had different settings in the same place, so your values may not be as you want them for Boinc 7. There's a lot of confusion about this change, I'm surprised you haven't noticed all the questions like yours popping up everywhere. |