Sieve Client Thread

[Moo_the_cow]

quote:
_________________________________________
Hm, aren't there some posts missing?
_________________________________________

I noticed that too, and at first I thought that something was wrong with my PC. I didn't delete those posts, so I'm guessing that there is either something wrong with the boards (more likely), or the original posters deleted them (which I doubt).

P.S. I hope my post doesn't get deleted either.

Update:

quote:
____________________________________________
Dyy had an equipment failure. Looks like some things had to be re-constructed from backups, which might explain the missing changes to the post....
____________________________________________

[b2uc]

Mystwalker

Can't sleep...was just reading over some of your old info and came across this at the bottom....probably read it 5000 times already...but let me ask a question.

Wild stab in the dark:
p=50T by the time you're testing n=3000000
p=300T by the time you're testing n=6000000

Does this mean we are PRPing much faster than you expected...or does it mean that sieving is taking out more factors than estimated? Was this prediction before 5 primes were found?

Just asking...I know it was what it was titled...a wild stab in the dark...but I was looking at the fortune of maybe only having to sieve to 100T when we pull up on 6000000....or am I looking at it backwards?

[Mystwalker]

Hm, did I really say that?
Can't remember that... - can you give me the link to that post?

In addition, I've never used the phrase "Wild stab in the dark" in my whole life AFAIK (possibly because I didn't know it so far? ;))

[mklasson]

Short story: I've made a siever that's faster than sobsieve v1.26 under linux (latest available?), and sobsieve v1.35 on a windows p4. It's slightly slower on a windows athlon. I don't know about the speed for other processors. Different versions are available for pre-pentium pro and post-ppro (has cmov instructions). I've also compiled statically linked versions for linux -- I need it for one of my machines.

The n lower bound is always set to 0 for the moment, so it doesn't make any sense not to sieve both 300K-3M and 3M-20M simultaneously with this program. Use the sob.dat that goes from 300K to 20M.

I've tried to make the program behave as much like sobsieve as possible, so it uses a SoBStatus.dat file with the same layout for progress saves. Factors are written to fact.txt though. By default the program also finds duplicate factors and occasionally one that is outside the n range. Such factors are written to factexcl.txt and can be ignored completely with the cmdline switch "-d".

Benchmarks for the range 50000G to 50000G+24M:
332kp/s windows, athlon 2030MHz, proth_sieve v0.31
338kp/s windows, athlon 2030MHz, sobsieve v1.35
163kp/s windows, P4 2.4GHz, proth_sieve v0.31
144kp/s windows, P4 2.4GHz, sobsieve v1.35
234kp/s linux, athlon 1533MHz, proth_sieve v0.31
144kp/s linux, athlon 1533MHz, ssobsieve v1.26

If there's a later version of sobsieve for linux out there, the speed of that one would no doubt be much higher.

Benchmark on ranges that are multiples of 8 million to get the most correct result. The reason is that I'm precalcing some stuff (sieving primes and factoring p-1) every 8M that's used throughout the following 8M range.

Download from http://n137.ryd.student.liu.se/sob.php if you want to try it. Use the cmov version if you've got a pentium pro or later.

Long story:
I came across something called the Silver-Pohlig-Hellman algorithm for calculating discrete logarithms (DL). It's good when the group order is a product of small factors, with complexity O(sqrt(p)) where p is the largest prime factor. Using it you can calculate the DL modulo any divisor of the group order, so for our sieving effort you can get the proper DL modulo a suitably large divisor (not necessarily a single prime factor. You can calculate DL mod prime factors separately and combine with crt, or you can calculate the DL mod a product of prime factors. For small prime factors, it's often cheaper to multiply a few of them together and operate on the product) of order(2,p) and then use that information to do a much cheaper instance of the regular baby-steps/giant-steps for the n range (0-20M, say). Yes, this is what Robert Gerbicz talked about 2 months ago... It's a shame I didn't get my head around it then. Props to Robert. Also be sure to check whether the calculated DL matches what's known about the residue mod "t" of the remaining n values. If it doesn't, eliminate that k immediately.

The problem is that you need to find order(2,p) quickly. Trial factoring every p-1 completely is too slow, so a much better approach is to sieve even numbers at the same time you sieve odd numbers to get the primes p. Save the found prime factors for all even numbers that are one less than a prime, and then use them later to calculate order(2,p).

Another improvement involves the "t-power test": instead of checking (-k*2^a)^((p-1)/gcd(p-1,t)) you can test (-k*2^a)^(order(2,p)/gcd(order(2,p),t)), which eliminates some extra k.

Paul, I'm pretty sure you could spice up sobsieve as well to gain somewhere between 20 and 50-ish percent with this approach. And don't hesitate to tell me if you feel like sharing your 25 instruction mul_mod. I'll happily kill for it. ;)

I also found what seems to be a small bug in sobsieve v1.35 while I was fiddling around. It reports 44448242721917 | 22699*2^12158038+1 as a new factor even though that k,n pair isn't included in the sob.dat file.

Anyhow, I'd be happy to hear your results if you do try it out.

Regards,
Mikael

[Troodon]

I have tried it (some minutes), but it haven't seen any rate output... I'm too lazy to do it manually :D .
Could you add a priority level parameter?
Thanks!

[mklasson]

Currently the rate is only output at the end of execution. Just test a smaller range -- you can edit SoBStatus.dat manually or give the range on the cmdline, as in
"proth_sieve.exe 50000000000000 50000024000000", in which case SoBStatus.dat is overwritten so be careful not to trash any work in progress.

As for a priority parameter, use the "nice -n20" (for linux) or "start /LOW" (windows) utilities for now. I'm too lazy to do that. ;)

Mikael

[Troodon]

K6-2@3x105 MHz, Win98 SE:

Statistics:
pmin : 60000000000000
pmax : 60000015000000
# Tested p : 471803
# Tested k : 5661636
# Whacked k : 4461754
# Whacked p : 116182
Total time: 324451 ms
46k p/s.

Wow! :eek:
SoBSieve 1.21 -> 16 kp/s
NBeGon 0.10 -> 6,6 kp/s

Thank you very much! Now, I'll benchmark it on the Tualatin.

[Troodon]

Tualatin@10x140 MHz

-= Windows 2000 SP3 =-

proth_sieve 0.31:

Statistics:
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 45366 ms
220k p/s.
proth_sieve_cmov 0.31:

Statistics:
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 44094 ms
226k p/s.

SoBSieveConsole 1.34: 230 kp/s

-= Windows 98 SE =-
proth_sieve 0.31:

Statistics:
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 45981 ms
217k p/s.
proth_sieve_cmov 0.31:

Statistics:
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 44271 ms
225k p/s.

SoBSieveConsole 1.34: 218 kp/s

The improvement of the CMOV version is not as big as I expected.

[mklasson]

> The improvement of the CMOV version is not as big as I expected.

It's about twice that percentage, around 6-7%, on my athlon. Anyway, it's a cheap boost.

You'll probably see those tualatin rates increase by 4-5% or something if you benchmark a range that's a multiple of 8 million or use a larger range to let the effect level out.

Mikael

[Keroberts1]

OK... I have an AMD athalon with approximatly 1.7G. Should i use this, what do i need to do to install it. I haven'
t downloaded it yet and I only want to if its going to be very easy to install and not take alot of effort to get going and update and so on as the current sobsieve program is. If this is all gonna happen though I would definatly love to see any sort of increase in sieve speed.

[Troodon]

Just download and place it in the same dir as SoBSieve, or create another one copying inside the files sobstatus.dat and sob.dat. As with sobsieve, you only need to run the exec, Before that, I recommend you to do some benchmarking - maybe sobsieve is still the fastest on your machine!

[Troodon]

proth_sieve is finding many factors for n>20M, which are currently considered "out of range factors". Could you make these factors be recorded into another file, like "factexc20M.txt". Maybe they will be useful in the future :) .

[b2uc]

I was about to ask the same question..until I read your post...what do we do with these little nuggets of future gold? They are just setting in a text file waiting to be turned in when the sieve effort goes n>20M. Be a lot of cheap points:)

[Mystwalker]

Till we get there, I assume several text files gonna get lost due to multiple reasons. I suppose it's best to collect them just like the other factors.
Are they only a bit bigger than 20M?

[mklasson]

Well, I just uploaded proth_sieve v0.32 to
http://n137.ryd.student.liu.se/sob.php

