| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Computing for Clean Water Forum
Thread: Strange BOINC Priority |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 44
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks,
i will let it rest for a few days. There is no reason to interfere with the client at this time. Maybe in the very near future a project reset. I understand there is more AI in the client than i thought. Thanks again, still a happy cruncher,  Arnold. |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
I've done this so many times, it can be ticked off if printed and held next to the client task queue, that I've no doubt it's 'The' order. Let me dump the client_state.xml and see what's filtered out from there. On first glance, they seem to be listed there in order of receipt., and indeed doing the result name searches on the first 10 and how they chronologically appear in the client, it's seemingly that order. Hmm, looks on WCG's web-page, by selecting Results Status, or clicking "Sent Time" or "Due time", the order among the tasks assigned at 09:10:08 is: HFCC_ n1_ 00924712_ n1_ 0001_ 0 faah16076_ ZINC00918518_ xEN_ 3rd_ md07910_ 03_ 0 ns000_ 00002_ 9 ns000_ 00003_ 11 c4cw_ target01_ 171751198_ 0 c4cw_ target01_ 171506571_ 0 c4cw_ target01_ 171630634_ 0 CMD2_ 0743-1TZS_ A.clustersOccur-2BAQ_ A.clustersOccur_ 16_ 162152_ 164232_ 162966_ 164232_ 1 CMD2_ 0743-1TZS_ A.clustersOccur-2A98_ A.clustersOccur_ 5_ 63653_ 67703_ 65274_ 67703_ 0 CMD2_ 0756-1SJI_ A.clustersOccur-3DB5_ A.clustersOccur_ 0_ 13705_ 15922_ 15094_ 15301_ 0 The order listed in client, Accessible view are...: ns000_00002_9 HFCC_n1_00924712_n1_0001_0 CMD2_0756-1SJI_A.clustersOccur-3DB5_a.clustersOccur_0_13705_15922_15094_15301_0 CMD2_0743-1TZS_A.clustersOccur-2BAQ_A.clustersOccur_16_162152_164232_162966_164232_1 faah16076_ZINC00918518_xEN_3rd_md07910_03_0 c4cw_target01_171630634_0 ns000_00003_11 CMD2_0743-1TZS_A.clustersOccur-2A98_a.clustersOccur_5_63653_67703_65274_67703_0 c4cw_target01_171751198_0 c4cw_target01_171506571_0 If there's any correlation between WCG's web-page and the client-listing, I don't seem to see it...  As for the listing in the client, this is the same order as in the scheduler-reply when the work was assigned, so atleast the v5.10.45-client haven't re-shuffled anything in this instance...  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
You have considered that hitting the headers for Sent Time and Time Due are sorted from latest to least? Had 12 C4CW yesterday in 1 call with same time stamp (down to the millisecond) and 1 shows out of order and remains in that same line no matter how often resorted.
----------------------------------------There's something funky in the RS page as when one looks at source code one sees the workunitid field (those numbers seen on RS pages of standard BOINC projects) and the pages mostly following these in sorted order. Mostly, certainly always when timestamps are all unique, so I've put in a mod request and a few more bits that were asked for in past. Now, uplinger also looked at the server code and I disassembled the client_state, where the timestamps are in seconds, with 6 decimal for the fraction. Bar panic state, the order is per how the tasks got sequenced in the client_state.xml, which is when same time stamps occur not necessarily the same order. i.e. the HFCC will have been recorded in the client_state before the C4CW... and that IS chronologically aka FIFO executed as far as the client is concerned... no obscure prioritizations. Something in the world where when a ruler is put to it, it proofs to be concave and not convex. End of story --//--
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
You have considered that hitting the headers for Sent Time and Time Due are sorted from latest to least? Had 12 C4CW yesterday in 1 call with same time stamp (down to the millisecond) and 1 shows out of order and remains in that same line no matter how often resorted. Yes, I know they're sorted from most resent to older, but even if you read my client-list from down to up, the order isn't the same... There's something funky in the RS page as when one looks at source code one sees the workunitid field (those numbers seen on RS pages of standard BOINC projects) and the pages mostly following these in sorted order. Mostly, certainly always when timestamps are all unique, so I've put in a mod request and a few more bits that were asked for in past. Now, uplinger also looked at the server code and I disassembled the client_state, where the timestamps are in seconds, with 6 decimal for the fraction. The deadline is saved as flops in client_state.xml, yes, but the Scheduling-server sends the deadline as integer, meaning the "decimal" is always zero then it comes to the deadline (except if you manually edits this yourself...). As for the sort-order on "normal" BOINC-pages, this is strickly by the resultid, or as it's also called the task-id. While the order the tasks is actually sent in often follows the same order, finding one or more tasks in a group issued at the same time buried a couple pages deep while the rest is on the 1st. page isn't unfrequent either. As for the wu-id, this is even more frequently out-of-order, since in cases of re-issues you'll have a lower wu-id compared to the neighbours. If got multiple applications wuid being non-sequential is also possible. A good example on this last from WCG is I've currently got 1817*, 1825*, 1818* from most resent to older... Bar panic state, the order is per how the tasks got sequenced in the client_state.xml Yes, this is also my experience.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." [Edit 2 times, last edit by Ingleside at Aug 26, 2010 4:47:24 PM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
I'm not concerned in this instance about the deadline timestamp but it being misleading on what you see in the client when hitting the Deadline column header. Is that a WCG mistake?... I see none where there isn't.
----------------------------------------From a CEP2 task: <report_deadline>1283464762.000000</report_deadline> <received_time>1282600757.299147</received_time> From a C4CW task: <report_deadline>1283632517.000000</report_deadline> <received_time>1282768506.067196</received_time> I see a fraction. Do you? For those not in the know, times are stored in seconds and converted to human readable date/time by assuming zero to be equivalent to 01011970 at 00:00:00 hours,... it's a Unix thing. I'd say for all: Give us back our Accessibility Grid View (or a 3rd click on the Deadline column header to restore receipt order... which I think is still very present in the 6.2.28 client to employ. -- // --
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
I'm not concerned in this instance about the deadline timestamp but it being misleading on what you see in the client when hitting the Deadline column header. Is that a WCG mistake?... I see none where there isn't. From a CEP2 task: <report_deadline>1283464762.000000</report_deadline> <received_time>1282600757.299147</received_time> From a C4CW task: <report_deadline>1283632517.000000</report_deadline> <received_time>1282768506.067196</received_time> I see a fraction. Do you? Ah, it's <received_time> you're talking about, a feature introduced in v6.6.37, and from the look of things only seems to be used for making sure GPU-jobs runs in FIFO-order... well, and to sort the GUI-task-list in FIFO-order. So, for GPU-jobs the run-order is sorted 1st. by <received_time>, 2nd. by "already started" and 3rd. by name. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
It may be an added feature, does not change the order in the client_state.xml is and was the normal processing order, FIFO, which was explained near the top of this now 36 post thread.
----------------------------------------Anyway, the only thing to take away is that in digging into the code I got something to propose to an active coder in the BOINC realm and fast track this. It's one of those 'too simple to be grasped'. --//--
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks, i will let it rest for a few days. There is no reason to interfere with the client at this time. Maybe in the very near future a project reset. I understand there is more AI in the client than i thought. Thanks again, still a happy cruncher, Arnold. After a automatic CPU benchmark the TTC jumped from 12:50:20 to 55:01:00. Then it went crazy suspending tasks and running others under high prio. I did a project reset and now the TTC is 01:55:24 (after an ordered benchmark) All is quiet now.....happely crunching away. [Edit 1 times, last edit by Former Member at Aug 26, 2010 8:16:18 PM] |
||
|
|
David Autumns
Ace Cruncher UK Joined: Nov 16, 2004 Post Count: 11062 Status: Offline Project Badges: 
|
Thanks for the feedback Uplinger
----------------------------------------This thread started off life as an observation so yep it's just nitpicking as all WU's do get crunched very successfully Bizarrely my latest batch are doing the exact opposite ! I aborted my whole queue (209 WU's [:">) so that sorting would not have an effect but the scheduler threw me a curve ball with some short expiry time HFCC's so it's been a while to get back to this point I've just completed those So here's what it's doing without any sort button being pressed  Not wrong, just different to how we've seen BOINC working since we migrated across to it back in early 2006. Keep 'em crunching Dave  |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
And still it's the order of how it's stored in the client_state in normal operation mode... in FIFO which is not in Vivo.
----------------------------------------Carry on.
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 1 times, last edit by Sekerob at Aug 27, 2010 12:33:32 PM] |
||
|
|
|