OFFICIAL "SERVER PROBLEMS" THREAD

[Madpoo]

Originally Posted by retina

It must be a new hidden prime discovered in there!

LOL... yeah, in the last 3 of the range. I wish.

But seriously, this summary report is *the* one part of the website that I was really afraid to touch too much because the code that generates all that data is scary to me. It's weird and complex and hard to follow.

I'm staring at it more now than I ever had previously and I remember why I didn't want to mess with it before. LOL

The good news is, the count will only be weird for a little longer until these last 3 in the range are done.

[retina]

Originally Posted by Madpoo

The good news is, the count will only be weird for a little longer until these last 3 in the range are done.

Maybe, until more of the same error are uncovered in the future.

It seems to me (and presumably others) that the data are wrong. How can we be sure the other data are not also wrong? Don't you wanna fix the errors and have confidence that nothing is missed?

[retina]

57000000 55901  1 | 35999   151 19747           3 |                 3    43 |                   19704 |

'3' == '3'.

[snme2pm1]

Originally Posted by Madpoo

The good news is, the count will only be weird for a little longer until these last 3 in the range are done.

Or, unless repaired ... It might have looked ugly if the "2" became a "-1".

[Madpoo]

Originally Posted by retina

57000000 55901  1 | 35999   151 19747           3 |                 3    43 |                   19704 |

'3' == '3'.

George found the problem and fixed it. It was a relic of the way primes were stored in the results table or something like that, and the code to generate the report wasn't taking that into account for primes discovered in the past few years.

He mentioned that not only would the 57M range be correct now, but also some stats on the 42M range.

[snme2pm1]

Originally Posted by Madpoo

George found the problem and fixed it.

I suspected that would be the way of things from your expressed difficulty to grasp the code semantics.
I had imagined that there were colours added to column dividers of that venerable table, but perhaps it was an aberration of the remoting facility.

[Madpoo]

Originally Posted by snme2pm1

I suspected that would be the way of things from your expressed difficulty to grasp the code semantics.
I had imagined that there were colours added to column dividers of that venerable table, but perhaps it was an aberration of the remoting facility.

You're talking about this page, right?
http://www.mersenne.org/primenet/

There shouldn't be any colors at all in the columns. Must have been something funky going on with the browser, I guess.

And yeah, when it comes to some of the data on the site and database, I'm still a little lost about things. I try to offload what I can from George and avoid bugging him, but sometimes it's inevitable.

[snme2pm1]

Originally Posted by Madpoo

You're talking about this page, right?
http://www.mersenne.org/primenet/

There shouldn't be any colors at all in the columns. Must have been something funky going on with the browser, I guess.

And yeah, when it comes to some of the data on the site and database, I'm still a little lost about things. I try to offload what I can from George and avoid bugging him, but sometimes it's inevitable.

Yes that is that URL in question.
When I view that at via TeamViewer at a remote location I see various colours at the "|" symbols.
I initially imagined that having got a new glimpse of the code behind this table that you couldn't resist the urge to spice it up somewhat.
It is probably the only remaining table that has not suffered a serious face-lift in the last year of your revolution!

[James Heinrich]

Originally Posted by snme2pm1

When I view that at via TeamViewer at a remote location I see various colours at the "|" symbols

Probably aliasing artifacts from viewing the page at scaled resolution?

[Mark Rose]

I found a bug with the /manual_gpu_assignment/ page.

As a little mini project, I decided to do all the DCTF above the GPU72 range, so above 58M. I encountered a problem when using the following settings for the form:

Number of assignments you want:  , or GHz-days of work you want: 500
Preferred work range: TF for double-checks
Optional exponent range: 80000000 to 84000000
Work preference: Lowest exponents
Optional bit level to factor to: 74

Sometimes the form gives assignments with no LL work, only expired PM1-L work, such as M80017243, or exponents with no work at all.

The expected behaviour would be for it to return no work, unless I'm misunderstanding something.

[Madpoo]

Originally Posted by Mark Rose

I found a bug with the /manual_gpu_assignment/ page.

As a little mini project, I decided to do all the DCTF above the GPU72 range, so above 58M. I encountered a problem when using the following settings for the form:

Number of assignments you want:  , or GHz-days of work you want: 500
Preferred work range: TF for double-checks
Optional exponent range: 80000000 to 84000000
Work preference: Lowest exponents
Optional bit level to factor to: 74

Sometimes the form gives assignments with no LL work, only expired PM1-L work, such as M80017243, or exponents with no work at all.

The expected behaviour would be for it to return no work, unless I'm misunderstanding something.

George or James could comment better, but as far as I know, if there isn't any available work given the options, I think it starts falling through and finding similar work. At least, that was my understanding when I glanced at the usual assignment code a while back, but I wasn't looking at the gpu assignment page which could be quite different.