+ priority level parameter. Default is now idle for process and normal for thread. This translates to something pretty idle. :) You can specify both process and thread priority, so you should be able to get precisely what you want. The settings go from 0 to 4 for process and correspond to idle, below normal, normal, above normal, high. For thread the range is 0 to 5 and correspond to idle, lowest, below normal, normal, above normal, highest. On the linux version only process priority is used; the process' priority is then set to 20 - 10 * priority. In short, 0 is idle while 4 is highest, just like under windows.

+ writes factors outside range to factrange.txt instead.

+ rate is output at every update interval (default 10M). The rate displayed is the average during the last full 8M block.

+ the lower limit of the n range is now used. Sieving 3M-20M instead of 0-20M is something like 1 or 2% faster, so using the 300K-20M sob.dat and double sieving is still highly recommended.

This version may be a really tiny bit faster than 0.31, but I'm pretty sure you won't notice it. :)

Regards,
Mikael

[mklasson]

>Are they only a bit bigger than 20M?

Some go up to about 35M (I figure it'll take a while before they become useful :) ). These extras have a bigger chance of popping up when p-1 is pretty highly composite.

Mikael

[b2uc]

Had a PC in the shop getting w32.Blaster.worm strain C yanked from it...so it's sitting here all week while the owner is off on vacation...so I decide to install SOBSieve on it to benchmark the P4 since I only run AMD chips myself.

I've never seen anything in my life more useless than a P4 2.4GHz Dell running WinXP Home with 128MB of SDRAM. Yep...128MB of SDRAM. I've seen faster results in the World Championship Blonde Hide and Go Seek competition filmed in stop motion video. Machine kicks major donkey in ECC2-109..but everything else it appears to be a black on grey paper weight.

[Mystwalker]

Sieving isn't P4's favorite discipline. I'd use it for P-1 factoring or (due to the memory constraints) for the standard SoB - unless it's not connected to the internet from time to time...

[Troodon]

I have run WinXP on my K6-2 at 300 MHz with 128 Mb of ram, when properly confirgured, it works well.
As Mystwalker said, P4 are good for SB, P-1 factoring and Prime95 and aren't good for sieving. That's because their x87 floating point unit is very weak under heavy load, but if you use SSE2, you can get as many instructions per cycle as with Athlon's x87 FP unit.
Plus the Pentium 4 is much more bus and memory speed dependant than any other recent CPU. SDRAM really kills Pentium 4's performance.

Thanks mklasson!

[mklasson]

http://n137.ryd.student.liu.se/sob.php contains a just released v0.33. Sorry about the abundance of new versions. :D

This one's about 2% faster across the board.

Mikael

[Keroberts1]

it would be nice to see a version as user friendly as the old one and perhaps wit hthe same lay ourt just so it would be easier to use/ monitor.

[larsivi]

mklasson:

Some numbers low sieving range, around 11T:

proth_sieve_windows_cmov, v0.33 reported 259k p/s as maximum

SoBSieve 1.28 reported 333k p/s as maximum

The machine is an 1.33 GHz Athlon

[mklasson]

larsivi:
I see about a 15% speedup on my system when sieving just 300K-3M instead of 300K-20M, so if that's what you're getting as well then all is normal.

Proth_sieve is not all that affected by the size of the n range. You should probably just stick with sobsieve 1.28 for the low sieving range.

Thanks for the numbers though,
Mikael

[Mystwalker]

Hm, strange...
The last 60+ factors I got (using SoBsieve) are quite evenly distributed across all n's - except the 4M section.:gone:
How about you?

[mklasson]

Hm, strange...
The last 60+ factors I got (using SoBsieve) are quite evenly distributed across all n's - except the 4M section.:gone:
How about you?
Alas, I haven't gotten a high-scorer for close to 200 factors now... Had one this morning that was 30k below the prp bound. Ack!

[Mystwalker]

Woohoo, got one!
37207258041013 | 24737*2^4401127+1 :elephant: :elephant: :elephant:

Was this finding pure coincidence? :scratch: *cough* conspiration *cough*:whistle:

[mklasson]

Too bad it's less than 40T. ;)

[Mystwalker]

Ah right, I remember... :swear: ;)

[Troodon]

More benchmarking:

-= Tualatin@10x142 W2K SP4 =-

*** "normal" ***

proth_sieve 0.31
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 44325 ms
225k p/s.


proth_sieve 0.32
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 44585 ms
224kp/s.

proth_sieve 0.33
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 44143 ms
226kp/s.

*** CMOV ***

proth_sieve_cmov 0.31
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 42933 ms
232k p/s.

proth_sieve_cmov 0.32
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 42712 ms
234kp/s.

proth_sieve_cmov 0.33
pmin : 60000000000000
pmax : 60000010000000
# Tested p : 314507
# Tested k : 3774084
# Whacked k : 2975683
# Whacked p : 77661
Total time: 41860 ms
238kp/s.

SoBSieveConsole 1.34: 236 kp/s


At 52336 G
- proth_sieve_cmov 0.33: 244 kp/s
- SoBSieveConsole 1.34: 236 kp/s

[mklasson]

Troodon:
Let me provide a gentle reminder that you'll get more correct (and higher, probably around that 244k figure for cmov) rates if you benchmark ranges that are multiples of 8 million wide. ;)

[Troodon]

Yes, I know, but I wanted to test it in an adverse scenario :jester: . Thanks for your great work!

[Troodon]

Another benchmark:
Athlon XP 1700+ (Palomino), WinXP SP1, 52424 G
SoBSieveConsole 1.34 - 274 kp/s
proth_sieve CMOV 0.33 - 256 kp/s

[mklasson]

To quote myself:

"Feeling lazy? Want to make the chore of managing all your factors a little more automated? Try the new sobistrator v1.10! [windows only]"

This program lets you keep track of multiple machines' sieving efforts and collect new factors from them with a single click. It can optionally launch the submit page automatically and reduce your effort to a paste operation.

I like it. :D

Have a go at http://n137.ryd.student.liu.se/sob.php if you want to try it.

I originally made this strictly for myself, but I figure someone else might enjoy it as well.

Regards,
Mikael

[Xrillo]

I've been running the sobistrator 1.10 for a few days now, and I can highly recommend it! :smoking:


...it's to bad I don't have more than one computer...:bang:

[mklasson]

Shooting myself in the foot stats-wise, I present you with proth_sieve v0.34. ;)

It's about 10% faster than v0.33, with the linux version something like a whopping 20% faster.

This one finds far less duplicates, because it forces all found factors' n to lie in the same residue class modulo "t" as the remaining unfactored n do. I previously hadn't implemented that idea in the new discrete log algorithm. Additional linux speedup is due to new gcc (3.3) and removal of some redundant variable copying.

"Outside range" factors are now able to go a lot higher, but are more rare. They're pretty useless, but free. :)

Factors with n < lower limit are also written to factrange.txt now. They used to go to factexcl.txt.

Head on over to http://n137.ryd.student.liu.se/sob.php

Cheers,
Mikael

[mklasson]

At the risk of talking to myself, here's a new version again. This one's about 16% faster than v0.34.

I get roughly 420kp/s on my 2030MHz athlon now.

Are you using this yet? :)

http://n137.ryd.student.liu.se/sob.php

EDIT: Oh, I forgot. A new feature in this version is that you can write new ranges in a text file called nextrange.txt and have proth_sieve automatically start working on the next one after it's done with the current. Ranges are given on two lines, just like in sobstatus.dat.
pmin=12345000000000
pmax=12346000000000
for example.
*** SoBSievers BEWARE! *** SoBStatus.dat is erased when the new range is started, so if you've been using SoBSieve and have factors in SoBStatus.dat you'd better copy them before creating a nextrange.txt.

Regards,
Mikael

[Xrillo]

I went from 160k to 210k in a matter of days using proth_sieve 0.33-0.35. :banana:

Last time I used sobsieve it gave me 140k.

You do the maths...

Oh, FYI I'm using a P4 2.4GHz system. :D

[Mystwalker]

Oh, FYI I'm using a P4 2.4GHz system.

Wouldn't it be better to do P-1 factoring then? I mean, my 1 GHz P3-m even does ~ 205kp/sec.
Whereas it would completely suck vs. your P4 when doing factoring...

btw. the sieving rate dramatically increased from ~ 160kp/sec when changing from SoBSieve to Proth_Sieve.
Really nice work, mklasson! :thumbs: :cheers:

Oh, and nice country you live in - I was there on camping tour some weeks ago. :walking:

[mklasson]

Originally posted by Mystwalker
Wouldn't it be better to do P-1 factoring then? I mean, my 1 GHz P3-m even does ~ 205kp/sec.
Whereas it would completely suck vs. your P4 when doing factoring...
Don't you think the P4 still does more good sieving at that rate than P-1:ing though?

