As for score... You bascially get close to zero I.E. no points
a typical factor within the currrent sieve window gets
~3,000 points for secondpass
and >150,000 points for a firstpass factor
The factors we submit get score = p/1T doesn't matter if it's above below first or secondpass or even if it eliminates a test from being done. So what this means is we get a score equal to the p in T.
So currently about 20 points for a factor, we are not interested in scoreing whatsoever its not what our effort is about.
how do you submit them
Well not easily, since the minimum sieve p-value sometimes changes we are very careful with our submissions and make sure they go through. Often times Joe_O submits more than once and we have ways of telling if they were applied correctly, such as this page http://www.seventeenorbust.com/secret. WE also submit them in large batches.
Also those factors above 20M are not recorded by the server at all!!!
We are personally collecting them archiving them in several places by two or more people, and we will send them to Louie, Kungao, when they decide to start testing/sieving above 20M.
People may not get personal credit for those tests done above 20M currently but we are recording who did what, which is why people are testing in blocks of 1T (1000G). It is possible to get personal credit for those below 20M if the user chooses. I and the other personally don't care much about a few 100 points, we get Joe to submit almost everything on our behalf.
Here is a list of our most recent factors, as you can see a little over 200 factors score less than 2000 points. Notice that these are all factors above doublecheck 1.5M.
If anyone wishes to join this group they are very, very welcome.
You can send an email to factrange at yahoo dot com and I will send you the yahoo invitation to make it easier to join this group.
Use this dat for ranges reserved in the ordinary way. Submit fact.txt in the usual way and then send it and factrange.txt to factrange at yahoo dot com so that we can process the factors over 20M.
Joe O,
When you try to join this Yahoo Group you are presented with a security word verification thingy to type in. It is very hard to decypher. It took me 3 attempts until I managed to work it out as there are stray bits of serifs etc that messup the word. Also, since when does a word contain a numerical character? Perhaps it should be rephrased as "enter security code" instead of "word verification".
Originally posted by vaughan Joe O,
When you try to join this Yahoo Group you are presented with a security word verification thingy to type in. It is very hard to decypher. It took me 3 attempts until I managed to work it out as there are stray bits of serifs etc that messup the word. Also, since when does a word contain a numerical character? Perhaps it should be rephrased as "enter security code" instead of "word verification".
I have no control over that. That is Yahoo's attempt to keep out 'bots'. That is why I also offered to send an invitation that bypasses that to anyone who emails me.
We would wish that everyone reserve in increments of 1T (1000G, 2000G, 3000G, etc), this helps us in several regards. Also if you wish to reserve a large chunk please try to finish it in less than 2 months.
If you wish to simply try out the new dat on a 50G range etc your more than welcome to do so. However please reserve maineffort ranges through the normal channels and using the 991<n<50M dat instead.
The 991<n<50M dat will find all of the factors the current dat 1.6M<n<20M normally would, however it is about 15% slower but also finds factors above 20M and below the minimum threshold.
We have been finding many missed factors within the 1M<n<20M range based on the lower p-values we have already searched.
As one can see from Joe's post, so these efforts are far from useless.
Thanks and I welcome all the new faces, please post your comments/experiences here, good luck and happy sieving.
I would like to, but I am right in the middle of a range that won't be done for 30 days or so. Also, the company I work for is going to be phasing out all of the machines I am sieving with soon! They will be replaced with P4s with Win XP Pro. I know that sieving with a P4 used to be a waste of time. Is it still that way? If the SSE2 sieving client fixes that problem, I may continue to use 2-3 of these machines for sieving.
So, I will probably finish up the ranges I currently have reserved, then go either into PRP or P1 factoring. I can wrap up the uncompleted reserved ranges with one of the machines I have at home.
Originally posted by Stromkarl If the SSE2 sieving client fixes that problem,
I don't know if proth_sieve_sse2 "fixes" the problem, but it is faster than proth_sieve_cmov on two SSE2 capable machines that I have tried it on.
While the choice of what you run remains entirely up to you, I would like to urge you to strongly consider P-1 factoring, if sieving is inefficient on the machines available to you. Prime95 version 24.6 continues a long tradition and does a very good job of P-1 factoring of k*2^n+1.
The worktodo.ini entry
Pfactor=4847,2,2005647,1,43,3
gives us in results.txt
[Sun Oct 17 12:08:06 2004]
4847*2^2005647+1 completed P-1, B1=35000, B2=455000, WZ1: 33F53785
By the way, I would recommend changing the name results.txt to factors.txt or some other name to prevent conflict with SB's results.txt file. You do this by putting a line in prime.ini:
results.txt=your_filename
Originally posted by Joe O I don't know if proth_sieve_sse2 "fixes" the problem, but it is faster than proth_sieve_cmov on two SSE2 capable machines that I have tried it on.
At least on Intel (I have no AMDs to try it out, but am pretty sure it holds here as well) SSE2-enabled CPUs, the SSE2 version is ~10% faster than the CMOV one.
When the FSB is clocked at 800 MHz, sieving speed is "not bad" - but not good either.
I'd also suggest P-1 factoring resp. normal PRPing. The P4s fly in these fields.
I'm thinking about getting involved in the 0-50M sieving. I finish a range in the next couple of weeks. I have a few questions to ask.
1. I've estimated that I'll be taking about 2 months to do a 1T range, based on my current sieving rate, and reducing the speed by 15%. Would this be a problem?
2. I gather this sort of sieving finds some factors missed by the 0-20M range sieving, but how many are found? In particular, how does this compare with the number found through sieving 0-20M currently happening?
3. Would I just use prothsieve as usual, but with the different dat file?
4. How would I submit factors? Would I just e-mail you all the factors?
5. Do the range reservations happen on the yahoo site you mentioned?
I've tried sse2 on a p4 it is better than it was before... when you compare both sse2 and cmov on a athlon64 the speeds are almost identical.
The problem is not the client it's the processor P4's just don't sieve well it has something to do with the pipeline? Regardless, it's not a waste to sieve with a P4 compared to doing nothing but for SoB your really better off putting those into prp or factoring.
If it were me I'd basically put all of those machines on secondpass prp. The only two machines I don't have running sieve are on the garbage account. For work you might be best off simply starting sob as a service and forgetting about it. Factoring works and is probably the most benfital but it's manual like sieve.
1. I've estimated that I'll be taking about 2 months to do a 1T range, based on my current sieving rate, and reducing the speed by 15%. Would this be a problem?
Yes the 15% estimate is still accurate and no 2 months is not really a problem at all. The major point is we are trying to progress quickly through these low T.
2. I gather this sort of sieving finds some factors missed by the 0-20M range sieving, but how many are found? In particular, how does this compare with the number found through sieving 0-20M currently happening?
Well this really depends on how many are missed. Currently we are very sure we are finding all factors that were missed b/c we have identified problems of why they were missed in the first place.
As for the number of factors found this depends on the range. Sometimes you get lucky... I havn't done the calculations recently but there have been ranges that produced more factors per g than first pass sieve. (perhaps Joe can give you exact numbers)
The other option of course is to sieve a high n range with the 991<n<50M dat this would be benifital to both projects, bascially your getting the high and low n work for a 15% overhead...
3. Would I just use prothsieve as usual, but with the different dat file?
Everything is the same except where you get the dat, the dat is downloadable through the group. I'll try posting it in this message but I think it's too large.
4. How would I submit factors? Would I just e-mail you all the factors?
Factors for n<20M are accepted through the website as usual once the range is finished zip fact.txt and factrange.txt and e-mail it to factrange@yahoo.com
5. Do the range reservations happen on the yahoo site you mentioned?
Yes they happen on the group, but I could assign you a 1T range if you wish.
Originally posted by Silverfish I'm thinking about getting involved in the 0-50M sieving. I finish a range in the next couple of weeks. I have a few questions to ask.
1. I've estimated that I'll be taking about 2 months to do a 1T range, based on my current sieving rate, and reducing the speed by 15%. Would this be a problem?
2. I gather this sort of sieving finds some factors missed by the 0-20M range sieving, but how many are found? In particular, how does this compare with the number found through sieving 0-20M currently happening?
3. Would I just use prothsieve as usual, but with the different dat file?
4. How would I submit factors? Would I just e-mail you all the factors?
5. Do the range reservations happen on the yahoo site you mentioned?
Thanks in advance.
1) 2 months is not too bad. Submit every 250G or at 500G so we can monitor your progress.
2) How many are found depends on the range. Take a look at my graph a few posts up in this thread (on the previous page).
3) Yes you would use the same prothsieve, but with the 991-50M dat. See my post above for joining the Yahoo Group where we make it available.
4) Since your range would be above the 25T mark, you would submit your fact.txt in the normal way AND then email it with your factrange.txt to factrange at yahoo dot com.
5) Yes the range reservations for our high N/resieve effort happen on the yahoo site.
Having said that, there is another way that you could participate in our effort. Especially if you are leery about the 1T restriction we need to maintain. And/Or would like to help us but want to help the primary sieve more directly. Just reserve a normal range in the normal way. Use the 991-50M dat instead of the smaller dat.
Then you would be doing a normal range, just 15% slower, and you would be helping out the high n effort as well. When you are done, you would submit your fact.txt file in the normal way and then email it to us along with your factrange.txt file. There is no need for a second reservation, I would take care of that when your files arrive.
Edit: Looks like VJS types faster, or started before I did!<Grin>
This range basically represents 2 days of sieving so was sieving this range fruitful from an SoB standpoint?
Well considering these values would probably only have to be checked one more time. My machine could have probably tested all four of these values in the same time period, so from that respect I broke even with the 1<n<20M range.
However when you consider all of the factors, I also found these... Which would probably take me more than a year to test just once.
YOu can switch to the large dat at any point and time.
Joe and I are pretty good and determining which dat was used and where... of course you could make it easy for us and tell us exactly where you left off or started with each dat. :-) (round numbers are not required for main ranges anyways.)
What will probably end up happening eventually is everyone switching to a higher n dat. At that point Joe and I will do a little secretarial work and post the ranges completed on the new reservation thread.
I've just started on the 0-50M dat, for the last 80G or so of my current range. I made a note of the last pmin figure in SobStatus dat file, before I changed to the 0-50M dat, and I'll send you that with the factors from the range when I finish it.
Another question though, are you interested in the factors in factexcl at all? I'll be submitting the 0-20M factors in the normal way, but what about those >20M? I suspect there won't be very many, but I just thought I should check. I 'll probably keep them anyway, so I can analyze the stats later on.
Basically don't worry about factexcl.txt it doesn't contain any new factors eliminating k/n pairs from the dat.
Joe and myself have been keeping factexcl.txt thus far b/c it may contain some useful information for factoring purposes later but not likely. In any regards this file won't help SoB finish any faster.
What's most important is that you submit fact.txt and factrange.txt, all of fact.txt is useful and a little more than 10% of factrange is also usefull.
This is probably a good idea but we would have to convince Mike. The file is ~2.5x larger than the regular dat not sure if bandwidth is an issue for him.
In the meantime if anyone wants the dat and doesn't want to jump through yahoo hoops and loops just PM me with your e-mail.
For those of you using the 991<n<50M dat, the server will correctly record and assign credit for those factors n<20M however those above 20M are simply ignored. Currently no factor with n>20M is recorded by the server.
In order for these to be recorded please submit them to factrange@yahoo.com
This method is working well, since we don't require those factors immediately. Once you have entirely completed your range please mail the fact and factrange.txt files to factrange@yahoo.com.
The prefered format is as follows
Both files zipped together with the following name.
Sieve range 991-50M username.zip
Example,
810000-815000 991-50M VJS.zip
So far this has not been a problem but we are getting quite a few new users with the 991-50M dat and I just wanted to mention it again.
Of course we are still accepting factrange files as well for those of you processing with the 1.7M<n<20M dat. For these submittions please include "factrange" in the subject line.
On a sidenote,
You are encouraged to submit fact.txt to the server first or as you progress through your range. However intermediate submissions to factrange@yahoo.com are not required.
Thanks to all of those who are participating in the main effort with this dat. I'd also like to note that we are still finding some missed factors n<20M with resieving and the 991<n<50M dat at low p double check. From a sieve standpoint double check sieve is still worth the effort by far. We will inform users if this situation changes.
Expect to see more low-p missed factors appearing on Mikes pages in the near future.
A note on scoring...
Finally we are assigning ranges above 40T in doublecheck sieve. These missed factors will now score upwards of 10K points. This is significatly better than current second pass factor scores and especially better than the scores for those factors p<40T.
Originally posted by vjs
Thanks to all of those who are participating in the main effort with this dat. I'd also like to note that we are still finding some missed factors n<20M with resieving and the 991<n<50M dat at low p double check. From a sieve standpoint double check sieve is still worth the effort by far. We will inform users if this situation changes.
This is a graph of our most recent n <20M found factors for low p double check.
Your comments basically describe the ultimate plan and I believe we are close to that point. However it will be the decision of Louie as to the acceptance of these factors...
Let me comment on some of your points as a whole:
First independant of the sieve range the user decides to sieve with the 991<n<50M dat, be it p=40T or p=800T (current sieve ranges) Mikes pages and the server will accept and score all factors p>25T (which we are now above with second pass) and n<20M.
This is good since we are still quite a ways away from testing n>20M but those found n<20M are automatically applied and score.
Your comment about server space, who gets the factors, etc... add to this; factor verification, testing for gaps in sieved ranges, co-ordination, and Louie and other being busy updating the dat etc.
This can be summed up in the efforts which have been done so far.
First a tremendous numbers of factors have been found thus far p<40T, as a matter of fact we have collected over 500Mb of factor files. You can see how this sheer number of factors would cause a problem for the server, automation, and updating of the dat in the past.
Joe has done a fantastic job updating the 991<n<50M dat we are currently using. I believe he said at one point it took his machine 4 hours to process one large factor submission of mine. You can see that such a submission to the server and 100% load for 4 hours would be a problem.
This is part of the reason Louie doesn't accept factors p<25T or n>20M and why they are not reported.
Another thing to consider is the number of factors found per G sieved decreases with increasing G. Hence, now that we are abouve 25T the number of new factors found drops off and so does the load on the server with importance of updating the dat. (991<n<50M dat has decreased in size from >27Mb to <8Mb).
A 8Mb dat isn't really an issue anymore, consumes <32Mb of machine memory and its size is not that difficult to work with or transfer.
This was the point we are tring to get too (25T) perhaps it is still too soon but trying to do this effort through the server for p<25T would have been a nightmare.
Regardless now may be time for the project to consider accepting factors n>20M, or perhaps we should continue as is until 75T... it's louies descission as to if and when.
Current there isn't much of a problem continuing as is, Sieve and submit factors as per usual. Then once their range is entirely finished the send their factors in via e-mail. We can then check for gaps etc above and below 20M, it avoids ranges being divided up into 20G chucks and makes it very easy for archiving purposes.
As for points scored etc, even if those factors scored at present the points awarded would be very low until the factors enter the main window. So for scoring it's not important. In the past the users who were participating were not as interested in scoring personally it was more of a project goal. Stats regarding factors found and progress etc are reported in the yahoo gourp and here from time to time, they are just not updated every 4 hours like Mikes.
As for updating the dat....
Joe runs his own db server that handels the dat and applies factors, currently it's working just fine. From time to time he grabs what was sent to the server through the webpage, e-mailed to factrange and processes all the factors. Joe would have to comment regarding it being easier to get everything from the server I'm not sure.
For stats updates, I'll probably put together another stats update next week. Also eventually we will produce stats on a user basis which is why we like people to reserve in 1T increments for double-check-sieve.
I've been trying ot do some DC sieving withthe large dat but i haven't been able to get to the .dat file. I have problems with yahoo and i would like it if there was a link in the fourum. Could someone help me with that?
For those of you following and contributing to; the high-n sieve, double-check sieve, and sending factrange.txt to factrange@yahoo.com, here is the final graph of this type.
This graph represent the decrease in dat size or number of k/n remaining vs update.
This final point (9) in this graph represents the most recent reduction which includes...
- all factrange@yahoo.com submissions
- all ranges p<25T have been completly sieved with a 991<n<50M dat
- all p<3T with a 50M<n<100M
- those factors submitted p>25T with the 991<n<50M
- the low-n P-1 factoring effort
- all factors found thus far by the main effort for n<20M
Whew!!! Quite a few factors and sources...
We have reduced the total number of k/n pairs between 20M<n<50M from just shy of 2M pairs (1,946,998) by over 55% to 871,348 k/n pairs remaining.
This leaves roughly
29,045 k/n pairs per 1M range of n.
(For comparison purposes) 1M-20M has roughly
26,264 k/n pairs per 1M range of n.
Continued in next message, see graph.
Y-axis represents total number of k/n's remaining without factors
X-axis represents the update interval.
Final table representing previous update intervals.
Future tables may have different limits on lower n> / Upper n< to represent current prp levels of first-pass and second-pass.
All future table will begin with the April-5 (p=25T) update inverval. (Original will change to p=25T)
Notes:
The dat size in bold (Lower LHS of table) represents the current 20M<n<50M range and 991<n<50M dat.
Points of interest for the most recent update shown in bold and noted as "found April-5"...
Notice the relatively large number of n<1M eliminated, many of these were from the low-p factoring efforts. The 20M<n<30M range "factors found" is slightly greater then the 30M<n<40M or 40M<n<50M, this difference or roughly 60 factors is probably due to factrange@yahoo.com submissions.
Note the reduction in 10M ranges 50-60, 60-70, 80-90, 90-100... These unique factors were found solely through factrange.txt submissions from people using the 991<n<50M dat. It seems as though all dat are able to find a great deal of unique factors just above their upper limit.
1.7M<n<20M main-effort dat finds factors into the low 40M range. Where as the 991<n<50m dat finds alot of factors 50M-100M and above... yes we are keeping n>100M as well.
Reply With Quote
Posting Permissions
