[QUOTE=blip;415121][B]2[/B]

we are speeding up ...[/QUOTE]

Umm... hmm... we're actually slowing down, but unless you looked at the milestone page daily and made a note of the ETA, you wouldn't notice.

Reason being, this guy: [URL="http://www.mersenne.org/M58702333"]M58702333[/URL]

The person assigned that test has been VERY slow with the progress. Since it was assigned on Sep 19, it's done this:
2015-09-25 - 2.9%
2015-09-26 - 8.9%
2015-09-27 - 10.5%
2015-10-03 - 10.6%
2015-10-04 - 11.8%

And since Oct 4, it's been stuck at 11.8%. It checks in daily, but hasn't moved the progress at all, it just bumps out it's own ETA by another day each time.

At this point it has a rolling daily average progress of only 0.178% per day and wouldn't finish until March 2017. Of course, it went in fits and bursts at first and then nothing for over a month, so who knows...

The other <59M exponent (M58970231) has been doing okay. Average is 1.7485% per day and I calculate a real ETA of Dec 5 (different than it's own estimate of Nov 28 by just one week). But it also goes in fits and bursts... it's at 61.3% now and it's been at that same % for a week... zero progress in one week. Hmmm... But still reports in daily. Go figure.

Hopefully they pick up the pace otherwise I just know someone's going to poach them. I'm not sure about the expiration rule for something like this where they continue to check in daily with zero progress... I don't remember what the assignment age limit is, but if it's 90 days, we could be waiting a while longer. Dec 18 for the first one, Jan 2 for the other.

So, if the folks running those read the forum, this is for you: Pick up the pace. :smile: Don't let these expire before you finish (or someone poaches).

[QUOTE=Madpoo;416272]Just blame solar radiation. :smile:

Seriously though, I wonder if it has anything to do with the size of the exponent and the FFT it uses, or something weird like that. Your result didn't have an error code but the other bad result did (a repeatable one though, so it wasn't marked suspect).

You're right though that ECC and a stable, non-OC'd system should be expected to run flawlessly, so I guess I'm back to solar radiation, or gremlins, or whatever. :)[/QUOTE]

ECC only protects against a single bit flip. Bits can also be flipped outside of main memory, too.

[QUOTE=Mark Rose;416277]ECC only protects against a single bit flip.[/QUOTE]

Not entirely true.

Some ECC implementations can recover from a single bit flip, and can detect two bits flipping in a "word". The latter produces an exception (which often results in a halt).

[QUOTE=Mark Rose;416277]Bits can also be flipped outside of main memory, too.[/QUOTE]

Absolutely.

In the early days of "copy protection" magnetic media (read: floppy discs) were encoded with an "off-on" (fon) bit or sector. Half the time they would read one, the other half they would read zero. Very quickly, of course, the "breakers" would simply comment out the test code.

[QUOTE=chalsall;416279]Not entirely true.

Some ECC implementations can recover from a single bit flip, and can detect two bits flipping in a "word". The latter produces an exception (which often results in a halt).
[/QUOTE]

The HP servers I use are like that. Single bit detect/correct, and two-bit detect (throw error).

As you mentioned, the usual thing that happens is when a 2-bit error is detected, the system will halt/blue-screen/whatever. Correctable single-bit errors get logged and you'll be nagged that something's wrong.

I think there are some caveats to the way it works, like the errors would need to be on the same module or maybe even the same physical chip... I don't recall the details.

Either way, it's rare to have 2 bits fail and you [I]don't[/I] have some kind of indication like a BSOD. It could happen though.

Vaguely related: [URL="http://rick.vanrein.org/linux/badram/index.html"]A neat trick for bad memory[/URL]

1 ...

[QUOTE=blip;417993]1 ...[/QUOTE]

Another case of someone finishing a cat 1 assignment late, after being recycled to someone else. The user finished the assignment in 165 days, so it was 75 days past the 90-day limit.

[QUOTE=blip;417993]1 ...[/QUOTE]

This is the one that came in:
[URL="http://www.mersenne.org/M58702333"]http://www.mersenne.org/M58702333[/URL]

My first thought was "joe-dal" got impatient, poached it. (I don't think "Spin" was going to finish anyway, to be honest).

Turns out, "joe-dal" had an assignment for that going way back to June 20, it expired, but it kept plugging away anyway. It happens.

I guess I should be surprised that "Spin" was assigned a priority exponent at the time (September) and then didn't work on it like they should have. That user does have the preferred assignment bit checked. This could be one of those cases to show why we should uncheck that when they're not living up to the promise they made to work on them.

It may also be that Cat-1 is not strict enough with past performance, queues, and the like.

Does the latest addition to the milestones page show some DB corruption?
[code]# Countdown to first time checking all exponents below 62M: 275 (1 still unassigned)
# Countdown to first time checking all exponents below 63M: 509 (3 still unassigned)[/code]Checking the [url=http://www.mersenne.org/primenet/]hourly report[/url] does not show any exponents in those ranges as available.

[size=1]I am aware of the different schedules that these pages are updated. But this has persisted for more than a few hours now and the milestones page always shows that number exponents waiting to be assigned.[/size]

I note that the highest sub-60M exponent remaining for first LL testing got recycled. With the new assignee of [url=http://www.mersenne.org/M59969537]M59969537[/url] having an ETA of 46 days, I think it's unlikely that the new assignee will beat the old assignee to completing the test. The old assignee was at least 92.7% done with the test.