btw. the sieving rate dramatically increased from ~ 160kp/sec when changing from SoBSieve to Proth_Sieve.
Really nice work, mklasson! :thumbs: :cheers:
Oh, and nice country you live in - I was there on camping tour some weeks ago. :walking:
Thank you! Yeah, too bad it's so much easier to appreciate a country when you don't live in it every day. :)

Mikael

[Xrillo]

Originally posted by Mystwalker
Wouldn't it be better to do P-1 factoring then? I mean, my 1 GHz P3-m even does ~ 205kp/sec.
Whereas it would completely suck vs. your P4 when doing factoring...

That's true, but I find that sieving is more efficient still. I tried P-1 factoring a couple of months ago but found only one factor in a range of 5500 candidates. So...I'd rather do some PRP tests instead of P-1. But It's boring...:sleepy:...at least you find something when sieving.. :)

[expinete]

Proth_sieve 0.35 now is faster than sobsieve 1.34 on my computer (XP 1600+)

proth_sieve 0.35 295kp/s
sobsieve 1.34 260kp/s

Good job! :thumbs: :thumbs:

[Mystwalker]

Originally posted by Xrillo
That's true, but I find that sieving is more efficient still.

I'm not sure with that. Sieving gives us a lot more factors, but most of them are not useful right now or in the next weeks. So one could do factoring now, as there is a lot of power urgently needed (big ranges can't be trial factored before PRP catches up), and later switch over to sieving again.
I don't know about the best factoring <--> sieving ratio, but I think it's not bad to let the machines do what they are most useful to do - P3, AMD sieving; P4 PRP or factoring.
But it's just instinct, can't prove anything. :crazy:


Originally posted by mklasson
Thank you! Yeah, too bad it's so much easier to appreciate a country when you don't live in it every day. :)
Mikael

I guess winter is not that joyful sometimes - how long are day times then?


btw. doing even close to 210kp/sec (sometimes even reaching it)

[mklasson]

I'm not sure with that. Sieving gives us a lot more factors, but most of them are not useful right now or in the next weeks. So one could do factoring now, as there is a lot of power urgently needed (big ranges can't be trial factored before PRP catches up), and later switch over to sieving again.
Best of all will be when p-1 is integrated into the prp client.


I guess winter is not that joyful sometimes - how long are day times then?
At its worst, the sun sets around 15 in the afternoon or so. That's not the worst part though... That'd be the horrible screams of the polar bears clawing at your back! It's enough to drive a man insane... :scared:

[Mystwalker]

Originally posted by mklasson
Best of all will be when p-1 is integrated into the prp client.


Theoretically yes, but Louie raised a good point there: It is expectable from the user that he grants the client to use 256 or 512 MB RAM? I think a lot of ppl won't (be able to) do this. :(



At its worst, the sun sets around 15 in the afternoon or so. That's not the worst part though... That'd be the horrible screams of the polar bears clawing at your back! It's enough to drive a man insane... :scared:

15 o'clock? Well, that's a lot better than I thought. A "dawn at 11:45, dusk at 12:15" was what I expected. ;)
Even here, it gets dark around 16:00 for some days...
But we have less polar bears:neener:

[mklasson]

> Theoretically yes, but Louie raised a good point there: It is expectable from the user that he grants the client to use 256 or 512 MB RAM? I think a lot of ppl won't (be able to) do this.

Considering that it's just for an hour twice a week, _I_ think that's pretty ok. Besides, they don't have to allot that much memory -- it's just speedier if they do.

[MikeH]

Mikael,

Congratulations, a truly astonishing achievement. You were straight out the box with a client that's faster than anything around for Linux, and anything pre-CMOV. Within two weeks you have overtaken Paul's clients on every platform and OS.

This is an astonishing accomplishment. Paul and Phil have been at this for years, don't be surprised if you have other projects with sieving needs knocking on your door!

I've just this evening started to use v0.35. On my AMD XP2100 I get 356kp/s vs 316kp/s with sobsieveconsole 1.34. I've been using my own automation s/w for a while, but I'll now be taking a look at sobistrator.

Keep up the great work.:notworthy

Mike.

P.S. You really should talk to Paul. If he has some super efficient bits of assembler that he's willing to share maybe you could get this thing much faster still.:bouncy:

[Keroberts1]

the proth sieve client is giving me a rate of 304 while i had 316 with sobsieve does that mean the sobsieve is faster or is the rate not registering right one one of them

[chvo]

For me proth_sieve 0.33 (Linux version) works fine, but 0.34 and 0.35 segfault when they start sieving (I'm working with Mandrake Linux, I don't know exactly which version).

[MikeH]

the proth sieve client is giving me a rate of 304 while i had 316 with sobsieve does that mean the sobsieve is faster or is the rate not registering right one one of them What hardware platform and OS are you using? And which versions of the clients are you uisng?

[mklasson]

MikeH,
thanks for the kind comments!

chvo,
it isn't simply a case of accidentally running the cmov-version on old hardware? Anyway, what processor are you running it on, and which program version are you using -- cmov/regular, static/nonstatic?

[chvo]

I'm using proth_sieve cmov static on a P4 (the static cmov 0.33 version worked fine, however now it segfaults when it starts sieving!?)

[Keroberts1]

I wasw using 0.34 with cmov on an AMD athalon 2000+ but since upgrading to 0.35 i have had a surprising speed up so I'm good now

[mklasson]

Is anyone else sieving (or trying to) with a P4 under linux, and if so do you have the same problems as chvo? I'm having a tough time finding the cause of this as I don't have any P4s myself and it works just fine on my machines.

Mikael

[Nuri]

I've started using 0.35 yesterday and I have a question. But, fisrt things first: Congratulations Mikael. :thumbs:

I'm using the client on 46.x T, and over roughly 60G of sieve range, the client found the following number of factors:

Unique: 23
Duplicate: 341
Out of range: 82 (only 41 of which is accepted by the sieve submission page).

The number of unique factors seemed fine to me, but the number of out of range factors, and especially the number of duplicates are ..... :dunno:

Are those figures normal? Any comments?

B.T.W.:

Hardware: AMD Athlon XP 2400+ (2.0GHz)
System: Microsoft XP
Range: 3M-20M

[mklasson]

Nuri,

thanks!

The upper "deranged" factors, the ones above the upper limit, can pop up when p-1 is highly composite, but as for what the count should be... I'm sure 41 is just fine. :) I had about half that in the range I checked. They're really rather uninteresting as we'll want to sieve the ranges properly anyway when that time comes. The other 41 of your deranged factors, the ones below the lower limit, are probably more interesting as a unique factor for a low n could be hiding there. The number of duplicates match my counts well, but they're of course even more worthless than the deranged ones. :)

[Mystwalker]

I have a feature request:

Could you add an option to use a SoB.dat file in a different folder?
That would it make possible to use one dat file for several computers that work on the same NFS...

btw.: Linux version is only 3-4% slower than Windows client on a P3-800.

[mklasson]

Good news everyone. :)

Paul and I have teamed up and are collaborating on proth_sieve now. The fruits of our labors is a new proth_sieve v0.36 that scores a very pleasant 530kp/s on my Athlon 2030MHz. That's up about 25% from v0.35. Also new in this release is a little SSE2 support. Not a major boost, but a fine 10% or so on P4 machines.
Thanks to Christian Nilsson (Xrillo) for helping out with that part. The SSE2 enhanced flavor only exists for windows, because I have no chance whatsoever of testing a linux SSE2 version. Feel free to contact me if you want to try a linux version.

New features include the support for alternative sob.dat files that Mystwalker wanted (-s argument). The rate is also output to sobstatus.dat now, which brings me nicely to the second program...

I've put up a new sobistrator v1.13 if you're into that kind of thing. New in this version is rate display, ETA, managing next ranges (nextrange.txt), and factor submission. Click submit when you've got new factors waiting and sobistrator will send them to the seventeenorbust site for you. Don't worry, you can configure it to log in with your name and password so you'll get full credit for the factors. :)

As usual, the goodies are at http://n137.ryd.student.liu.se/sob.php

EDIT: Of course I forgot to mention that there's an older v0.354 SSE2 included in the SSE2 package. That one seems to be a couple of percent faster than v0.36 SSE2 for some reason. Use whichever you want.

Regards,
Mikael

[Mystwalker]

Got "only" 15-20% performance increase, but I think that's still worth a big cheer! :cheers:

Just updated my systems, running fine. The -s parameter helped me save a lot of space. I don't know my quota, but I think it's good not to reach it. ;)

