Python Driver for GGNFS and MSIEVE

[Brian Gladman]

It's in the range where I had a mistake in the minrels formula so I think you should have enough. But I have very little experience with this so I would be the wrong person to listen to.

Brian

[10metreh]

4.5M relations should be (possibly more than) enough for a c102.

[Andi47]

Originally Posted by EdH

I currently have a c102 that wants 7.695e+06 relations, with the following:
(test.job.T0)

<snip>
rlim: 2300000
alim: 1249999
lpbr: 26
lpba: 26
mfbr: 49
mfba: 49
rlambda: 2.6
alambda: 2.6

According to my table I expect that you will need ~4.0M to 4.4M relations with these parameters.

[EdH]

Thanks for the relations info. If I can, I'll interrupt the script and give it an early try.

Brian,

In case you didn't notice, there's a post in the "Running GGNFS" thread that references a modification to your script, dealing with threads vs. clients, etc.

[Brian Gladman]

Originally Posted by EdH

Thanks for the relations info. If I can, I'll interrupt the script and give it an early try.

Brian,

In case you didn't notice, there's a post in the "Running GGNFS" thread that references a modification to your script, dealing with threads vs. clients, etc.

Thanks - I hadn't noticed this. I have said that I will respond to the issues raised on this thread as I don't want to fragment discusssion of the script.

Brian

[Brian Gladman]

I have attached a _tentative_ attempt to cure the duplicates bug in multiple client situations. I have also removed the minrels bug (this was for one of the lpbr values).

I would be grateful for feedback on this as it is very easy to make mistakes in how this should be done. Please bear in mind that this may well contain bugs.

Brian

[EdH]

I interrupted it at a little over the 63.2% mark, ending up with 4963034 relations of the requested 7695000 (just shy of 65%). This worked fine and I have advanced the sequence another line. Thanks for the info.

I am now in the process of making the new script available on two (1 linux, 1 WinXP) machines. I'll let you know how they turn out at the next opportunity.

Thanks for all the work.

Take Care,
Ed

[EdH]

Version 0.64 has completed one cycle on each of the above mentioned machines, with it nearing a second completion on the WinXP one. I have also installed 0.64 on a third (linux) machine.

Thanks for all the work...

[EdH]

All my machines seem to be running 0.64 with no issues, but they are also single core. I did notice one thing that isn't any sort of issue, but thought I'd mention it, in case it is of interest:

In my g##-test.txt files, there is a single line at the bottom:

--------- CPU info (if available) ----------

There is no further info for any of my machines (WinXP, linux). I know that "cat /proc/cpuinfo" will give me linux info, but I couldn't figure out how to incorporate that into the script, or even whether it would work within the script. I have no idea how to ask WinXP.

Take Care,
Ed

[Brian Gladman]

Originally Posted by EdH

All my machines seem to be running 0.64 with no issues, but they are also single core. I did notice one thing that isn't any sort of issue, but thought I'd mention it, in case it is of interest:

In my g##-test.txt files, there is a single line at the bottom:

--------- CPU info (if available) ----------

There is no further info for any of my machines (WinXP, linux). I know that "cat /proc/cpuinfo" will give me linux info, but I couldn't figure out how to incorporate that into the script, or even whether it would work within the script. I have no idea how to ask WinXP.

Hi Ed,

The big change is to try to get multiple clients to work without creating duplicates. I think the multiple thread situation is ok. So if your clients are combining their results correctly, that is good evidence that I have a multiple client fix.

On CPU information I had not got round to publishing proc_info but I have attached versions of it for win32 and x64 on Windows. If you put the appropriate binary in your ggnfs binary directory, it should provide processor information. For *nix I have included the source code that needs to be compiled to produce the proc_info binary.

Brian

[EdH]

Thanks Brian,

But, I guess I'm not bright enough to get this compiled on my linux machine:

[ID@CompName]$ gcc proc_info.c -o proc_info
proc_info.c: In function ‘get_processor_info’:
proc_info.c:31: error: ‘FILE’ undeclared (first use in this function)
proc_info.c:31: error: (Each undeclared identifier is reported only once
proc_info.c:31: error: for each function it appears in.)
proc_info.c:31: error: ‘fp’ undeclared (first use in this function)
proc_info.c:38: error: ‘EXIT_FAILURE’ undeclared (first use in this function)
proc_info.c:42: warning: incompatible implicit declaration of built-in function ‘strstr’
proc_info.c:51: warning: incompatible implicit declaration of built-in function ‘strcpy’
proc_info.c:52: warning: incompatible implicit declaration of built-in function ‘strlen’
proc_info.c:64: warning: incompatible implicit declaration of built-in function ‘strcpy’
proc_info.c:65: warning: incompatible implicit declaration of built-in function ‘strlen’
proc_info.c:78: warning: incompatible implicit declaration of built-in function ‘sprintf’
proc_info.c:79: error: ‘EXIT_SUCCESS’ undeclared (first use in this function)
proc_info.c: In function ‘main’:
proc_info.c:142: error: ‘DWORD’ undeclared (first use in this function)
proc_info.c:142: error: expected ‘;’ before ‘bsize’
proc_info.c:143: error: ‘HKEY’ undeclared (first use in this function)
proc_info.c:143: error: expected ‘;’ before ‘hKey’
proc_info.c:144: error: ‘_MAX_PATH’ undeclared (first use in this function)
proc_info.c:149: warning: incompatible implicit declaration of built-in function ‘printf’
[ID@CompName]$

Here's my GCC info:

[ID@CompName]$ gcc -v
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i586 --build=i586-redhat-linux
Thread model: posix
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) 
[ID@CompName]$

Do I need to add in some switches? Or, am I missing a header or library?

It's not really anything pressing. Everything seems to be running just fine the way it is. I just happened to notice it as I was looking over some files.

Take Care,
Ed