Hi again!

Ok, it seems to be working :smile:

I will test later several other cenarios, and will give here the feedback.

Now another matter:

Lets suppoese the same cenario as before, 2 Command prompts.

As they are on diferent directories, from time to time i stop (with Ctrl-C) the 2nd client to copy the "add" file to the first directory.

Lets suppose that i stop the 2nd client at the start of q 470000 to 480000 processing.

When i resume the 2nd client it says resuming from q 470000 to 480000, but no work is done on this range.

I mean, almost imediatly the range q 490000 to 500000 is started.

This means that range 470000 to 480000 is not processed, i think ?

Regards,
scalabis

Unfortunately the multiple client code is not very robust as it has had very little testing before now. I suspect that your supposition about gaps in coverage is correct.

I'll have to reflect on what might be done to improve it. But there won't be any quick fixes I'm afraid.

Brian

Tests ...
 

Ok, some more tests ...

1st run:

One Command prompt, a 87 digit semiprime;

q is parsed from 300000 to 690000 where the estimated minimum is reached. Everything ok.

2nd run:

two Command prompts, Python Driver run twice, over the same directory;

it starts ok, each windows parsing in turn q 300000 to 310000 and the other q 310000 to 320000.

But along the way the percentage of relations found is not right:

[quote]
Found 1471204 relations, 96.8% of the estimated minimum (1520000).
compressing spairs.out to spairs.save.gz
-> making sieve job for q from 460000 to 465000 as file test.job.T0
-> making sieve job for q from 465000 to 470000 as file test.job.T1
-> Lattice sieving algebraic q from 460000 to 470000.
-> gnfs-lasieve4I11e -k -o spairs.out.T0 -v -n100 -a test.job.T0
-> gnfs-lasieve4I11e -k -o spairs.out.T1 -v -n101 -a test.job.T1
FBsize 38377+0 (deg 4), 49097+0 (deg 1)
FBsize 38377+0 (deg 4), 49097+0 (deg 1)
total yield: 18291, q=465007 (0.00375 sec/rel)
368 Special q, 568 reduction iterations
reports: 31510045->3246135->2971797->606257->606257->606257
Number of relations with k rational and l algebraic primes for (k,l)=:
Total yield: 18291
milliseconds total: Sieve 18147 Sched 0 medsched 8046
TD 15541 (Init 795, MPQS 2563) Sieve-Change 18293
TD side 0: init/small/medium/large/search: 220 1175 496 454 3923
sieve: init/small/medium/large/search: 1278 4103 687 374 3277
TD side 1: init/small/medium/large/search: 123 921 313 885 6236
sieve: init/small/medium/large/search: 671 2311 389 375 4682
total yield: 20152, q=470021 (0.00361 sec/rel)
402 Special q, 585 reduction iterations
reports: 34401042->3546830->3243487->663409->663405->663405
Number of relations with k rational and l algebraic primes for (k,l)=:
Total yield: 20152
milliseconds total: Sieve 20239 Sched 0 medsched 9719
TD 18413 (Init 1328, MPQS 2877) Sieve-Change 15963
TD side 0: init/small/medium/large/search: 124 1864 515 360 4660
sieve: init/small/medium/large/search: 1150 4350 718 513 3165
TD side 1: init/small/medium/large/search: 126 1187 563 501 7185
sieve: init/small/medium/large/search: 634 2971 826 437 5475
appending spairs.out.T0 to spairs.out
appending spairs.out.T1 to spairs.out
appending spairs.add.2 to spairs.out
appending spairs.out to test.dat
Found 1824305 relations, 120.0% of the estimated minimum (1520000).
-> msieve -s Test\test.dat -l Test\test.log -i Test\test.ini -nf Test\test.fb -t
2 -nc1
[/quote]

With q between 460000 and 470000, msieve is called the first time.

Sieving on Command prompt 1, gets more and more delayed (because msieve is invoked)

I stopped work on window 2, at this point:

[quote]
Total yield: 24097
milliseconds total: Sieve 14882 Sched 0 medsched 5966
TD 16183 (Init 1022, MPQS 2543) Sieve-Change 15639
TD side 0: init/small/medium/large/search: 141 1133 339 542 4913
sieve: init/small/medium/large/search: 968 2811 687 604 2247
TD side 1: init/small/medium/large/search: 31 845 311 513 6393
sieve: init/small/medium/large/search: 486 2476 467 440 3696
appending spairs.out.2.T0 to spairs.out.2
appending spairs.out.2.T1 to spairs.out.2
appending spairs.out.2 to spairs.add.2
-> making sieve job for q from 690000 to 695000 as file test.job.2.T0
-> making sieve job for q from 695000 to 700000 as file test.job.2.T1
-> Lattice sieving algebraic q from 690000 to 700000.
-> gnfs-lasieve4I11e -k -o spairs.out.2.T0 -v -n200 -a test.job.2.T0
-> gnfs-lasieve4I11e -k -o spairs.out.2.T1 -v -n201 -a test.job.2.T1
FBsize 49082+0 (deg 4), 49097+0 (deg 1)
FBsize 49082+0 (deg 4), 49097+0 (deg 1)
total yield: 16911, q=699077 (0.00185 sec/rel)siever terminated
appending spairs.out.2.T0 to spairs.out.2
appending spairs.out.2.T1 to spairs.out.2
-> Return value -1073741783. Updating job file and terminating...
appending spairs.out.2 to spairs.add.2
[/quote]

