[RC5] Statsbox or Add-on suggestion-request...

Jim C. Nasby jim at nasby.net
Fri Jan 21 18:58:03 EST 2000



Ben wrote:
> 
> Darren Tay wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > I have an obvious suggestion for providing nicer stats for participants.
> > (If this thing already exists somewhere, sorry, could you point me to it
> > please?)
> >
> > Rather than (or in addition to) the "Participant's Block Submission
> > History", could we add a line graph plot of *cumulative* work done VS
> > time, for each participant? These stats would be much more useful than
> > Block Submission History, esp. for people (like myself) who do not
> > fetch-flush on a strictly regular schedule. A cumulative work VS time
> > graph would show change in keyrate nicely together with total work done.

Neat idea, I'll add it to the to-do list.

> I was actually considering writing this sort of thing in Perl. It would
> be nice if I could get the data in a cleaner format, but I could
> probably do it with the source of the stats page.

The raw data is available. Please see
http://stats.distributed.net/rc5-64/phistory_raw.php3?id=39622 for an
example.

> > Also, on the "Participant Summary" page, I suggest the "Current Rate" field
> > be defined rather as work submitted over time interval from last flush, or
> > something like that... The present calculation tends to give crazy-large
> > figures for "Current Rate" because it assumes that any work submitted that
> > day was completed on a single day (I suspect).

Your assumption is correct. We do not keep any info in stats about when
blocks were flushed other than the day that they hit the master, so it's
not possible to put your idea into effect.
 
> Hours spent processing would help draw the SETI at home users, since they
> think that the amount of hours is more important than the amount of
> results. This would probably require modification to the block
> submission protocol, though.

We have talked about doing this, and there's two issues. First, it would
require a change to the protocol, although we're already working on this
for other stuff anyway. Second, on many platforms it's not very easy to
determine how much CPU time was given to a process.

Moo!
dB!
-- 
Jim C. Nasby (aka Decibel!)                                  /^\ 
jim at nasby.net                                               /___\
Freelance lighting designer and database developer         /  |  \
Member: Triangle Fraternity, Sports Car Club of America   /___|___\

Give your computer some brain candy! www.distributed.net Team #1828
Get paid to surf!! http://www.enteract.com/~nasby/alladvantage.html

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list