OFFICIAL "SERVER PROBLEMS" THREAD

[ramgeis]

I submitted the test results for M96999043 and M96999083 but both still show up as assigned to me:
https://www.mersenne.org/report_expo...6999043&full=1
https://www.mersenne.org/report_expo...6999083&full=1
Also in the account assignment details. Weird...

[GP2]

Originally Posted by ramgeis

I submitted the test results for M96999043 and M96999083 but both still show up as assigned to me:
https://www.mersenne.org/report_expo...6999043&full=1
https://www.mersenne.org/report_expo...6999083&full=1
Also in the account assignment details. Weird...

Were these done with mprime or with gpuOwL? Maybe this is an issue for manually submitting gpuOwL results?

The cure would be for someone to do PRP double checks, but those are big exponents.

Alternatively, you could try de-assigning them in your account assignment details page.

[ramgeis]

Originally Posted by GP2

Were these done with mprime or with gpuOwL? Maybe this is an issue for manually submitting gpuOwL results?

The cure would be for someone to do PRP double checks, but those are big exponents.

Alternatively, you could try de-assigning them in your account assignment details page.

No, I manually submitted the results done by Prime95 from a machine with no connection to the outside world.
Of course I can delete my assignment, but that doesn't make the problem go away.
I just wanted to raise the awareness of an issue on the server side.
I'll definitely have a look at it again when I submit the next results...

[S485122]

I wanted to find why there would be a lone unknown exponent in the 77 to 78M range.

- The Detailed report / Exponent status is not outputing correctly in text-only format : when pasted the lines are missing an end of line character. One can use the text-only report if one goes through "view source". I abandoned the idea of doing this 56 times :-(

- Another query brought out an anomaly : I used the PrimeNet Known Factors of Mersenne Numbers, counted the factored exponents and found 35813 and not 35812 as stated in the PrimeNet statistics page. With 35813 the numbers tally.

Could it be that all the manipulations to hide new primes are the cause of that kind of errors ?
Since people get more and more adept at finding them as soon as the news of a new prime is out, the changes done to hide them have gotten more complex. Perhaps not all changes have been undone (in this range and in others...)

Jacob

[ramgeis]

Originally Posted by ramgeis

No, I manually submitted the results done by Prime95 from a machine with no connection to the outside world.
Of course I can delete my assignment, but that doesn't make the problem go away.
I just wanted to raise the awareness of an issue on the server side.
I'll definitely have a look at it again when I submit the next results...

It happened again with M96999191 and M96999193. I can't imagine that it is supposed to work this way.

[kriesel]

Originally Posted by ramgeis

No, I manually submitted the results done by Prime95 from a machine with no connection to the outside world.
Of course I can delete my assignment, but that doesn't make the problem go away.
I just wanted to raise the awareness of an issue on the server side.
I'll definitely have a look at it again when I submit the next results...

It seems to be a generic issue; it's occurring when manually submitting gpuowl results.


Folks are busy, & I assume they'll get to fixing it eventually.

[chalsall]

Originally Posted by kriesel

Folks are busy, & I assume they'll get to fixing it eventually.

At the same time, it's a bit embarrassing.

The Milestones report says everything below 78,413,429 has been tested at least once.

And yet the Work Distribution Map shows there is still a 77M needing a first time check.

These are simple SQL queries.

Why is there still inconsistency?

[kriesel]

Originally Posted by ramgeis

No, I manually submitted the results done by Prime95 from a machine with no connection to the outside world.
Of course I can delete my assignment, but that doesn't make the problem go away.
I just wanted to raise the awareness of an issue on the server side.
I'll definitely have a look at it again when I submit the next results...

It seems to be a generic issue; it's occurring when manually submitting gpuowl results.


Folks are busy, & I assume they'll get to fixing it eventually.

[Mark Rose]

Originally Posted by chalsall

These are simple SQL queries.

That would be the case if the schema were correctly designed. But I have a feeling that's not the case, as usage has evolved over the years.

[chalsall]

Originally Posted by Mark Rose

That would be the case if the schema were correctly designed. But I have a feeling that's not the case, as usage has evolved over the years.

Please forgive me for this, but as you know SQL handles AND and OR statements really quite well.

"SELECT COUNT(*) FROM exponent WHERE (state=1 OR state=5) GROUP BY exponent%1000000" works fine, for example. And uses cached indexes.

I would swear to make my point, but there's little demonstrated upside....

[Madpoo]

Originally Posted by Mark Rose

That would be the case if the schema were correctly designed. But I have a feeling that's not the case, as usage has evolved over the years.

It's not necessarily that it's hard to come up with queries that get the right results, it's just taking the time to do it... which, for me, means researching where the existing queries live, how they work, and then figuring out how to mod it to include the PRP results (which live in their own table... it's different work than LL and was added *way* after the fact, so yeah... it has its own home )

Since adding PRP to the site, I hope folks appreciate that adding a new feature like that and then going back through and fixing all kinds of reports behind the scenes is one of those things with lots of moving parts. Personally I didn't really mind thinking that it would be done here and there as time permitted. Y'all are just impatient. LOL