On window 1, i had to wait until:

[quote]
Total yield: 21267
milliseconds total: Sieve 9224 Sched 0 medsched 4274
TD 10519 (Init 565, MPQS 1874) Sieve-Change 9880
TD side 0: init/small/medium/large/search: 94 644 328 294 2770
sieve: init/small/medium/large/search: 688 1609 262 217 1469
TD side 1: init/small/medium/large/search: 32 919 310 124 4439
sieve: init/small/medium/large/search: 315 1449 281 200 2734
appending spairs.out.T0 to spairs.out
appending spairs.out.T1 to spairs.out
appending spairs.add.2 to spairs.out
appending spairs.out to test.dat
Found 8291988 relations, 545.5% of the estimated minimum (1520000).
-> msieve -s Test\test.dat -l Test\test.log -i Test\test.ini -nf Test\test.fb -t
2 -nc1
compressing spairs.out to spairs.save.gz
-> Running matrix solving step ...
-> msieve -s Test\test.dat -l Test\test.log -i Test\test.ini -nf Test\test.fb -t
2 -nc2
linear algebra completed 64285 of 71903 dimensions (89.4%, ETA 0h 0m)
-> Running square root step ...
-> msieve -s Test\test.dat -l Test\test.log -i Test\test.ini -nf Test\test.fb -t
2 -nc3
-> Computing 1.26904e+09 scale for this machine...
-> procrels -speedtest> PIPE
Scaled time: 0.42 units (timescale= 1.196).
-> Factorization summary written to g87-test.txt
[/quote]


545.5%, has to be wrong ...

Best regards,
scalabis

I am not sure about the relations reporting but I have had a look at improving the sieving in multiple client situations. You might like to try the attached version - at this stage it is a special version for testing the new approach only. Unless people are trying to use multiple clients, it would be safer staying with the earlier version for the moment.

Brian

Hi!

Count me in.

I will try it, as soon as i can.

Thanks.

Regards,
scalabis

I found a few bugs in the version I posted earlier - here is a better version. BUT this is still EXPERIMENTAL.

Brian

Hello, I just decided to try out factmsieve.py today and ran into a problem. Hopefully someone can see what I've done wrong and help point me in the right direction. :) I'm factoring a few snfs 122 digit numbers. I create my own poly file via a program I've written. I've just downloaded python 2.6.5 32-bit and installed it on my 64-bit Windows XP computer. I have downloaded version 0.60 of the factmsieve.py script. Here is the command that I ran:
[CODE]
D:\Programming\ggnfs-msieve\c122>factmsieve01.py c001.poly
-> ________________________________________________________________
-> | Running factmsieve.py, a Python driver for MSIEVE with GGNFS |
-> | sieving support. It is Copyright, 2010, Brian Gladman and is |
-> | a conversion of factmsieve.pl that is Copyright, 2004, Chris |
-> | Monico. This is version 0.60, dated 19th March 2010. |
-> |______________________________________________________________|
-> This is client 1 of 1
-> Using 2 threads
-> Working with NAME = c001
Traceback (most recent call last):
File "D:\Programming\ggnfs-msieve\c122\factmsieve01.py", line 1987, in <module>
read_parameters(fact_p, poly_p, lats_p)
File "D:\Programming\ggnfs-msieve\c122\factmsieve01.py", line 1312, in read_parameters
.format(Y1, poly_p['m'], Y0, fact_p['n']))
NameError: global name 'Y1' is not defined
[/CODE]

And here is the poly file that I used:
[CODE]
name: c001.poly
n: 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000049
m: 1000000000000000000000000
deg: 5
c5: 10
c4: 0
c3: 0
c2: 0
c1: 0
c0: 49
Y1: 1
Y0: -1000000000000000000000000
skew: 1.37
type: snfs
rlim:
alim:
lpbr:
lpba:
mfbr:
mfba:
rlambda:
alambda:
qintsize:
[/CODE]

Can anyone see where I may have gone wrong? Does this script only accept certain poly file formats?

I'm not sure if this is the problem, but try naming it just "c001" (not "c001.poly"). (still put the poly in the file "c001.poly")

After I changed the name: line from c001.poly to c001, I still get the same error about Y1 not being defined.

Its a bug - my apologies - find the line:

.format(Y1, poly_p['m'], Y0, fact_p['n']))

referenced in the error report and replace it with:

.format(denom, poly_p['m'], numer, fact_p['n']))

I'll update the script soon but I am working on a rather big change right now. This is looking good in my testing and will make the management of sieving intervals much more robust.

Brian

[quote=WraithX;209134]
n: 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000049

...

[/code]Can anyone see where I may have gone wrong? Does this script only accept certain poly file formats?[/quote]I can't see where the error lies, but I deduce that you may be trying to find some Brilliant numbers.

Paul