Estimated Time Remaining, frictional reporting :
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
-- >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.
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 correctional constants might be needed at Duration
Correction Factor SERVER, but can only be derived from real time Client
performance data.
MP
DSN @ H
-----Original Message-----
From: McLeod, John
Sent: 13 February 2014 13:09
To: Jon Sonntag
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.
