[FIXED] Got k=44131 yesterday!

[Troodon]

[Mon Dec 16 00:53:17 2002] logging into server
[Mon Dec 16 00:53:17 2002] login successful
[Mon Dec 16 00:53:18 2002] n.high = 1354500 . 1 blocks left in test
[Mon Dec 16 00:59:44 2002] residue: 0F669E5D04EC866C
[Mon Dec 16 00:59:44 2002] completed proth test(k=54767, n=1358563): result 3
[Mon Dec 16 00:59:44 2002] connecting to server
[Mon Dec 16 00:59:45 2002] logging into server
[Mon Dec 16 00:59:46 2002] requesting a block
[Mon Dec 16 00:59:47 2002] got proth test from server (k=44131, n=886068)
[Mon Dec 16 02:00:26 2002] block processing paused
[Mon Dec 16 16:30:18 2002] got k and n from cache
[Mon Dec 16 16:30:19 2002] restarting proth test from cache (k=44131, n=886068) [8.2%]
[Mon Dec 16 16:37:24 2002] block processing paused

Why did I get a test of a "killed" k? I'm running the win32 client.

[Bellbox]

Notice that the n you are processing (886068) is lower than the one currently found to produce a prime (995972); it's just one of the few left over tests. There is a small chance that one of these smaller n's could be prime as well, so to prove that 44131 x 2^995972+1 is really the smallest prime, we need to test all of the blocks.

[philmoore]

My understanding is that a secondary goal of the project is to verify that each discovered prime of the form k*2^n+1 for one of the 17 original k's is actually the smallest possible prime of this form. Your exponent n=886086 is smaller than the prime discovered with n=995972. Your number was originally assigned to someone else, then expired, and is now being reassigned. If 44131*2^995972+1 does actually turn out to be the smallest prime of the form 44131*2^n+1, it will be one of a class known as "Keller primes". Statistically, knowledge of Keller primes is of interest to the project in helping us guess where the next one might be.

On the other hand, further testing of numbers of the form 44131*2^n+1 with n greater than 995972 is of no direct use to the project. I would hope that a way can be found to remove such numbers from the data-base so that they will not be reassigned. In my opinion, asking participants to waste cycles and electricity on computations which do not advance the goals of the project risks turning off some potential contributors. This will become increasingly important as the size of future discoveries increases and the Proth tests which could then be discarded become quite time consuming.

[eatmadustch]

Originally posted by philmoore

On the other hand, further testing of numbers of the form 44131*2^n+1 with n greater than 995972 is of no direct use to the project. I would hope that a way can be found to remove such numbers from the data-base so that they will not be reassigned. In my opinion, asking participants to waste cycles and electricity on computations which do not advance the goals of the project risks turning off some potential contributors. This will become increasingly important as the size of future discoveries increases and the Proth tests which could then be discarded become quite time consuming.

I quite agree. Surely it must be quicker to delete these numbers from the server than to spend hours/days testing them. I wouldn't want to waste my cycles testing an unimportant number either!

[kugano]

Fixed.

What happened is that any tests for the eliminated k's which were pending, i.e. had been sent out for testing but not yet returned, weren't deleted, since doing so would've meant voiding a lot of people's work. Then, some of those tests got dropped after the tests expired, and were re-submitted into the queue for testing.

I think I've eliminated all but a very few of these, all of which have already been sent out: there are 15 tests pending for k=44131 and 89 tests pending for k=69109. Once those tests are done/expired, that should be it.

[Troodon]

OK, thanks. I'll let it finish ;) .

[Mystwalker]

As this question isn't important enough to get it's own thread, I guess I'll post it here:

According to the stats, there were no high n's handed out in the last hours/day(?). And only I got two "old" values.
Is it recycling day? :confused:

[kugano]

It is, as a matter of fact :) We changed the work expiration time from 14 days back down to 5 days. This resulted in approximately 3500 tests expiring and flowing back into the queue.

Incidentally, that's also the culprit behind the recent "canyons" in our rate graphs: since the cEM measurement varies for different n sizes, recycling this many "old" blocks has drastically dropped the average n value of tests being assigned, thus changing the average value of a cEM. Soon, cEMs will be completely replaced by a much more accurate unit.

[Jwb52z]

Does this change to 5 days mean that we can no longer just do some work every day to keep our unit from expiring? I usually only do 1 "packet" part of a unit a day.

[kugano]

Nope, it won't affect you. The 5-day expiration time means that a block is 'expired' after it has been 5 days since the server has heard from the client at all. A progress update counts, and restarts the 5-day count.

Although, I have to ask: why are you intentionally only doing 1 unit per day?

[Jwb52z]

The reason is that I divide my computer time between 4 or so different projects. When I get to be able to have more than one computer, I will not do that.

[kugano]

Ah :) Well, glad to hear SB is one of the four. :thumbs:

[shifted]

Originally posted by Jwb52z
The reason is that I divide my computer time between 4 or so different projects. When I get to be able to have more than one computer, I will not do that.

Why not just run all four at the same process priority?

[Mystwalker]

All four need memory at the same time then...

Concerning the 5 days:
Maybe a news posting would be wise - to inform the masses. ;)

[shifted]

Originally posted by Mystwalker
All four need memory at the same time then...

Well... sb uses less than 2 megs of ram. I'm not sure about your other projects.

[Mystwalker]

At least the Win32 client needs something between 6 and 10 MB... :(

[smh]

Great that the expiration time is back to 5 days :)

[Jwb52z]

With my computer, I don't think it would work too well for me to have everything I run all at once turned on at the same time. I am on a P3 500 laptop with 192 MB of RAM. The projects I run are Seventeen or Bust, Minimal Equal Sums of Like Powers, SETI, GIMPS, and DNETC's RC5-72. That would make my modem connection really slow because I'm on AOL most of the day as well. What do you think? And beore you ask, no, I can't get broadband because I live way out ini the country where there's nothiing but trees and pastures and animals like cows.

[Jwb52z]

I should have said that I also run NEO as well.

[Angus]

Mystwalker said:

According to the stats, there were no high n's handed out in the last hours/day(?). And only I got two "old" values.

Where the heck are you seeing what work units were sent out on what days, and to whom?

[Mystwalker]

I just looked at the extended statistics for a couple of hours and the max n of the "current test window" did not change. Normally, there was a noticable increase every update - like now again. :)