Just thought about it... When it's possible to set the output file names via parameters (or maybe a parameter so that the files get an infix according to the range), then one should be able to run one copy multiple times in parallel, right?
I could hook up a lot of machines that way without the need to create further copies...:bouncy:

The new client and especially the sobistrator motivated me to work on my SoBSieveServer again. Hope I get enough time at the weekend.
Ah, the sweet smell of competition. ;)
Note: That server is no rival for the sobistrator - it could rather further enhance it...

[Keroberts1]

I've having trouble downloading the programs. Is the site down? Maybe not it could just be a problem wiht the connection on my end.

[Keroberts1]

Ok the problem as on my end but i have a new one. The sobinstrator says when i try to open it this application failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem. Obviously that didn't help. Anyone know what i need to do?

[b2uc]

Ok the problem as on my end but i have a new one. The sobinstrator says when i try to open it this application failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem. Obviously that didn't help. Anyone know what i need to do?

Run Windows update so your machine can download the .net update and upgrade from MFC70.dll to MFC71.DLL

Cheers,

Lee

[mklasson]

Mystwalker,

>Just thought about it... When it's possible to set the output file names via parameters (or maybe a parameter so that the files get an infix according to the range), then one should be able to run one copy multiple times in parallel, right?

Yeah, I don't see why not. You want that? :)

Soo, what's this SobSieveServer of yours?

Mikael

[Mystwalker]

Originally posted by mklasson
Yeah, I don't see why not. You want that? :)
Mikael
Sure. :)


Originally posted by mklasson

Soo, what's this SobSieveServer of yours?

Mikael
Well, basically it's a server storing and assigning ranges to clients and accepting found factors and notifications of completed ranges.
It was part of a seminar project and works with SobSieve (getting it to work with proth_sieve should be fairly easy, though).
There's still some issue, but I'm not sure whether it's program or computer related...

Hm, I think we could figure it out if someone could run the server on his/her computer. It's written in Java...


edit:
As it's been a while since we discussed excluded factors...
Are they of any worth submitting/storing?

[Mystwalker]

Well, one question concerning proth_sieve:

Assuming one runs that program, and meanwhile copies the factors out of the fact.txt and deletes that file afterwards. Will that result in proth_sieve not saving factors anymore?
I now have a ~11G hole, which seems to happen sometimes with this ranges this high, but I just want to make sure...

[mklasson]

> Assuming one runs that program, and meanwhile copies the factors out of the fact.txt and deletes that file afterwards. Will that result in proth_sieve not saving factors anymore?

No, no problem at all, it just creates a new file. I only wish 11G holes weren't so common...

I can't personally see any worth in excluded factors, btw.

Mikael

[Mystwalker]

Originally posted by mklasson

I only wish 11G holes weren't so common...

Mikael

According to chvo, they will be the average once we hit 200T - and thanks to your work, we will a lot sooner than it seemed only weeks ago. :D

[Slatz]

thanks for everyones work on the new clients...damn we have come a long way.

With the new proth sieve..i saw an increase of roughly 20%.

Great Job to all involved.

Slatz

[Mystwalker]

Ok, that client found a factor again - it was just a 23G hole. :cry:
It took only 1.6G to find the next one, though. Damn variance! :rolleyes:


I can't personally see any worth in excluded factors, btw.

What a pity. I have thousands of them - literally!

[Mystwalker]

From the other thread:

Originally posted by Keroberts1
100 T by new year we can do it!!!

According to my calculations (approx. 37.25G left), we need 3.45 Mp/sec.
I think that's achievable. :)

[mklasson]

I just put up a new proth_sieve v0.37. There was a bug in v0.36 that could cause it to miss factors (something like 1 in 400 factors). I'm very, very, very sorry about that. :( I used to sieve 257 ranges with known factors before every release and verify that all were found, but apparently this bug slipped through anyway. I'm now verifying 834 ranges prior to release to make such errors less likely. Note that the bug only exists in v0.36 and not in earlier versions, so hopefully _very_ few factors have been missed because of this.

*** Please upgrade your version immediately. *** As a small bonus, v0.37 is about 1% faster on my athlons.

There's also a new feature that Mystwalker requested in this one. Use the "-n <id>" argument to append <id> to the basename of all filenames. If <id> is 001 then SoBStatus.dat becomes SoBStatus001.dat, and so on. "-s <filename>" can still be used to override the sob.dat filename, and takes precedence over -n.

http://n137.ryd.student.liu.se/sob.php

Regards,
Mikael

[Keroberts1]

p = 86584680240941 @ 437kp/s
p = 86584690240963 @ 4294967087kp/s
p = 86584700241031 @ 437kp/s

Wow that is a speed increase Any idea what causs this bug?

[Mystwalker]

There's also a new feature that Mystwalker requested in this one. Use the "-n <id>" argument to append <id> to the basename of all filenames. If <id> is 001 then SoBStatus.dat becomes SoBStatus001.dat, and so on. "-s <filename>" can still be used to override the sob.dat filename, and takes precedence over -n.

Seems to work without a glitch. thx-a-lot!:cheers:

btw.:
~3% speed increase with P3/win32
<1% speed increase with P3/Linux

[priwo]

from 84 kp/s to 107kp/s on a P3 450 with NT

using 037cmov instead of 036cmov

[mklasson]

from 84 kp/s to 107kp/s on a P3 450 with NT
using 037cmov instead of 036cmov
Ooookay. That sounds a bit odd to me, but, aaah, congratulations! :D Are you sure you haven't changed anything else?

Keroberts1,
just enjoy your new blazing speed. ;)

Mikael

[MJX]

>>from 84 kp/s to 107kp/s on a P3 450 with NT
>>using 037cmov instead of 036cmov

>Are you sure you haven't changed anything else?

Hello!

I am at 99kp/s with my celeron 410 with w98 (cmov037) so 107kp/s at 450 Mhz seems ok....
I was at 68kp/s with version 033 > more than 40% speed gain...Thanks Mikael!!!

Philippe

PS: maybe will my cpu break the 100kp/s speed with proth_sieve 0.38????:hiya:

[larsivi]

Speed 'tip': proth_sieve went from 400kp/s to 320kp/s on my AMD 1.33GHz when I enabled Windows update. It went back to 400 when I disabled it again.

btw, I'm sieving low range only.

[cmprince]

FYI,
My Athlon 700 went from ~120 kp/s with SoBSieve 1.34 to 195 kp/s with proth_sieve_cmov_036 to 201 kp/s with proth_sieve_037_win_cmov.

Seems like only a few months ago that 60 kp/s was blazing -- oh, wait; that was a few months ago... Fantastic work by all. I hope someone writes a paper on the overall development efforts, as I'd be intested in reading it.

[Mystwalker]

Mikael,

could you state what's the complexity of the used algorithm concerning the range n?
You said it's not as relevant as SoBsieve. This piece of info could be useful if we discuss about changing ranges to increase sieving rate...

[Joe O]

Originally posted by larsivi
Speed 'tip': proth_sieve went from 400kp/s to 320kp/s on my AMD 1.33GHz when I enabled Windows update. It went back to 400 when I disabled it again.

btw, I'm sieving low range only.

Could you please explain "Windows update"?

[larsivi]

Could you please explain "Windows update"?

Yes, of course. Sorry. Windows Update is a service that is available in (at least) WinXP. It seems to continiously search MS' pages for updates to relevant software, mostly security updates and such.

I suppose that giving proth_sieve a higher priority might decrease the slowdown, but I haven't tried that.

[Mystwalker]

Just got a possible bug report:

The nextrange feature seems not to work on one of my machines running proth_sieve 0.37 on Win2k. :(

[mklasson]

Mystwalker,

the complexity of the Silver-Pohlig-Hellman discrete log algorithm is O(sqrt(q)), where q is the biggest prime factor of p-1. That gives you the full DL though, which we're not really interested in. The beauty of the SPH is that we calculate the DL mod q_i for each prime divisor (not necessarily unique -- you get it mod q_i^2 the second time, and so on), so we can stop when we know enough. The individual residues mod q_i are recombined using the chinese remainder theorem to get the DL mod m = product(q_i). We never need to go further than m = n_high (20M) for example. Occasionally we do so anyway because that's the most efficient procedure given the factor layout of that particular p-1. This is the source of the really far out outside-range factors. After we have calculated a suitably large m we turn to the regular Shanks baby-steps/giant-steps on the interval (n_high - n_low)/m, which is O(sqrt((n_high - n_low)/m)).

Anyhow, the net result of all this is that the complexity is a bit harder to estimate... Yes, it still depends on the n range, but how? Several different n ranges will have the same optimal work for many p, and the amount of work for a fixed range varies wildly with different p.

Oh, and about the nextrange feature, you haven't just misspelled the filename and made it next_range.txt or written pmin twice or something like that?

Mikael

[Mystwalker]

I'm quite sure it didn't misspelled the file name. Anyway, a recent recheck showed the feature indeed does work. I don't know what went wrong this morning, but maybe there was a mistake on my side.
If the problem occured again, I'll tell you...

[paul.jobling]

Hi all,

I haven't been receiving notification of updates for some reason, so I haven't been here for a while, but I have just subscribed to the thread again. However let me say here my thanks to Mikael for his great work in finding the Silver-Pohlig-Hellman disrete log algorithm and for coding it up. The program is remarkably fast... good job Mikael upped the limit to 2^50 from 2^48 ;)

