Enhancing Sobistrator to work with SR2sieve?

[Joe O]

Originally Posted by jasong

Unless there's a setting I'm not aware of, absolutely.

Actually, they do not have to be multiples of 10^9.
Nextrange.txt ranges, like all of jjsieve range specifications, do not require that the numbers be multiples of 10^9.
Having posted that, if making this work for SR2sieve would require multiples of 10^9 as is required in SR2work.txt, then go for it.

[Joe O]

Originally Posted by geoff

Getting sr2sieve to work with Sobistrator will take more changes than I first realised. Can someone who uses Sobistrator answer these questions:

Is it necessary to make sr2sieve wait when it finds that nextrange.txt is empty, or is it OK just to exit?

Are the ranges in nextrange.txt always multiples of 10^9?

I still think that changing Sobistrator is the better way to go. That is why I sent you the source, and that is why I suggested changing the output to GLADE instead of MFC windows. That would give us the benefit of running under Linux as well as Windows. If LUA would be better than GLADE, then by all means do it in LUA.

[geoff]

Originally Posted by Joe O

I still think that changing Sobistrator is the better way to go. That is why I sent you the source, and that is why I suggested changing the output to GLADE instead of MFC windows. That would give us the benefit of running under Linux as well as Windows. If LUA would be better than GLADE, then by all means do it in LUA.

The problem is that I have never used GLADE or LUA, or any graphics library for that matter. I am also far from fluent in C++. I figure that if I can add a switch to sr2sieve to make it use SoBStatus.dat and nextrange.txt instead of checkpoint.txt and sr2work.txt, then maybe someone else can compile Sobistrator for Linux.

[geoff]

sr2sieve 1.6.10 has a new -j switch that will make it behave in a similar way to JJsieve or proth_sieve, for compatibility with Sobistrator. Checkpoints are written to SoBStatus.dat, ranges are read from nextrange.txt.

It should be possible to start a range with JJsieve and continue it with `sr2sieve -j -s', and vice versa.

I haven't actually tested it with Sobistrator though, so let me know if there are any problems.

[benjackson]

Any other changes in 1.6.10 or is it not worth installing over everything we have running 1.6.9 if we don't use sobistrator?

[KriZp]

seems to work, if one adds pmin= and pmax= lines to either nextrange.txt or SoBStatus.dat before starting.

If I kill the client with ctrl+C it writes crazy values to to SoBStatus.dat, like so:
pmin=694214149064053 @ 220565 kp/s
pmin=694214156402581 @ 1091 kp/s
pmin=694214273974933 @ 220556 kp/s

After I copied sr2sieve and SoB.dat to a new directory and edited nextrange.txt with the appropriate pmin and pmax lines it produced a normal line after I shut it the first time, and then a very high one again the next time. I first thought it was because the checkpoint file was present after the first time I stopped it, but now, after a few hours and the checkpoint.txt file present the SoBStatus.dat file contains lines such as

pmin=694240577782601 @ 1044 kp/s
pmin=694240905331801 @ 1037 kp/s
pmin=694241232487189 @ 1025 kp/s
pmin=694241559773897 @ 1043 kp/s

[geoff]

Originally Posted by benjackson

Any other changes in 1.6.10 or is it not worth installing over everything we have running 1.6.9 if we don't use sobistrator?

No other changes since 1.6.9.

Originally Posted by KriZp

If I kill the client with ctrl+C it writes crazy values to to SoBStatus.dat, like so:
pmin=694214149064053 @ 220565 kp/s
pmin=694214156402581 @ 1091 kp/s
pmin=694214273974933 @ 220556 kp/s

The kp/s speed is calculated as the average since the previous checkpoint. If you shut it down very soon after a checkpoint, the speed in the final checkpoint might not be very accurate. I will try to find a better way to calculate the final checkpoint speed in a future version.

[geoff]

KriZp There was indeed a problem with the kp/s times for the first checkpoint after resuming a range from SoBStatus.dat, it should work properly in sr2sieve version 1.6.11.

[Joe O]

Originally Posted by vjs

Joe,

II tried the drop method into a folder currently running jjsieve and come up with the following error.

Line 1: unparsed range in file 'SoBStatus.dat'


also with a core quad should i be using the --sse2 switch or does it autodetect?

This was posted to me on the SoB forum: http://www.free-dc.org/forum/showthr...556#post115556