Index  | Recent Threads  | Unanswered Threads  | Who's Active  | Guidelines  | Search
 

Quick Go ยป
No member browsing this thread
Thread Status: Active
Total posts in this thread: 32
Posts: 32   Pages: 4   [ Previous Page | 1 2 3 4 | Next Page ]
[ Jump to Last Post ]
Post new Thread
Author
Previous Thread This topic has been viewed 3364 times and has 31 replies Next Thread
foxfire
Advanced Cruncher
United States
Joined: Sep 1, 2007
Post Count: 121
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

...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.
----------------------------------------

[Jan 10, 2017 4:33:03 PM]   Link   Report threatening or abusive post: please login first  Go to top 
knreed
Former World Community Grid Tech
Joined: Nov 8, 2004
Post Count: 4504
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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:


{
"AppName": "zika",
"ClaimedCredit": 0.0,
"CpuTime": 0.0,
"ElapsedTime": 0.0,
"ExitStatus": 0,
"GrantedCredit": 0.0,
"DeviceId": 3074575,
"DeviceName": "Nimbus",
"ModTime": 1484140157,
"WorkunitId": 1913094363,
"ResultId": 1191202595,
"Name": "ZIKA_000181133_x2m9q_9NMR_DengNS3pr_wPepAnalog_0384_0",
"Outcome": 0,
"ReportDeadline": "2017-01-21T13:09:17",
"SentTime": "2017-01-11T13:09:17",
"ServerState": 4,
"ValidateState": 0,
"FileDeleteState": 0
}

[Jan 11, 2017 2:35:59 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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)
[Jan 11, 2017 2:40:40 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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.)
[Jan 11, 2017 3:06:19 PM]   Link   Report threatening or abusive post: please login first  Go to top 
foxfire
Advanced Cruncher
United States
Joined: Sep 1, 2007
Post Count: 121
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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!!
----------------------------------------

[Jan 11, 2017 9:15:39 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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:


{
"AppName": "zika",
"ClaimedCredit": 0.0,
"CpuTime": 0.0,
"ElapsedTime": 0.0,
"ExitStatus": 0,
"GrantedCredit": 0.0,
"DeviceId": 3074575,
"DeviceName": "Nimbus",
"ModTime": 1484140157,
"WorkunitId": 1913094363,
"ResultId": 1191202595,
"Name": "ZIKA_000181133_x2m9q_9NMR_DengNS3pr_wPepAnalog_0384_0",
"Outcome": 0,
"ReportDeadline": "2017-01-21T13:09:17",
"SentTime": "2017-01-11T13:09:17",
"ServerState": 4,
"ValidateState": 0,
"FileDeleteState": 0
}

1	ResultsAvailable		
2 ResultsReturned
3 Offset
4 AppName "AppName": "zika",
5 ClaimedCredit "ClaimedCredit": 0.0,
6 CpuTime "CpuTime": 0.0,
7 ElapsedTime "ElapsedTime": 0.0,
8 ExitStatus "ExitStatus": 0,
9 GrantedCredit "GrantedCredit": 0.0,
10 DeviceId "DeviceId": 3074575,
11 DeviceName "DeviceName": "Nimbus",
12 ModTime "ModTime": 1484140157,
13 WorkunitId "WorkunitId": 1913094363,
14 ResultId "ResultId": 1191202595,
15 Name "Name": "ZIKA_000181133_x2m9q_9NMR_DengNS3pr_wPepAnalog_0384_0",
16 Outcome "Outcome": 0,
17 ReceivedTime ?????????????????
18 ReportDeadline "ReportDeadline": "2017-01-21T13:09:17",
19 SentTime "SentTime": "2017-01-11T13:09:17",
20 ServerState "ServerState": 4,
21 ValidateState "ValidateState": 0,
22 FileDeleteState "FileDeleteState": 0


Field 17 took an escape \o^o/
[Jan 13, 2017 6:35:20 PM]   Link   Report threatening or abusive post: please login first  Go to top 
adriverhoef
Master Cruncher
The Netherlands
Joined: Apr 3, 2009
Post Count: 2153
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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. wink
[Jan 14, 2017 12:51:17 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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!
[Jan 14, 2017 9:05:57 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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.)
[Feb 1, 2017 3:52:45 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: API Returning Conflicting Data

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)
[Feb 15, 2017 7:10:02 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Posts: 32   Pages: 4   [ Previous Page | 1 2 3 4 | Next Page ]
[ Jump to Last Post ]
Post new Thread