news

[jjjjL]

here are a couple things i've done lately

-new linux version 1.0.2
:being tested; hasn't seg faulted in 2 days yet

-main stats redo
: added a dynamic list of all k values that will update as they are assigned
: now the k-graphs that i like so much have to be accessed by clicking on the pending blocks. i think this is natural as it shows the distribution of tests between the lower and upper bounds.
: i noticed another one of those stats glitches and even though i know the exact block that caused it, i could not find a sane reason as to why it kept graphing it that way. failing a sane fix, i have made the graph software automatically ignore any single block that was processed at over a 10 million cEM/s. So far as I know, the best I ever saw was a P4 pulling around 2.5 mill cEM/s around n=3mill. By the time anyone processes a block that fast, the project will be done. ;)


-factoring
: i have been working on a way of automating the factoring process to remove pcandidates as it finds factors for them so that it can basically run in trandum with the search.
: in the mean time, i have manually removed over 100 tests before they were ever assigned by additional factoring work.


-Louie

[res0r9lm]

heck can't be any worse than 1.0.1 I have been getting seg faults a couple time an hour. finially gave up running the project until it's fixed

[nuutti]

>-main stats redo
>: added a dynamic list of all k values that will
> update as they are assigned
>

Great idea, but seems that it is not working right now. I have
k=46157 and n=692687, but stats summary page tells us that
upper bound of k=46157 is 679151.


Yours,

Nuutti

[jjjjL]

res0r9lm - my friend is also testing it. the new version will be released very soon. i know the seg faults have been frustrating... it's been loads of misery for me too. ;)

nuutti - yep. you're right. i was so busy playing with my new scripts that remove candidates that get factored before assignment that i forgot to rename a couple temporary scripts back to the dynamic ones. stats were static between 2:30am and 7:45 this morning when i noticed. they are updating with all kinds of new data again now. looks like we are testing 8 different k's now. :)


-Louie

[jjjjL]

btw, i did finish my factor update scripts. i had to learn a few things about perl and scp. now i have it so that every night at 4am the server downloads all the factoring work from the computing cluster I have here at U of M and if the work hasn't been assigned yet, the candidate is removed from the database. this can be done by hand but i was getting pretty sick of it. today it took me almost an hour to remove 100 tests. now i just have to resubmit my factoring jobs to the cluster every week to keep things going which amounts to a single command. :) oh yeah, it also already removed 400 more tests by itself so far. :D

this approah will probably amount to saving the network between 5-10% of it's power. basically we are hacking away at the problem from both ends at once now.

also, since i added the k=24737 data to the server, there will never be lower tests than the ones that are being done right now. i'm sure all the stats-whores (myself included ;)) can breath a sign of relief now that we know the cEM rate is only going up from here on out. :)

i will caveat that with a reminder that if we begin double checking large chunks of data, then it may require tests to get small again. if that becomes nessisary i will probably implement a Prime95ish scheme to allow people to choose work.

so in summary,

- a new linux version is on the way that appears to fix issues
- stats are looking decent again
- all the data for all 17 k values is loaded for n < 3,000,000
- that data is slowly being reduced by over a dozen computers that are factoring the k values non-stop and automatically updating the main database
- we have completed over 5000 full tests in the last week alone
- we have over 200 active users now in the last 2 weeks

with all this good news, now all we really need is our first prime. ;)

happy cruching,

-Louie

[Mystwalker]

All 17 k values?
Hm, does that mean that the other guys gave you their k's and start using the SB client?

Plus, trial factoring is faster than the proth test, right? :confused:
Wouldn't it be better to priorize trial factoring to save CPU power?

[nuutti]

>Plus, trial factoring is faster than the proth test, right?

Probably not when you are trial factoring only one number, but
when you are trial factoring all n's same time then it is probably
faster. That is why we have centraliced trial factoring. (I guess).
Trial factoring Mersenne numbers is very special case and it should not to compare to our project. (Mersennes have special structure for factors).

Yours,

Nuutti

[smh]

Originally posted by Mystwalker
Plus, trial factoring is faster than the proth test, right? :confused:
Wouldn't it be better to priorize trial factoring to save CPU power?

A lot of the numbers in the ranges we are testing have small factors. And why testing if a number is prime if you already know it has a factor?

I just took K=24737 with N=1 to 3.000.000 as an example.
There are 1.500.000 odd N's in this range. After sieving on a PIII 450 there are onlu 30.000 N's left after 1 minute and 26.000 after 2 minutes and i'm still removing 40 N's a second.

This rate will slow down as we try larger primes. As long as you are removing more N's in the time you can take a number of tests it makes sence to factor deeper.

[nuutti]

Of course these numbers have been trial factored very high before adding to server!!!
I am 100% sure that every number is trial factored up to 10^9
at least.

My point was that we has allready trial factored very high.
And because of that factoring only one number is not faster than doing proth test but factoring one k and varying n is. And than can be done only centrally. And Louie is doing that all the time.

Yours,

Nuutti

[smh]

Yes, most have been factored much further. See http://fatphil.org/maths/sierpinski/

I think this is sufficient for N <1M but for higher N's additional factoring has to be done.

I don't know how much cpu power is doing the factoring (sieving actually) right now, but i guess it will take at least till the end of the year before prp testing removes factors faster than the sieving on all remaining K's

[Alien88]

The Linux client will be released sometime this evening if everything continues as planned.

[nuutti]

>I don't know how much cpu power is doing the factoring (sieving
>actually) right now, but i guess it will take at least till the end of
>the year before prp testing removes factors faster than the
>sieving on all remaining K's


Ok. What is n limit and factoring limit you feel are break points / turning points when probable prime test is faster than factoring ?

Louie has published this information regarding 33661:
"As a neat side note, the largest number that ended up being factored was 33661*2^1151592+1 which is divisible by 1,001,741,106,239."

These new numbers are not factored as high. But quite High I guess. And when we are over one million (n) then Louie has factored more.

Yours,

Nuutti

[smh]

Ok. What is n limit and factoring limit you feel are break points / turning points when probable prime test is faster than factoring ?

That depends on a few things.
1) The K value
2) The range of N's
3) The hardware
4) The software

If you can do one PRP test in 2 days and if the removal rate of the sieving is 2 per day then that means that your computer is removing candidates faster by sieving then prp testing.

There probably is a fairly long period where sieving and prp-ing elliminated numbers at the same rate.

I don't know what the removing rate was when Louie was sieving around 1T. If it was higher then the same machine can do a prp test then it's worth sieving a bit longer.

[shifted]

Originally posted by Alien88
The Linux client will be released sometime this evening if everything continues as planned.

THANKS!! :)

[res0r9lm]

I linux client 1.0.2 is working great. good job :thumbs: