Best use of large capacitor server

[Madpoo]

Originally Posted by kladner

I think madpoo and chalsall, among others, have put a lot of effort into defining reliability, and detecting it, or the lack thereof.

One point to make, in terms of figuring out how reliable systems are, is that we often won't even have a clue how reliable a system is until at least a couple of their results have been double checked.

Given the gap between first time and double checks, that means it could be years and years before we find the bad systems. We're just now going through the 34M exponents for DC work, and many of them had their first time check back in 2008-2009. That represents the best time frame at the moment for figuring out which of those systems were spitting out bad results.

As it is right now, I've had limited success in finding machines that have been spitting out more recent results. I've found one or two, and that's only because they did a double check of some smaller number (28M - 35M) that was bad and had now been triple checked, and then they went on to do a bunch of larger first time checks in the 55M and up range.

I have a couple bad machines that I've been doing my awesome "strategic double checks" where most of their work was 55M and up, and found most of those are bad as well. But like I said, that's ONLY because they did a small double check at some point that helped us figure out how bad that system was, years and years before we would have found out otherwise.

Thus my suggestion that if a machine is going to be sticking around for a while and doing lots of work, hey, do a DC here and there and help us help you. If your machine generates crappy residues, you really would want to know, otherwise you're really just wasting your own time and murdering poor innocent electrons for no reason.

[Mark Rose]

Perhaps all new machines should be forced to complete one DC before they can take any LL work?

[Madpoo]

Originally Posted by LaurV

A random example from Chris's query, this was dropped many times, and not yer completed, and well.. not exactly random picked, I cheated a bit, I picked it because it says over 23000 (!) days till completion, so there is actually no chance that it will be completed this time either. So, expect another drop...

I just looked for exponents with a lot of "churn" (for lack of a better word). None had more than 10 expired assignments, but quite a few (593) had 9 assignments over the years that all expired. These are *JUST* double check assignments.
e.g. M37326019

Looking at exponents that haven't been tested at all yet, there's still churn but so far no exponents had 8+ expired assignments, and only three had 7 expired assignments. For the nerds:
M69314629
M69470263
M69970099

On a grander scale, ~137K exponents for DC's have been assigned and expired 2+ times. ~44K exponents for 1st time checks.

Overall it adds up to 730K assignments (just DC and LL) that were expired. It's not insignificant. 458K of those never checked in since the time they were assigned... they just got the assignment and then disappeared. Nearly 530K never checked in after a day had passed.

Summary: Yes, lots of churn. Might be interesting to see, of those, how many are from runaway users... users who have never submitted one finished assignment. (might be only 33K assignments where the user never returned anything at all... but it was a quick query so I won't vouch for it)

[LaurV]

I queued the last one for LL, because I like how the digits are arranged
Remark that the other two are already assigned for LL, as they are TF-ed to 75. This one is TF-ed to 74 only, and is currently assigned to GPU72 for TF to 75, so I can not get it "legally" assigned for LL. I tried to get it to TF by myself, from GPU72, but is not available (got a 71M instead, which I returned to the pool). Maybe is assigned already to another TF-er, or maybe the form went nuts (it happened in the past).

Chris, please reserve it for me if it is not assigned. Otherwise no problem, my p95 may grab it after it is reported as TF-ed to 75, if it is not reassigned immediately to someone else (low chances, in this range, so most probably my p95 which connects to the server once per day will get it, as it is already added to the worktodo, without the N/A key).

[Madpoo]

Originally Posted by LaurV

I queued the last one for LL, because I like how the digits are arranged
Remark that the other two are already assigned for LL, as they are TF-ed to 75. This one is TF-ed to 74 only, and is currently assigned to GPU72 for TF to 75, so I can not get it "legally" assigned for LL. I tried to get it to TF by myself, from GPU72, but is not available (got a 71M instead, which I returned to the pool). Maybe is assigned already to another TF-er, or maybe the form went nuts (it happened in the past).

Chris, please reserve it for me if it is not assigned. Otherwise no problem, my p95 may grab it after it is reported as TF-ed to 75, if it is not reassigned immediately to someone else (low chances, in this range, so most probably my p95 which connects to the server once per day will get it, as it is already added to the worktodo, without the N/A key).

I guess I just feel bad for those poor exponents... "always a bridesmaid, never a bride" kind of thing. LOL

[chalsall]

Originally Posted by LaurV

Chris, please reserve it for me if it is not assigned. Otherwise no problem, my p95 may grab it after it is reported as TF-ed to 75, if it is not reassigned immediately to someone else (low chances, in this range, so most probably my p95 which connects to the server once per day will get it, as it is already added to the worktodo, without the N/A key).

Ah... Sorry guys...

I've been busy moving several tens of thousands of litres of water back into our storage tanks.

Turns out the "Pool Guys" didn't get the plumbing correct.

Please stand by....