Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
![]() |
World Community Grid Forums
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 32
|
![]() |
Author |
|
foxfire
Advanced Cruncher United States Joined: Sep 1, 2007 Post Count: 121 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
...If the workunit id would be of use as well we can include it as well. I would very much like you to include the workunit id. ![]() |
||
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
We have added the WorkunitId. In order to keep the meaning of each id clear, the id field previously added has been renamed to ResultId. Here is an example output:
|
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Kevin,
Somewhere between now and half an hour ago the previously added Id field went blank, returns no data (From what you posted, it seems to have replaced the position now taken by WorkunitId) |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Arggh, Id rename to ResultId has blown all Xml maps so arduously regenerated, spelling the word 'unhappy', wasted hours of my time.
(Just adding Id cut the archive piece of the period run from 7-8 minutes to under 2, on an archive of 340000 on 45000 active results.) |
||
|
foxfire
Advanced Cruncher United States Joined: Sep 1, 2007 Post Count: 121 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
We have added the WorkunitId. In order to keep the meaning of each id clear, the id field previously added has been renamed to ResultId. ... Thank you Kevin!! ![]() |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
We have added the WorkunitId. In order to keep the meaning of each id clear, the id field previously added has been renamed to ResultId. Here is an example output:
1 ResultsAvailable Field 17 took an escape \o^o/ |
||
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2153 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
In the present case where ServerState=4 ('still in progress') one could live without the ReceivedTime field, as it denotes the time when the server received the result back from the 'reporter' (=cruncher), therefore the field is absent for a reason. Of course you knew that already, I'm just explaining.
![]() |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Except, when specifying SS 4, the Received Time is also in the list of mapped fields, that is when doing a pull with office query. What I know is not relevant, what is documented IS!
|
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Note for knreed,
The addition of the 2 unique keys in the API, electing to use the ResultId one, has led to serious search/find/sort/duplicate removal performance improvement... not quite the 1000x that some MVP was wielding around [he was not using the 'exact' match parm it appeared], but 12-15x has certainly been achieved... 1 minute or < 5 seconds is major when parsing a set of 400K 250 times per fetch max. Since the exact hits is temp stored in an array, the subsequent dependent algorithms pretty much fly, going from found, compare, state-lookup and record if new credit or, as the case may be, an erred result that got credited in arrears. This noon run 39000 ServerState 5 on the Result Status pages, 300,000 on archive and zero misses, off by 1 second [bankers rounding :O]. Thx much for that change. (Now its a case of appending the ModTime 'on or after' filter to the scripted Urls and the number of fetch cycles can dropped to just those of the last stats cycle. That will cause another step change in speed... but risks not catching any missed from the previous period... lost in intertube space. Got a solution for that needing to be worked up.) |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
This morning had some bwilliance occuring to me [see Hunting Tool thread] which again halved the time from previous, this afternoon while cycling 30 clicks in the cold, uphill to get warm, another 'moment' happened, and revisited some old John Nash stuff, returned to the original claim it could be done 1000x faster, and indeed, after application of the 'moment', it was.
Instead of this on chronologically sorted data [and ModTime is far from unique] =IFNA(MATCH([@ResultId];ArchResId;0);0) this, on ResultId small to large sorted data =IFNA(IF(INDEX(Archive[ResultId];MATCH([@ResultId];Archive[ResultId];1))=[@ResultId];MATCH([@ResultId];Archive[ResultId];1);NA());0) Yes, this looks like lots more work, but it isnt. Now, the part that needs to find an exact match and fails on unsorted key [limited range data, as set in ArchResId], finds the exact match, if true, without specifying an exact match in the initial search, and low and behold, so fast, the part of the cycle that took minutes to find if any of current 6000 results were already on archive, went to 'don't blink as you'll miss it', 0.3 seconds according the programmed stopwatch, and this against an archive of now 627000 results. How it works... if there's a number returned in an 'approximate search', search switch 1, like looking for ResId 1263712642 then compare the closest returned value to the original target value and if true, 1263712642, then look again for that 'approximate value' and register the record to be used to find other values of that record, such as was there credit grant or not, else, it's 100% sure to not be on archive, i.e. 0 = false So, goodoos again on adding the ability to do binary searching instead of the painfully slow match search on the result name [the formerly only unique piece of a result]. (Just fizzy water with a suspect color in a champagne glass ;P) |
||
|
|
![]() |