Regards,

Paul.

[Keroberts1]

what do yo umean by upped the limit. Was the limit of the previous sieve client 2^48. That will be an issue s oI'm glad that it was upped. We'll probably be breaking the 2^48 limit before the end of next summer at this rate.


One side question unrelated: Is the Siever's performance related at all to the size of the numbers being sieved? Could the performance change as we get to higher numbers or could it be optimized for larger numbers as we get dow nthe line. I'm not sure what type of algorithim is used in the program so I would not have any idea how ot even guess whether or not this is possible.

[smh]

However let me say here my thanks to Mikael for his great work in finding the Silver-Pohlig-Hellman disrete log algorithm and for coding it up. The program is remarkably fast

Just wondering, is this useful for the regular NewPgen too?

[mklasson]

Is the Siever's performance related at all to the size of the numbers being sieved?
Yes, you have to calculate bigger powers as p (and the order of 2 in Z_p) increases. The overall rate doesn't seem terribly affected though -- the effect is offset somewhat by the diminishing density of the primes. But yes, the real performance is affected to some degree. It might be possible to tailor the program a bit to suit bigger numbers better, but probably no major change. Lots of vague words here. I'm assuming p stays below 2^64 here... "We'll never sieve that far anyway".

[Keroberts1]

I'm thining about this for the distant future. As I see it we will be bringing some of these numbers probably far past the 20-million mark andchances are some may go much farther than that needing PRP tests that may take months or even up ot a year. once we get to that point a single factor found every few weeks would still be extremely useful. With this outlook the sieving effort may find it useful ot go much deeper than previously thought

[MJX]

Hello, concerning the version 036 bug,because I didn't want to miss a factor , I have sieving twice a 10 G range with cmov 036 and cmov 037. The results, 80 factors found including duplicates and excluded, are the same with both versions. So, in "real" sieving conditions, the error rate of the version 036 seems small too...
Other trials confirming it ?:p

[Keroberts1]

Will the Siever sieve any faster once one of the K values have been removed? Once again this is a kinda pointless question escept i was just wondering is factor finding will dropp off suddenly if we find a few primes.

[mklasson]

Originally posted by Keroberts1
Will the Siever sieve any faster once one of the K values have been removed? Once again this is a kinda pointless question escept i was just wondering is factor finding will dropp off suddenly if we find a few primes.
Yes. How much depends on which k is killed.

[Keroberts1]

perhaps Sieving for only certain Ks may be benefitial once we get to the higher ranges. If that would still yeild a beneficial ratio then there is reason to think about that

[smh]

It's more efficient to sieve all K's at the same time. Thats why program's were created to do that.

Sieving only one K will allow sieving much deeper for only that K in the same time, but it will cost more time to sieve all K's seperately compared to sieving them all at once.

Anyone any idea how much more efficient sieving all k's at the same time is?

[Keroberts1]

I've gotten an incredible boost in factor density just in the last few G I've been sieving. Not enough to be alarmed at but it is interesting and perhaps more evidence that there is some sort of pattern causeing them to group together.

Here are the factors

86806006665839 | 10223*2^13321541+1
86808425787089 | 33661*2^5661816+1
86812209123841 | 10223*2^14637101+1
starts getting interesting **************
86822005490767 | 21181*2^13538660+1
86822396416597 | 10223*2^15637277+1
86823040551029 | 55459*2^14422258+1
86823909625963 | 28433*2^15145945+1
86824201083779 | 21181*2^12366764+1
86825582367299 | 33661*2^16773792+1
86825821343039 | 21181*2^16424444+1

[larsivi]

sobistrator bug?

I had a few new factors which I tried to submit. Since seventeenorbust.com was down, the submit failed and I got a message about submitting the factors manually. Fair enough, but the factors disappeared from the "New factors" panel, while stilll saying that there were 8 new factors. I guess I can find the factors in the log, but I got a feeling that this behavior isn't intended.

[mklasson]

larsivi,

you'll probably see your new factors again if you press refresh.

I'm not sure, but I think I fixed that some time ago... At least I don't have the same problem in the version I'm running. Just hadn't released it yet.
Try http://n137.ryd.student.liu.se/sobistrator_114.zip

Mikael

[larsivi]

mklasson:

They came back with the refresh, but with the new version they didn't disappear at all.

Tjänare!

[Whity2]

something i noticed : if i start proth_sieve_cmov.exe by adding it to the windows/current version/run in registry it does not seem to look for the SoBstatus file as it just prompts me what values i want to sieve.
when i load it it startup by adding it in the Start Menu Startup submenu it works without that problem. tried both methods with same directory , same sobstatus , together and apart.

:shocked:
Win XP SP 1
AMD XP +2000 (getting 400 kps)
512 MB RAM

[Mystwalker]

Maybe there's no working directory set when you use the registry.
Just try using the -s parameter...

[Whity2]

that didn't solve the issue

[Nuri]

Originally posted by ceselb
Various design fixes and cleanups. Comments in the discussion thread please.

It looks much nicer now. :thumbs: Thx.

[m0ti]

Please check out my last post here (http://www.free-dc.org/forum/showthread.php?s=&threadid=4565) and let me know if this is a good idea (should give a speed boost of 2x... and not just in sieving)

[ceselb]

Originally posted by MikeH
sorry ceselb, but I need to stay out of everyone's way for a bit ;)

Heh, no problem. We'll soon catch up with you.
5T is quite a range, what's your rate?

[MikeH]

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.

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 :(

[Mystwalker]

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 ;)

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. :D
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. :|party|:

[Keroberts1]

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.

[Washuu]

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

[larsivi]

Washuu wrote:

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.

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.

[Nuri]

Hi Washuu,

Did you see Mike's page (http://www.aooq73.dsl.pipex.com/)?

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 (http://www.free-dc.org/forum/showthread.php?s=&threadid=2408) useful. The discussion of the algorithm we're currently using starts with the post of Robert Gerbicz (http://www.free-dc.org/forum/showthread.php?s=&postid=29254#post29254) in June 8th.

BTW, welcome to the sieve.

[Washuu]

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.

[ceselb]

When I test NBeGon on Solaris (is it the only client that runs on this platform?) i will join to sieving again.


It won't be very fast, but every bit helps. :cheers:



PS. Please update my scores page - the range until today was incorrect.

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.

[Washuu]

[QUOTE]Originally posted by ceselb
[B]It won't be very fast, but every bit helps. :cheers:

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

[Mystwalker]

I chose solving Sierpinski problem, because it's _finite_

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... :(

[Keroberts1]

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)

[Washuu]

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

[mklasson]

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.

[Mystwalker]

Celeron 1700 MHz is slower (150kp/s) than Pentium III 1200 MHz (180 kp/s) - is sieving so much dependent on cache memory?

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.


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

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. :(

[Keroberts1]

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.

[Mystwalker]

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 :)) should be larger.

Concerning the range discussion:

I'd advice to use the 1M-20M range, as there are only very few tests <1M (http://www.seventeenorbust.com/secret/) 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.

[jjjjL]

Originally posted by Mystwalker
But we maybe need another 1M-3M dat file, as some ranges are only sieved for 3M-20M.

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.

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

[Death]

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.

it ask's for sob.dat, but i haven't one.

[Joe O]

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

I'm definitely with Louie on this one! The sooner we go to a 1M < n < 20M unified sieve effort, the better.



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.

[Keroberts1]

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.

[Nuri]

Originally posted by Death
it ask's for sob.dat, but i haven't one.

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.

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).

[Keroberts1]

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.

[MikeH]

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:

[Deoje]

:help: 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.

[mklasson]

Hi Deoje,


Originally posted by Deoje
I reserved a range 33000-33050.
I started the sieve and input that range.
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.

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

