Reply With QuotePlease check out my last post here and let me know if this is a good idea (should give a speed boost of 2x... and not just in sieving)
It looks much nicer now.Originally posted by ceselb
Various design fixes and cleanups. Comments in the discussion thread please.Thx.
Please check out my last post here and let me know if this is a good idea (should give a speed boost of 2x... and not just in sieving)
Team Anandtech DF!
Heh, no problem. We'll soon catch up with you.Originally posted by MikeH
sorry ceselb, but I need to stay out of everyone's way for a bit
5T is quite a range, what's your rate?
My collection of about 10 PCs seems to have remained undisturbed recently, so I guess I'm running at something like 800G per week (I'll check tomorrow). So 5T should keep me going 'til the end of the year.5T is quite a range, what's your rate?
But I notice that Mystwalker is thrashing me again on unique factors in the 14 day average, so maybe I need to acquire more PCs
EDIT: Just looked at last weeks log files. I am currently crunching at 1.1T per week, but it won't last
Last edited by MikeH; 11-13-2003 at 07:40 AM.
My number of PCs varies greatly, but last weekend I had 15 systems crunching. If they wouldn't be stopped from time to time, I'd crunch along at ~ 1.8 T / week.Originally posted by MikeH
But I notice that Mystwalker is thrashing me again on unique factors in the 14 day average, so maybe I need to acquire more PCs
But I don't have access to them for 2 of 3 weeks ATM.
So assume that there are ~100-150 new factors waiting to be submitted right now.
I don't know if this is ok so if there are any complaints please lemme know before the weekends over cause I'll be starting it then
195000 - 200000 Keroberts1 [Reserved]
I'll just take a range that'll take me a few months. I should be able to finish it before the rest of ya catch up. If i can't I'll just release parts as the time nears. This range should take me about 2 months unless I manage to gain a few more resources soon (hopeful) Things are in the works.
Will ever the database of factors be available to the public, or only for people that helped calculating theme?
Perhaps it is already available, and only I cannot find it?
And second question: I understand how sieve works, but is somewhere exact alghoritm described? I'm not talking about source code, I'm interested only in mathematical alghoritm of division such big integers and preparing potential candidates for factors.
If the questions are too lame to answer, just drop three words - "use google more" and I'll get it without offense. (I did use google, but didn't find nothing but theory and Fourier transformations)
Regards,
Washuu
Washuu wrote:
I think mklasson mentions a paper about one or more such algorithms in the 'sieve client' thread. The thread is long, but probably worth reading if you're really interested.And second question: I understand how sieve works, but is somewhere exact alghoritm described? I'm not talking about source code, I'm interested only in mathematical alghoritm of division such big integers and preparing potential candidates for factors.
Hi Washuu,
Did you see Mike's page?
There, you can find a list of excluded factors, and a results.txt format file with all duplicate and excluded factors removed. Also a results.txt format file with duplicate and excluded factors marked, and user and team allocations fully identified. And of course, many cool stats.
As for the second question, I guess you will find the Sieve Client Thread useful. The discussion of the algorithm we're currently using starts with the post of Robert Gerbicz in June 8th.
BTW, welcome to the sieve.
Stats - apporx 400 kp/s on Athlon 1667 (2000+), proth_sievie_cmov v. 1.37., WinXP.
When I test NBeGon on Solaris (is it the only client that runs on this platform?) i will join to sieving again.
Regards, Washuu
PS. Please update my scores page - the range until today was incorrect.
Last edited by ceselb; 12-06-2003 at 10:45 AM.
It won't be very fast, but every bit helps.When I test NBeGon on Solaris (is it the only client that runs on this platform?) i will join to sieving again.
It's updated manually, so it might take a few days until it changes. If it hasn't updated after a week, send a PM to MikeH.PS. Please update my scores page - the range until today was incorrect.
[QUOTE]Originally posted by ceselb
[B]It won't be very fast, but every bit helps.
Hmmm... that's strange that nobody has written a good optimised client for Solari/Sparc - most of the machines are pretty fast.
I have three four-processors machines (and a few with one processor)without access to the Net, and I'm thinking about what DC project I should assign it's computing power... There aren't much choices
I chose solving Sierpinski problem, because it's _finite_, and it's general math problem - not single attack for RSA or another decipher challenge
Greetings for all,
Washuu
Sorry to say this, but no one knows if SB is finite ot not. Possibly, we can find the remainining 12 primes soon, but it is possible that a (or more) k don't have any prime at all...I chose solving Sierpinski problem, because it's _finite_
that is true but i don't think it is likely as no proof has been found showing that any of them are going to be sierpinski numbers. Although of course this is not in itsself a proof taht they aren't it shows that they can not be proved the same way others have been. Iexpect to see the problem finished but not for a good long time. Perhaps it'll pick up some speed if a new prime is found. (duhh)
hi,
I've tested proth sieve on a few different machines. And what's strange for me - Celeron 1700 MHz is slower (150kp/s) than Pentium III 1200 MHz (180 kp/s) - is sieving so much dependent on cache memory?
But what was a bad surprise for me - 900 MHz UltraSparc III with whole 8MB of cache gave only 20 kp/s with newest NBeGon (Solaris 8). Why? This machine can do much better! I compared benchmarks from Distributed.Net client on these machines and difference was much smaller.
Besides, NBeGon can't use more than one processor, but this is regrettable.
Is it possible that NBeGon was not optimised at all?
Regards,
Washuu
Hi Washuu,
if the Celeron is a PIV Celeron then it's because the FPU on PIVs is really slow, and proth_sieve makes heavy use of the FPU when doing modular multiplication.
As for NBeGon, it was indeed optimized for a while, but it's a bit outdated now.
That's because the Celeron is a Pentium4 type CPU, which often is inferior when it comes to number-crunching. Even the real P4 has difficulties to keep up - unless you're using a 800 MHz bus.Celeron 1700 MHz is slower (150kp/s) than Pentium III 1200 MHz (180 kp/s) - is sieving so much dependent on cache memory?
Oh, of course NBeGon is optimized. To be specific, it was faster than SobSieve the time it was created. But FatPhil unfortunately abandoned the development. Thus, no improvements (like prothsieve) found their way into a newer version.But what was a bad surprise for me - 900 MHz UltraSparc III with whole 8MB of cache gave only 20 kp/s with newest NBeGon (Solaris 8). Why? This machine can do much better!
Is it possible that NBeGon was not optimised at all
How does the new prime effect the efficiency of the sieving. We'll find fewer factors per range but we'll achieve a modest speed up too. Just wondering if anyone had thought about this too? I'm definatly gonna finish my range very early this time though.
There were already some discussions (as public sieving started early this year and no prime has been found till now).
There will be a visible speed increase, but the influence on PRPing and (and hopefully member count
Concerning the range discussion:
I'd advice to use the 1M-20M range, as there are only very few tests <1M that have not been secret-tested so far. And it seems like those will be done within a month.
But we maybe need another 1M-3M dat file, as some ranges are only sieved for 3M-20M.
Last edited by Mystwalker; 12-16-2003 at 06:05 AM.
We don't need every patch n < 3M sieved. I think it's more important to unify the sieve effort so it's less confusing for people who want to help and not as time consuming to post to both threads for every dual reservation.Originally posted by Mystwalker
But we maybe need another 1M-3M dat file, as some ranges are only sieved for 3M-20M.
I'm also interested in how the latest discovery will effect sieve efficiency vs PRP. Even though the sieve will run faster, it will be running on a smaller group of numbers so it won't be finding as many useful factors.
Since k=5359 was a higher density k it will remove a lot of potential numbers that could be factored. It will likely result in a net decrease in the realitive value of sieving vs PRP. I'm sure we'll see some math on it, re-evaluating the number of "useful" factors to PRP speed.
Also, there's the stats adjustments. MikeH takes into account when your factors turn out to be "useless"... which include all factors for k=5359 for n > 5M. So around 3/4 of the factors found for that k will not increase your scores.
Cheers,
Louie
it ask's for sob.dat, but i haven't one.Originally posted by paul.jobling
For those of you who are real speed-freaks, I attach a console version of the SoBSieve software. Since there is no Windoze overhead, this is about 10% faster on this NT 4 system (!).
Paul.
wbr, Me. Dead J. Dona \
I'm definitely with Louie on this one! The sooner we go to a 1M < n < 20M unified sieve effort, the better.Originally posted by jjjjL
We don't need every patch n < 3M sieved. I think it's more important to unify the sieve effort so it's less confusing for people who want to help and not as time consuming to post to both threads for every dual reservation.
Cheers,
Louie
We really need Nuri on this, but AFAIR we really don't get much "bang-for-the-buck" for 300K < n < 1M when p > 40T, and we are approaching that limit soon. There are only 6 unassigned ranges and 9 in progress. When these are finished, we could just let that reservation thread languish.
Again, IMHO an unified sieve effort for 1M < n < 20M would be very good for the project. As far as coordination of reservations, we just need to continue the 3M < n < 20M thread, with a possible name change to 1M < n < 20M.
Joe O
how long will it really take for us to reach 1 million in the double check. If the chance of a missed prime is only one in a hundred then we should only keep the double check at the point where the likelyness of finding a prime per amount of time devoted is equal. I'm not sure exactly where this is but it would require to consider the likelyness of finding a prime at current level, the likely ness of finding a prime at double check level, the odds of a prime being missreported at the double check level, and the difference in time required to perform a test. I don't have any of these values but if someone who does have some of them would like to take some time and figure the numbers on that I would be very interested in seeing the results. If the double check doesn't look like it will ever reach very far then perhaps we should just trim the sieve range to 5,000,000 plus. Of course I'd want to see the numbers before making up my mind as for what side of the issue I am on. Perhaps we'll find that the double check effort really needs to be enhanced greatly to reach optimal depths.
Please visit Mike's page for the dat file. http://www.aooq73.dsl.pipex.com/ . I guess the information on that page will make things much more clear.Originally posted by Death
it ask's for sob.dat, but i haven't one.
If you feel that anything is not clear, please do not hesitate to ask again.
PS:
- Currently, Mikael's proth sieve is the fastest client. I recommend you use one of the version 39 alternatives which fits best to your machine configuration.
- Since we've recently found a prime, the sob.dat file will soon be updated. I guess it will be announced both here and on Mike's page.
- Do not forget to reserve your range in the coordination thread(s).
Last edited by Nuri; 12-16-2003 at 05:04 PM.
How is the scoring going to change for the sieve. I expect the additional factors found for 5359 not to score but will it also be be the case that MikeH will remove the score for any tests that never actually saved a test. Or will it just be after a certain date the factors will stop scoring. I guess either would be fair just a little curious how this will effect my stats.
BTW if noone can answer my earlier question then a if anyone has a couple numbers on the factors that i mentioned then I'll see if i can do it myself. I definatly still need to get some info though.
A new trimmed and clipped sob.dat file can now be found at http://www.aooq73.dsl.pipex.com/SobDat_n1M-20M.zip.
There are now 11 ks, the n range is 1M - 20M, and all the factors discovered up to today have been removed.
I'll update the front sieving page in the next couple of days to reflect the changes.
For info, a few quick trials determined the following speed improvements:
Reduction to 11 ks: +5%
...and change nmin from 300K to 1M: +1.5%
...and remove all latest factors: +0.7%
Net gain: 7.1%
That was on an AMD XP2100+, I'm sure everyone will see slightly different numbers.
And remember to get version 0.39 of ProthSieve from http://n137.ryd.student.liu.se/proth_sieve.php
I'll need to adjust the gap analysis parameters as a result of these changes, but I'll think about that when I'm not quite so tired :sleepy:
I'm new to sieving so I have a couple of questions that might sound simple but I must ask anyway.
First I have the new sob.dat file and I am using the proth sieve ver. 0.39.
I reserved a range 33000-33050.
I started the sieve and input that range.
It created several folders factrange, factexcl, fact, and sobstatus.
Of these files what do I need to turn in on the Factor verification page and do I need to turn in anything else on any other page?
Also it seems that the proth sieve has finished that range but is continuing to process values. For the range above what is the last approximate value that should be processed?
Right now it is on p = 33052430146627 @ 584kp/s.
Also when it does finish is there anything else that I need to turn in or do I just post that the range is completed and get another?
Thank you in advance for any advice that you might have.
Hi Deoje,
Are you sure you didn't accidentally input a higher number for the end of the range? That would explain why it hasn't stopped. You can look at the "pmax=*" line (first or second line) in SoBStatus.dat. If your p is 33052430146627 now, then you've definitely gone too far. Nothing above 33050000000000 should be processed. Don't worry though, nothing terrible has happened, just a little wasted effort. Just abort the program by pressing Ctrl+C.Originally posted by Deoje
I reserved a range 33000-33050.
I started the sieve and input that range.
The contents of fact.txt is what you want to submit to the factor verification page. After you're done, post a range completed msg and reserve a new range.
Mikael
Yes. Bright clear!Originally posted by Nuri
Please visit Mike's page for the dat file. http://www.aooq73.dsl.pipex.com/ . I guess the information on that page will make things much more clear.
If you feel that anything is not clear, please do not hesitate to ask again.
Right now I download 1m-20m file and ready to start.
Just need to reserve some range...
wbr, Me. Dead J. Dona \
As you're sieving a range intended for the 300k-3M values, it's not advisable to use the 1M-20M SoB.dat file.Originally posted by Deoje
First I have the new sob.dat file and I am using the proth sieve ver. 0.39.
I reserved a range 33000-33050.
As I took it, you've already finished that range (though it is unclear why prothsieve didn't stop). Maybe a look into the SoBStatus file can give us some insight.
Anyway, just post the results (as mklasson said) and reserve new ranges here (1M-20M search):
http://www.free-dc.org/forum/showthr...&threadid=3501
Hello all,
I'll be away from my siever for two weeks, and would like to sort this out before I leave tomorrow. I've reserved a 2+T range, mostly undone, for both managed ranges. Is it worth continuing the range of 300k-1M? I'd like to switch to the consolidated 1M-20M file and unreserve the remainder of my range in 300k-3M. How much more sieving do we really need for the lowest n's?
Thanks, and happy holidays to those that celebrate them.
chris
The choice is really yours. Whether you are more comfortable using the new sob.dat file, or modifying the old one.Originally posted by cmprince
Hello all,
I'll be away from my siever for two weeks, and would like to sort this out before I leave tomorrow. I've reserved a 2+T range, mostly undone, for both managed ranges. Is it worth continuing the range of 300k-1M? I'd like to switch to the consolidated 1M-20M file and unreserve the remainder of my range in 300k-3M. How much more sieving do we really need for the lowest n's?
Thanks, and happy holidays to those that celebrate them.
chris
The modifications are:
1) Changing 12 to 11 on the first line
2) Deleting the line containing "k=5359" and all the following + lines, up to but not including the line containing "k=10223 "
While there is some value in sieving 3K < n < 1M, it's value is diminishing daily and there is about 1% speedup in dropping it. These values are relatively easy to PRP, and all of them up to about 850000 have been checked at least once.
The major speedup, about 5% comes from dropping the 5359 values.
Again, the choice is yours.
Joe O
I won't start until I was sure I'm doing right.
So, after reserving a range I must run proth_sieve.exe and enter this numbers?
First 162000, then 164000 and wait until it stop?
Then submitting results over sob.com/sieve
moved /ceselb
Last edited by ceselb; 12-19-2003 at 02:20 AM.
wbr, Me. Dead J. Dona \
Just to clarify, my previous post in reply to cmprince . I was talking about using the new 1M < n < 20M sob.dat file vs using the old 300K < n < 20M sob.dat file after modifying it.
I strongly urge anyone using a 3M < n < 20M sob.dat file to download and use the new 1M < n < 20M sob.dat file. I feel that this will benefit both you and the project. You, by speeding up your sieve, and the project, by sieving the optimal n range. Those of you using the 300K < n < 20M sob.dat file after dropping 5359 will sieve the optimal n range+ with almost no penalty. Maybe 1%, maybe less. The important thing is to cover at least 1M < n < 20M, for the remaining 11 k.
Joe O
since it is not just unlikely that we'll ever have enough resources devoted ot double checking then perhaps we should just abandon it or now and concentrate on looking in the main active region for primes. Have any of the double check tests even reported a differeing residue? Sieveing between 1million and 5 million seems pointless. How is the double check ever going to catch up to that. And still i nthe mean time we may find more primes and the time spend sieving adn prping those ranges would just be additional waste.
(In response to Death)
yup right on. All you have to do when its done is copy and paste the contents of fact.txt to the sieve submittion window and the factors will be saved. Just remember to log in first. Also if you look at the fact. txt file adn see any factors that you hink may be about to get passed by the prp line then you should do your best to submit them as soon as possible. Resubmitting old factors will not cause any problems.
moved /ceselb
Last edited by ceselb; 12-19-2003 at 02:21 AM.
Ok thanks for the help. When I turned in the results from the fact.txt and it said 30 of 30 verified but no new results. I guess thats what it should say?
Also should I save the contents of the other files; factrange, factexcl, sobstatus for any reason or should I just clear them out? And is there any reason to keep the contents of fact.txt?
I guess I must have entered the wrong upper range when I started. I will have to pay more attention in the future.
Also if anyone knows what kind of speed should I be getting?
I'm using an AMD 2800+ Barton, with 1Gig of ram.
The speed I've gotten range from approximately 580kp/s to 620kp/s.
I'm using the proth sieve 0.39 windows comv.
Also that's the correct version to be using right?
Just curious to see if the speed Im seeing is what it should be.
Do AMD or Intel processors perform better on the sieving client?
I have a Pentium 4 2Ghz, with 768mb of ram that is running the sob client but it does not perform terribly well on that. If it would perform better using the sieving client I could switch the two machines.
Last edited by Deoje; 12-18-2003 at 03:06 PM.
Deoje:
AMD is the king of the sieve and P4 is the king of PRP testing.
You would be better off to continue using your P4 for the sob client. Even PIII performs better than P4 at sieve (just for comparison: PIII-1000 @ 270kp/s and P4-1700 @ 170kp/s).
The speed you get seemed pretty reasonable to me.
proth sieve 0.39 windows cmov is the right version for AMD.
I think you had a problem regarding your range. Normally, when you submit your factors, you should get something like:
19 of 19 verified in 1.71 secs.
18 of the results were new results and saved to the database.
I guess I understood the problem you encountered.
Sieve coordination (300K - 3M) thread is just for patching of some uncompleted factors with n values within the range 300K and 3m. Since you've used the 1m<n20m dat file, you've found factors that were already known. No big deal anyway, only a loss of one day's work.
Pretty soon, we will not be using that thread anymore.
You should use Sieve coordination (3M - 20M) with the new 1M < n < 20M sob.dat file you are already using. That will solve your problems.
Also, if you've not done yet, I recommend you download and use Mikael's sobistrator as well. This will ease things (please note that it needs MFC71.dll, msvcp71.dll, and msvcr71.dll to run. You should normally have them, but if not, it's easy to find over the net).
When you start to use sobistrator, you will see that you will not have to deal with the contents of fact.txt, factrange, factexcl, sobstatus etc.
I hope I could answer your questions. Please do not hesitate to ask if you have any more. And welcome to the sieve.
Joe,
Thanks for your analysis. I actually did try to edit the .dat myself, but it crashed. Further reading indicates I might not be using v0.39, so I'll try that again. It just made me even more hesitant to use a "non-standard" .dat. If I can make the .dat edits with v0.39, I'll continue the range from 300k, then move to 1M-20M on my next range.
------------------------------------------
Keroberts1,
I'm not sure, but I would think that as the length of each of the tests runs longer and requires more blocks to process, the chances of a computational error goes up. I think GIMPS had a false positive before their most recent success, and that they end up needing a third tie-breaking test on a small but significant number of exponents. So I think sieving from 1M is still definitely worth it for such a small penalty.
Posting Permissions
