Estimated Time Remaining, frictional reporting (R1) : Duration Correction Factor CLIENT + Duration Correction Factor SERVER
is a good autonomous solution for all parties involved. This approach allows for some sensible Artificial Intelligence to be done at the Client. -- The Client probably has better knowledge about possible work unit completion [and overall progress] than the project server ever will. -- This is sort of the nature of distributed computing, when one is using different kinds of computers to run the numbers. The Client can build up a behavioral database [on a per application basis], and use statistics for deriving Duration Correction Factor CLIENT. The Client --> Server hint data structure -- The Client need only pass back to the server 2 or 3 numbers to correct Duration Correction Factor SERVER. -- If the Server does not support decoding the data structure it will be ignored. -- BOINC Server version numbers can be used to turn off or on this hinting, thus avoiding unnecessary traffic generation, will I hope this is possible... -- How or where this will be transmitted, received and processed (and used) I do not know. The Data Structure --> Version number : Unsigned Byte --> Method : Unsigned Byte, as it will take experimentation with up to 30 or 40 methods over time to get this right ... -- >Certainty (%) : (Unsigned or Unsigned) Byte (5 decimal to 95d in steps of 5), signed to use sign as parity bit... --> Seconds Delta : Signed Int ~= 9 hours differential possible per communication; Math = [32k/60]/60 --> Sample age seconds : Unsigned Byte (only use 100 to 180 decimal, mostly 101 to 123 used), resample greater than 67s --> Reserved for future use : Unsigned Int, could provide the last unsigned int of Unix Time (signed int64) timestamp of sample time --> Optional : Sequence Number : Byte -- aka how many times has a correction been sent after UTC 00:00 ... Keep it under 100! --> Checksum : CRC-16-CCITT, CRC32-mpeg if Client ID and Application Hashsum are used. --> So under 80 bits, certainly under 100 bits. --> Adding the Client ID (and Application Hashsum) will up the bits used, but still keep the traffic overhead to under 1000 bits. Meanwhile, Duration Correction Factor SERVER is still available. This is what is being used currently. So, backwardly compatible. Modifying Duration Correction Factor SERVER (to accept hints from Duration Correction Factor CLIENT) may take some re-designing, but can evolve over time. Possibly 2 or 3 derived correctional constants (for each client, but held at the server) might be needed at Duration Correction Factor SERVER, but can only be derived from real time Client performance data. “Revision 1, add Method” MP DSN @ H -----Original Message----- From: McLeod, John Cc: BOINC Developers Mailing List @berkeley.edu Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... Another is to have the client reinstate some form of Duration Correction Factor – so that the client did not have to wait for the server to update the estimates. It might make sense to make the DCF for projects that use the server side calculation react faster than the DCF for projects that do not. This would also have to be done with the understanding that the server side correction is in effect so new downloads would start with no DCF applied at first. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