[Death]

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.


Yes. Bright clear!

Right now I download 1m-20m file and ready to start.

Just need to reserve some range...

[Mystwalker]

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 you're sieving a range intended for the 300k-3M values, it's not advisable to use the 1M-20M SoB.dat file.

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/showthread.php?s=&threadid=3501 :thumbs:

[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

[Joe O]

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 choice is really yours. Whether you are more comfortable using the new sob.dat file, or modifying the old one.
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 (http://www.seventeenorbust.com/secret/).

The major speedup, about 5% comes from dropping the 5359 values.

Again, the choice is yours.

[Death]

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

[Joe O]

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. (http://www.aooq73.dsl.pipex.com/SobDat_n1M-20M.zip) 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.

[Keroberts1]

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.

[Keroberts1]

(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

[Deoje]

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.

[Deoje]

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.

[Nuri]

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) (http://www.free-dc.org/forum/showthread.php?s=&threadid=2771) 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) (http://www.free-dc.org/forum/showthread.php?s=&threadid=3501) with the new 1M < n < 20M sob.dat file (http://www.aooq73.dsl.pipex.com/SobDat_n1M-20M.zip) 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 (http://n137.ryd.student.liu.se/sobistrator_116.zip) 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.

[cmprince]

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.

[Mystwalker]

Originally posted by Nuri
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).

P4 power in sieving mostly relies on a fast FSB.
Using FSB800, I get 2*275 = 550kp/s on a P4 running at 3 GHz w/ Hyper-Threading enabled.

It's not as fast as the Athlons, but quite good anyway...

[Keroberts1]

It would be nice if we could actually figure out where the optimal range would be.

[rosebud]

I'm using the new 1M-20M Sob.dat. Should I still reserve my range with DC sieve or are the threads going to be merged some time soon?

[Mystwalker]

Originally posted by rosebud
I'm using the new 1M-20M Sob.dat. Should I still reserve my range with DC sieve or are the threads going to be merged some time soon?

I suspect the DC sieve thread is going to be closed and archived soon...

[rosebud]

alrighty

[ceselb]

Originally posted by Mystwalker
I suspect the DC sieve thread is going to be closed and archived soon...

I won't stop the ones wanting to fill the gaps. I've made a post in the DC coordination thread if anyone is interested.

[mastervince5]

I have a small request.

Could anyone give me some information about the progress that has been made since the start of the sieve project (how many times faster the newest version is).

I was lost between page 10 and 15 of this thread.

thx and keep up the good work

[ceselb]

Since the first version of the sieve our speed is around 25-30 times faster.

Or did you mean something else?

[Mystwalker]

When you take this (http://www.free-dc.org/forum/showthread.php?s=&threadid=2408&perpage=12&pagenumber=2) posting from Louie, there should be a performance increase of 400x since the days of NewPGen 2.70 :notworthy
I think SobSieve began with ~8 kp/sec on (then) fast systems, which would result in an approx. increase factor of 45.

[mklasson]

Would everyone using sobistrator v1.15 or v1.16 please upgrade to the new v1.18?

I made a bit of a screwup there, so B2 at RieselSieve is getting all your factors. :) Luckily he's forwarding them to Louie along with the name of the user submitting them. Sorry about all that. Just please upgrade right away, and rest assured that your submitted factors are well on their way to their rightful home.

http://n137.ryd.student.liu.se/sobistrator_118.zip

Thanks,
Mikael

[Death]

Originally posted by Keroberts1
(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

there's no fact.txt at directory.
only factexcl.txt and factrange.txt
do you mean both of them? that's look like "fact*.txt" =))

I submitted both and receive some like 25 verified, 20 new....
so I must reserve new range.

and something strange
162000396491 | 24737*2^21846079+1
163889464229 | 10223*2^25017809+1
163891911307 | 55459*2^21457486+1
163889464229 | 10223*2^25017809+1

why no numbers between 162000 and 163000? may I broke something?
should I restart this from the beginning?

[Nuri]

I guess I understood your problem.

You sieved 162 billion to 164 billion instead of 162 trillion to 164 trillion (or 162000 billlion to 164000 billlion).

That range is was sieved about 10 months ago, and it's factors were already submitted. That's why you could not find any new unique factors. Since that was the first time you've run the client and no new facotrs were found, the client did not find the need to create a fact.txt file.

You do not need to care for factexcl.txt and factrange.txt files. Just ignore them and leave as they are.

By the way, sieving 162000 to 164000 would take around 40 days at the fastest PC (or, roughly 1000 times the time it took for your PC to run the 162 billion to 164 billion range).


That is ok if you are planning to use a couple of PCs, or even if you run it under a single PC and if you are sure you will commit your PC for the coming days to work on the range you have and finish it.

But, if you are not that sure, I would recommend you to simply unreserve your 162000-164000 range from the coordination thread, then reserve and start with a smaller range (forex: a range of 100G, meaning 162000-162100 etc.)

Whichever you choose, I don't think there will be a problem.

[Death]

170000947469471 | 33661*2^10224120+1
170001591866017 | 67607*2^2093299+1

2 of the results were new results and saved to the database.
New Factors

[Death]

:(

pmin=170002478067419 @ 199 kp/s
pmin=170002479067459 @ 199 kp/s
pmin=170002480067479 @ 199 kp/s
pmin=170002481067511 @ 178 kp/s
pmin=170002482067519 @ 178 kp/s
pmin=170002495067959 @ 168 kp/s
pmin=170002496067977 @ 168 kp/s
pmin=170002497067979 @ 170 kp/s
pmin=170002498067993 @ 170 kp/s
pmin=170002512068483 @ 160 kp/s
pmin=170002513068541 @ 160 kp/s
pmin=170002514068577 @ 153 kp/s

like tihs. after restart it starts from 200 kp/s and slowly goes to 150 kp/s

:(

[Mystwalker]

Originally posted by Death
#= gap analysis indicates that the range is complete

171000-171500 Death # (ETA: mid feb)

what does # mean? there's only 2 days left to complete...

As you already know, Mike's scoring script also checks the for gaps in the factors submitted so far. When there are no gaps left in your range that are so large that it is likely to harbor another factor, that range might already been completed but not declared as completed yet.
It's basically just a way to improve the information contents of this table...

When you have 2 days left, it's of course possible that you find more factors, but the dcript won't be on alert if you don't...

[Death]

Originally posted by Mystwalker
As you already know, Mike's scoring script also checks the for gaps in the factors submitted so far. When there are no gaps left in your range that are so large that it is likely to harbor another factor, that range might already been completed but not declared as completed yet.
It's basically just a way to improve the information contents of this table...

When you have 2 days left, it's of course possible that you find more factors, but the dcript won't be on alert if you don't...

please explain what does it mean "gap"? gap can by between factors of IN factor?

and I prefer to complete range by myself not to abandon it. just to be sure...

[ceselb]

When you're nearly done with your range the gap checking script (http://www.aooq73.dsl.pipex.com/gaps/Gaps_n3_20_ps0u.htm) might think that you're done.
Don't worry, nothing will happen (unless you disappear for a month or two).

[Death]

Originally posted by ceselb
When you're nearly done with your range the gap checking script (http://www.aooq73.dsl.pipex.com/gaps/Gaps_n3_20_ps0u.htm) might think that you're done.
Don't worry, nothing will happen (unless you disappear for a month or two).

Huh huh...

171473269359173 | 55459*2^10274926+1

new one.

[Mystwalker]

Originally posted by Death
please explain what does it mean "gap"? gap can by between factors of IN factor?

The gap is the distance between to factors (the p's - like the range between the 171473269359173 you've just found and the next factor). If it is a lot bigger than usual in that range, it is likely there are still factors missing.


and I prefer to complete range by myself not to abandon it. just to be sure...

Didn't mean that, as the gap analysis can only guess, plus it has to take into account that the factor density might to sparse at that paricular range. If it is not, you'll still find some factors, so abandoning ranges is definitely not feasible. :cool:

[Death]

seems that somebody turn off power at saturday. my current range must been completed at sunday, but theres one day left =((

>> If it is not, you'll still find some factors, so abandoning ranges is definitely not feasible.

yes I found one more factor. but there's 22 hours left. hope to find more...


and another question.
how many WU's will save one factor?

[Death]

so gap checker missed twice =))

171491458444963 | 24737*2^7998031+1

[Nuri]

That's normal. :thumbs:

The gap checker looks at if the gap is larger/smaller than the largest acceptable gap for that range.

As I understand it*, the aim of the gap checker is to avoid missing any factors due to human error. If there is a gap that is larger than the largest acceptable gap for that range, and the user claims that the range is complete, then we might be missing some factors (i.e. the user forgot to submit them etc.). On the other hand, it's almost for granted that there will be at least some factors at a range that is as large as the largest acceptable gap.

It's something like; every square is a rectangle, but every rectangle is not necessarily a square. ;)


* In fact, for me, it's more like a part of many fancy stats to play with. The more, the better. :D

[Mystwalker]

Originally posted by Nuri
It's something like; every square is a rectangle, but every rectangle is not necessarily a square. ;)

I'd just say it's an alerting tool. It's designed to produce next to no false alert, which means that it generously overlooks smaller anomalies.
That way, it is very likely to find some factors in a range even after the gaps have been "accepted"...

[Death]

latest record
p = 666000078004351 @ 195kp/s

and it waits half a hour for now....

why it stops???

proth_sieve_smov.exe -i 1 -vv

p = 666000078456017 @ ???kp/s

and stops. can it be a factor so it takes a hour to check it???

UPD. for now it hangs for three hours and nothing.
maybe there's a problem in a client?

[Nuri]

The same happens here. That's strange, because the client works for higher p values. So, it's not something to do with a boundary etc.

For some reason, it stucks between 666000078456017 and 666000078456023.

I dunno why it happens, but it will run again if you set pmin to 666000078456024.


PS: Death, I also checked the range with one of our older clients (SoBsieve 1.10). There's no factor at that specific point. ;)

[Nuri]

Ah, I now remembered that one of my macines was stuck for four days last week at somewhere around 184.64T something. Unfortunately, I could not notice it until I came back from holiday.

Anyways, in that case, it started running without a problem after a reboot. So, I'm not sure if it's due to the same reason.

[Death]

thank you for clearing situation.
so I continue from 666000078456024

and, have you tried 18, 19, 20 etc at the end?
It running on 24 at the end but can it run with 23 or 22?

PS and I hope you not checked ALL that range =)))

[Nuri]

Don't worry. I checked them all. :thumbs:

[Death]

same shit

p = 666000350160731 @ ???kp/s stucked. :trash:
and now there's 10:10 and i don't know how long it hangs at night =((
waste of time...

where's the author??

PS
that's not an optimization fault.
_cmov and _sse2 and _sieve.exe stops all the same.

it won't start even at 742 so i checked it with SoBSieve.exe ant it works up to 666000354181219 wery well.
so I continue from thith point with _sse2.exe again.
hope to hear Mikael Klasson and Paul Jobling soon... :cry:

[Death]

well.

sieving countdown!
so the client sieve not from 100 to 150 but from 150 to 100.
may be this can raise speed a bit?

and this is useful have a choice!

[TheCrusher]

I have reserved the following range and seem to have the same problem.

After 666666110000350 it won't move any further.

Must have been hanging there all over my vacation for two weeks or so...

[Death]

pmin=666000672412337 @ 0 kp/s

[mklasson]

Sorry to hear about the problems, but at least I think I know what's causing it. Give me two days or so and I'll try to have a fix for it.


Originally posted by Death
sieving countdown!
so the client sieve not from 100 to 150 but from 150 to 100.
may be this can raise speed a bit?
and this is useful have a choice!
What do you mean by this?

Mikael

[Death]

I mean exactly the same what I write.
The numbers must not increasing but decreasing.
So you can sieve not from XXXXX to XXXXX+500 but from larger number to smaller.

example
start sieve from 150000 to 145000
and it goes
150000 @ xxx it/s
149996 @ xxx it/s
149992 @ xxx it/s
etc...

btw, what is the problem with client? what's happen?
waiting for fix +)))

[mklasson]

Originally posted by Death
I mean exactly the same what I write.
Thank you. I wasn't doubting that. It's just that the meaning of what you write isn't necessarily as obvious to me as it is to you.


The numbers must not increasing but decreasing.
So you can sieve not from XXXXX to XXXXX+500 but from larger number to smaller.
I'm afraid that's pointless. You'd still have to sieve the same numbers. You'd just get a rate that started low and increased instead (say rate 100kp/s at the start and 150kp/s at the end instead of 150kp/s at the start and 100kp/s at the end).


btw, what is the problem with client? what's happen?
waiting for fix +)))
I just noticed you've been reserving extremely high ranges. Not only is it very inefficient for the project (the primes are denser in the lower ranges so it's always best if you reserve ranges that are as low as possible), but I also think the current client works fine at the ranges we're currently at (and a bit further).

