[QUOTE=Uncwilly;273523]It seems that the fix broke the 'easy' definition part. It sorts inverted.:ick:[/QUOTE]Apparently "easy" isn't so easy to define :cool:
Please try again, and let me know if anything still seems out of whack.

Hi,

*hmm* how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"? The hard way: remove the "avg. rate" from the status output... but I don't really like this solution.

Ideas?

Perhaps a nice text in README.txt? Does the average user even read the README?

Oliver

[QUOTE=TheJudger;274100]how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"?[/QUOTE]You need to display something that varies directly with overall performance, whether it's expressed as overall-time-per-exponent (where lower is better), or some inverse measure where bigger is better. What might be nice for the average user, actually, would be to replace "avg. rate" with "GHz-d/day" and calculate the GHz-days credit for the current assignment, and how much credit equivalent would be completed in 24h at the current rate.

[QUOTE=TheJudger;274100]
how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"?
[/QUOTE]

Calculate average rate not on sieved candidates but on all?

I'll go further: what I really want to know is approximate wall time per factor found, assuming the usual statistics....

[QUOTE=apsen;274107]Calculate average rate not on sieved candidates but on all?[/QUOTE]
Yep. That ought to do the trick. If you take care of 100 potential factors -- it doesn't matter if it is "99 by sieve and 1 by TF" or "90 by sieve and 10 by TF", you just took care of 100, period. That is the true measure of overall progress.

[QUOTE=TheJudger;274100]
*hmm* how do we tell the mfaktc users that the time per assignment (time per class) matters[/QUOTE]

With different builds with varying number of classes, even time per class is not that useful.

[QUOTE=Christenson;274112]I'll go further: what I really want to know is approximate wall time per factor found, assuming the usual statistics....[/QUOTE]

While meaningful in itself, this measure can't be used to compare difference in performance across two different assignments, as it is sensitive to both exponent as well as bit level being done.

[QUOTE=TheJudger;274100]Hi,

*hmm* how do we tell the mfaktc users that the time per assignment (time per class) matters, not the "avg. rate"? The hard way: remove the "avg. rate" from the status output... but I don't really like this solution.

Ideas?

Perhaps a nice text in README.txt? Does the average user even read the README?

Oliver[/QUOTE]

Maybe re-arrange the order the fields are displayed so time and ETA are the first thing the user reads and average rate is displayed further to the right along with sieve primes and avg. wait? At least for people whos native language reads left to right that' should highlight which is more important.

Leftmost data may appear more important, perhaps, but the output still lacks a simple "throughput rate" number of some kind, where users can experiment with various settings and see which "gives me the biggest number".

Just call it iteration time. All Prime95 users are familiar with that terminology so will use it to compare benchmarks.

How about garo's iteration time (meaning time per class) and the probability of finding a factor, given the exponent and bitlevel, assuming no P-1? I don't think there will be much difficulty multiplying by the number of classes and dividing by the probability of a factor to get effective rate of finding factors....