Message boards :
Questions and problems :
Any way to manually change the deadline of a task?
Message board moderation
Author | Message |
---|---|
Send message Joined: 25 May 09 Posts: 1287 |
No - they are determined by the individual projects to fit with their own desires. |
Send message Joined: 5 Oct 06 Posts: 5091 |
You can do it, but I'd strongly urge you not to do so. Everything to do with tasks is stored in a single file - client_state.xml. It's huge, it's vital, it's complicated, and it's fragile. To change anything, you have to stop BOINC, edit the particular value you're interested in, re-save the file, and start BOINC again. A single slip-up in either values or formatting, and the whole pack of cards collapses in a heap. Having said that, deadlines are easy: <report_deadline>1608156032.000000</report_deadline>That's a "Unix timestamp" - the number of seconds since the start of the current Unix epoch, and can be converted via, say, EpochConverter to Wednesday, December 16, 2020 10:00:32 PM And, again, having said that, I wouldn't do it that way. I also run Climate Prediction, and I manage that by Not running a large cache Not running too many projects at once Increasing the time between task switches to a day or longer BOINC takes very little notice of deadlines unless there's a real danger that they might be missed. The key factor in your problem is probably to make sure that no other project grabs the CPU because its own deadline is too close. |
Send message Joined: 28 Jun 10 Posts: 2578 |
I wouldn't bother for deadlines. The only time I edit client_state.xml is when needed for a task usually, testing branch tak that I know will crash otherwise. So far I have managed without making the whole thing fall apart but wouldn't be surprised if at some stage I do that. |
Send message Joined: 25 May 09 Posts: 1287 |
Thanks Richard - I really should have made sure the caffeine level was up to "functioning" - a better initial answer would have been "No, unless you really know what you are getting into, and are prepared to loose all you current work if you get it wrong". |
Send message Joined: 5 Oct 06 Posts: 5091 |
As an afterthought - it is possible to edit the locally-displayed deadline, and if you extend it, the BOINC client will let it start after the new date. But the real, effective, deadline is stored in the project's server, and your local edit has no effect there. If you award yourself a period of extra time, it's at your own risk - the project may not accept your scientific result, and may not award you any credit for it. |
Send message Joined: 5 Oct 06 Posts: 5091 |
What I'm trying to do is shorten the deadline for my CPDN tasks ...Yes, I know - but this is a public forum, and other readers might have used my instructions for a different purpose. It's important that they, too, know the full implications so they can make an informed judgement. |
Send message Joined: 5 Oct 06 Posts: 5091 |
... Primegrid send out far too many tasks ...Can we take a technically precise reading on that statement, please? I'm currently working on what seems to be a real-life programming bug (#4117) which looks like that, but in reality the cause of the problem is that the client asks (repeatedly) for too much work - way beyond what my cache settings require. Your Event Log will tell the full story - <sched_op_debug> will add useful figures for how much you request and how much you receive. Note that the fundamentals of the internet prevent servers from sending work except in response to a request - firewalls and routers would block such traffic. |
Send message Joined: 25 May 09 Posts: 1287 |
Having zero as your prime cache may not be working in your favour - try a "real" number of say 0.1. Further having the additional days greater than the prime cache setting is known to give issues, so again a small number, say 0.01. While this will not help avoiding the long deadlines (which originate from the protect) it will help to reduce the apparent overloading that you are observing. |
Send message Joined: 5 Oct 06 Posts: 5091 |
Yes I know, but I assumed the client was saying "I want 1000000 seconds of work" - a long time ago you could see that in the event log. Perhaps they moved it into a debug flag. If I ask for 1 million seconds and get 5 million, it's the server's fault.On the very first attach, the clients should ask for precisely 1 second of work. But the subsequent request should asking for something approximating to your cache setting. Yes, the simple figures are revealed by a debug log flag - the <sched_op_debug> I mentioned in my question. That produces very few, but useful, extra lines in the output - small enough for me to set it as routine on all my rigs. |
Send message Joined: 5 Oct 06 Posts: 5091 |
If the machine was nearly dry, it would ask for 11232s x 4 (44,928 seconds), to keep all four cores busy for the whole length of the cache. So that looks OK. It got 20 tasks - 3,103.95 seconds each. How do they display on the Tasks tab in BOINC Manager? The average task runtime would be about 52 core-minutes, or 13 CPU-minutes. The Manager should display in wall-time, so the 'correct' figure would be 13 minutes. 20 tasks would take about 4.3 hours - a bit long, but not disastrous. The server translates your work request into a number of tasks, but at most projects mere mortals can't see the working. The honourable exception is Einstein, but they don't have any MT apps. The 'estimated total CPU task duration' is worked out by the client, and we can look into that. If you see a work request which seems to produce the wrong answer, it would be helpful to gather all the evidence (the debug log, like this one: a screenshot of BOINC Manager: and if you get there before the next work request, the 'sched_request_...' and 'sched_reply_...' files for the event). [Those are created new each time, but remain in the data directory until over-written by the next request] |
Send message Joined: 5 Oct 06 Posts: 5091 |
Thanks. I've got a little 4-core Celeron (bought for testing a low-power CPU bug), which should be dry in the next half-hour or so - I drain them, rather than abort them. I'll repro that, and grab the screen-shots etc. Sounds like another issue for GitHub, after I've answered David's silly question overnight. Going to be a busy weekend. |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.