Yes, the client is still broken and I will fix it, but you can eliminate the problem yourself and increase efficiency at the same time by switching to a lower range. To quote you: "waste of time...". 214T+ looks free.

The problem is that the hash table gets full.

Mikael

[Death]

Originally posted by mklasson
Thank you. I wasn't doubting that. It's just that the meaning of what you write isn't necessarily as obvious to me as it is to you.

=) you are welcome. don't want to be mean, just can't explain. I'm not an english-language native spoking person, so it's usually hard to explain something with different words. my small wocabulary i though...

I'm afraid that's pointless. You'd still have to sieve the same numbers. You'd just get a rate that started low and increased instead (say rate 100kp/s at the start and 150kp/s at the end instead of 150kp/s at the start and 100kp/s at the end).

Yes, I know that's the numbers are the same, but sieving can start from highest and countdown to lower number. now they are increasing, but sieving can do the same stuff at other direction.
maybe this can raise speed a bit... and maybe this can be useful for something that we don't know....

I just noticed you've been reserving extremely high ranges. Not only is it very inefficient for the project (the primes are denser in the lower ranges so it's always best if you reserve ranges that are as low as possible), but I also think the current client works fine at the ranges we're currently at (and a bit further).

call this a whim. since I can't connect to sob.pns.net to running usual sob client (damn this pecky corp. firewall), i just want to do something funny.
if v.3 comes to life and ecc2-109 comes to an end, I can add some boxens to SoB. maybe few dozens...

Yes, the client is still broken and I will fix it, but you can eliminate the problem yourself and increase efficiency at the same time by switching to a lower range. To quote you: "waste of time...". 214T+ looks free.

I switched to slightly lower range for a few days... until I get fixed client.

The problem is that the hash table gets full.

well, good that we discover this before going to check really big ranges +))

Edited bold tags for readability. /ceselb

[mklasson]

There you go. New clients are up at http://n137.ryd.student.liu.se/proth_sieve.php. No BSD clients atm, but they'll come up soon.
Highlights are:
5-10% speedup.
Lowered memory usage.
Fewer infinite loops.

Mikael

EDIT: Oh yeah, Linux and BSD versions still (like in 0.40) only measure time for current process so the rate isn't affected by other running programs. I'll try to fix that in the _next_ version...

[Keroberts1]

on my machine its reporting a slight speed drop. However i had some doubts about the accuracy of the speed reporting in v.40 What is your opinion on this?

[Deoje]

Ver. 40 reported my speed as 645kp/s and 699kp/s max. and lower depending on if I had anything else running such as a web browser. These seem a little high.

Ver. 41 reports my speed as 621kp/s max and lower of course if I have something else running.

Was ver. 40 just reporting the wrong speed and ver. 41 is showing the correct speed?
Or is Ver. 41 slower on my machine?
If it is slower I will change back to ver. 40 of course, but if ver. 41 is correct I will not .
Thanks

[Death]

thank you!

so let's restart brom beginning...

and speed is slightly lower than usual..
160 k/s vs 190 k/s but it's more stable over time. ie v.40 speed flowing over time from 200 k to 110 k and back...

[mklasson]

That's odd. Could you post what cpus you're using along with those numbers? I can imagine that 0.41 might be slower on non-athlons. Also, what ranges are you doing?

[Death]

celeron 1700 MHz

v.41 shows 170 k/s max.
v.40 shows 200 k/s max.

doing 666000 range. same with 500000 range.

but as I say this 170 k/s is stable, and v.40 moves from 200 k/s to 100 or even 60 k/s and back...

[Nuri]

PIII-1000

v.040cmov 279 kp/sec
v.041cmov 255 kp/sec
v.041sse2 crashes (040sse does not)


PIII-something
v.040cmov 236 kp/sec
v.041cmov 221 kp/sec


PIV-something
v.040sse2 143 kp/sec
v.041sse2 180 kp/sec ===> 26% speed increase!!!! I'm not complaining or anything, but is there something wrong with this???

PS: I'll try it with another PIV later and post it's result.

[mklasson]

Alright, don't put too much effort into testing 0.41. I'll have a new one out soon.

As for the SSE2 crashing on P3 -- it should do that. Strange that 0.40SSE2 didn't.
26% up P4 sounds a bit much, but not wholly unreasonable.

[mklasson]

Ok, give 0.42 a try. http://n137.ryd.student.liu.se/proth_sieve.php

This one should give better speed for SOBbers. I see a slight speed increase from 0.40. Let me know what you see.

Mikael

[Deoje]

my speeds (see post above) were on an AMD Athlon XP (Barton) 2800+ overclocked slightly to 2224.42mhz (approx. 3000+)

[MJX]

celeron 400@411, based on pII, 128kb L2cache
proth_sieve_cmov 0.40 107-108 kp/s
proth_sieve_cmov 0.42 112-113 kp/s... :)

[Deoje]

Just tried ver. 42
hovered around 653kp/s
Still slower than the reported speed from ver.40 (reported between 699kp/s and 645kp/s averaged about 670kp/s) for me but a lot closer.
Do you know if ver. 40 might have just been reporting the speed wrong?

Also when the reported speed from ver. 40 was above about 600kp/s it would only report 645 or 699kp/s and nothing else. Was it rounding to these numbers?
Maybe ver. 42 is just a lot more accurate in reporting the speed. That would be good.
Thanks for the quick response and the hard work on proth_sieve! :thumbs:

[mklasson]

Thanks. Yeah, there's definitely a bit of rounding going on. My timing routines suck at the moment... The best way to check speed is to do a decently sized range (say 50M) and then look at the
"Total time: xxx ms."
at the end. You'll want to use the same range for all tests of course.

[hc_grove]

mklasson: What would it take to get a SSE2 version for Linux? Login to a Linux-box running on a P4? I could create an account on my laptop for you if you'll send me an SSH-key, and as we are in the same timezone we could probably agree on a time where I make sure it's on the net.

If you're interested I'll PM you my email.

.Henrik

[mklasson]

Henrik,

that would definitely work, but it may not be necessary. If you could download
http://n137.ryd.student.liu.se/TEST_proth_sieve_042_linux_sse2.tgz
or
http://n137.ryd.student.liu.se/TEST_proth_sieve_042_linux_sse2_static.tgz
and test one of them I'd be pleased to hear your results.

Mikael

[hc_grove]

I've tried the non-static version and it runs on my laptop and it runs 10-15% faster than the cmov-version.

But still only ~240kp/s on a 2GHz, it will still be better used for factoring, but it's still nice to have the choice.

I can try the static version tomorrow if it's needed.

.Henrik

[Deoje]

I just looked at some stat files from previous ranges using ver.40 and they were all around 644kp/s so I am seeing a speed increase.
:cheers:

[Death]

left it overnight .41

p = 666012253370873 @ 195kp/s



now try .42

[Death]

sse2.42 - 199-201 ki/s without deviations
cmov.42 - 150 drops to 100 ki/s
regular.42 - 142-136 ki/s

well nice! very stable speed!!! and speed increase is also very impressive

thank you!

666000 sieving cause such improvements =)))
:blush:






and just one request
please add version number to file name.
someone want to keep few clients in a same directory.


and how about service installer??? :help:


(can't remember how many time i write this for developers) :rotfl:

[Mystwalker]

Concerning the "count-down" feature:

It would be useful e.g. when someone has two PCs crunching on a big range. Then, he could set up one machine counting up and the other counting down. Assuming he takes care that they don't run into each other (range-wise), this wouldn't require much work.

Dunno... already had sort of this scenario two or three times. It'd be a nice-to-have feature IMHO, but I rate it low priority.

[Death]

wow. I'm not alone!!! this feature indeed not high priority but very useful.
imho it's implementing not so difficult.
and it's also can be some speed increment (but also can be not).
maybe somebody can explain something about speed for up and down sieving

and sobistrator can do this job.
when it sees that two machines meed at the middle of range (assuming equal crunching rate) it add next reserved range to nextrange.txt and all starts from the beginning.

[mklasson]

I doubt I'll implement downwards sieving -- too much hassle and too little value. Just split the range evenly if you've got two (or more) machines doing the same range. Sobistrator's even got a button that distributes a range evenly over all machines, taking their individual sieve speeds into account.

But anyhow, I've done some more tests and verified that the linux SSE2 client indeed works fine now so I've added a link to it at http://n137.ryd.student.liu.se/proth_sieve.php. (Thanks for the prodding Henrik). Any Athlon64 users sieving under linux will likely want to use it.

Oh, and as for version number in filename. Just rename it yourself. :) I prefer having the version number in the archive name but not in the executable name.

Mikael

[Death]

How long it takes to replace INC with DEC and ADD with SUB? ;)
But I'm not insist. If you don't want to do this we can't force you ... +)

and for version number.... do you have any reasons for this?

[mklasson]

Long enough. :)

Version number: personal preference. Easier to upgrade for one thing. Just copy over the old executable instead of having to change scripts that reference it and whatnot.

[Death]

well. as you wish.

maybe sometime you change your mind.

[jjjjL]

Originally posted by mklasson
Long enough. :)

Version number: personal preference. Easier to upgrade for one thing. Just copy over the old executable instead of having to change scripts that reference it and whatnot.

I totally agree with your decissions. As a developer, I would never do either of those things. (ie, adding a pointless, confusing feature and renaming the executable)

Cheers,
Louie

[Death]

so we as users must do it manually... =)))))

and there's nothing confusing about this feature
you give to proth_sieve two numbers and if first is larger than secont it starts the countdown/

btw, two factors was autosubmitted at holidays
666153670507067 | 21181*2^2106740+1
666162285968381 | 33661*2^2581920+1

666.154T 21181 2106740 6.662 Sun 22-Feb-2004 5543.673 16.65
666.079T 22699 8854534 6.661 Wed 18-Feb-2004 163195.110 16.65

well done!!!
thank you very much!!!!!!!!

[Nuri]

Originally posted by Death
so we as users must do it manually... =)))))

and there's nothing confusing about this feature
you give to proth_sieve two numbers and if first is larger than secont it starts the countdown

Well, I think this will bring the risk of (especially an inexperienced user) to, say, input; 215300 as and 21540 (instead of 215400), and the program thinks the user wants to sieve downwards from 215300 to 21540 until the user notices something is wrong.

This may sound as a silly mistake, but it might happen. We all have made various mistakes down the path. Even one of the most experienced sievers might fall into such a mistake out of carefullness.


It is for our best interest to keep the client as easy to use as possible.


PS: If there is really a benefit in downward sieving, then it is fine. But after 13 months of sieving, I do not think there is. It will only complicate things a bit more.

[Death]

well. for this case there can be --down commandline key.

nevermind as author says he won't do this. =(

[Death]

one thing about first time start
it look's like a (kinda, don't want ro restart running client)


Sieve from : XXXXXX
Sieve to : YYYYYY


but should look like


Sieve from : XXXXXX
Sieve to : YYYYYY


ie two extra spaces after "sieve to" and ":" to align input positions.

as says Nuri


Well, I think this will bring the risk of (especially an inexperienced user) to, say, input; 215300 as and 21540 (instead of 215400)

[Keroberts1]

I was just wondering if the dat file is updated every time a new factor is found or if it has been updated at all since the last K value was removed? My understanding is that it hasn't. Would it be difficult to have it automatically updated so an up to date copy can be obtained anytime? If this would be to dificult to do then no problem just say and I'll forget about it completely as I believe I've been told before removing N values makes very little difference in the speed of the siever, however this would eliminate duplicates from showing up and even a tiny speed up is a speed-up. Ohh oyu know how we DC'ers are. We love to strangle every little bit out of our limited resources.

A second side question was can the client be optimized for higher P values? I believe i heard that mentioned before. At waht point would that become reasonable, if ever?

[dmbrubac]

I've been searching this forum for a discussion of the excluded factor file and haven't found it, so my apologies if I beating a dead horse....

The current PRP range is 6630284 < n < 6830284 (from MikeH's stats pages)

but in factexcl.txt I'm finding
325031458051441 | 33661*2^6912408+1
324982891732153 | 55459*2^7352074+1
324981044968207 | 67607*2^6727819+1
324964190065829 | 33661*2^6970800+1
etc.

Why are these excluded?

Oh.. OK, probably this thread (http://www.free-dc.org/forum/showthread.php?s=&threadid=6901)

[Troodon]

See: http://www.free-dc.org/forum/showthread.php?s=&threadid=6797

PS: dmbrubac, do you read your private messages on this forum? I have sent you one a moth ago and you still haven't readed it :eek: .