Two questions: is there any work to getting mfaktc CPU independent?

And two, more complicated: I have 4 cores, 8 threads. I have 3 P95 workers running on two threads apiece, occupying logical CPU's 3-8. I had the last worker running only on logical CPU 1, leaving 2 empty for mfaktc. When I started mfaktc, it started taking cycles from all of the other CPU's, affecting their performance and not making use of logical thread 2. Is there anyway to set mfaktc onto one particular core/thread?

[QUOTE=ET_;269068]Does it work with CUDA 3.X (especially 3.0)?
Having a GTX275 I can't access to 2.0 capabilities delivered by CUDA 4.0.[/QUOTE]

You can use CUDA 4.0 on your GTX 275, you just can't take advantage of the fancy new features that require CC 2.x. I'm stuck in the same boat with the Tesla S1070.

But yes, the 4.0 driver will run code compiled with 3.x.

[QUOTE=Dubslow;269085]Two questions: is there any work to getting mfaktc CPU independent?

And two, more complicated: I have 4 cores, 8 threads. I have 3 P95 workers running on two threads apiece, occupying logical CPU's 3-8. I had the last worker running only on logical CPU 1, leaving 2 empty for mfaktc. When I started mfaktc, it started taking cycles from all of the other CPU's, affecting their performance and not making use of logical thread 2. Is there anyway to set mfaktc onto one particular core/thread?[/QUOTE]

Right now, making mfaktc more CPU-independent by doing sieving on the card is on my wish list. It's taking me longer than I would like to make mfaktc talk to primenet, so I'll be happy if someone comes along and scoops me (does the job first). Oliver might do the job, too, so check with him.

Second, from the standpoint of either Windows or Linux, mfaktc is "just a program", not really using threads. If you want to lock it to a particular CPU core, ask your OS to do that. If you want to set its priority, ask your OS to do that. I think it's part of task manager in Windows.

Oh, and I'm pretty sure that it is not effective to try to use more logical cores than you have physical cores -- you just waste less time in context switching than if you ran twice as many threads as you had CPU -- but you still pay for the context switches.

[QUOTE=Christenson;269092]If you want to lock it to a particular CPU core, ask your OS to do that. If you want to set its priority, ask your OS to do that. I think it's part of task manager in Windows.[/QUOTE]It is. Processes tab, right-click on mfaktc.exe and choose either "Set Priority" or "Set Affinity..." as appropriate.

[QUOTE=frmky;269086]You can use CUDA 4.0 on your GTX 275, you just can't take advantage of the fancy new features that require CC 2.x. I'm stuck in the same boat with the Tesla S1070.

But yes, the 4.0 driver will run code compiled with 3.x.[/QUOTE]

Thank you very much! :bow:

Luigi

What does "avg. wait" mean? I get values from ca. 100 to ca. 3000 alternating... and 60M/s on my GT555M.

[QUOTE=MrHappy;269519]What does "avg. wait" mean? I get values from ca. 100 to ca. 3000 alternating... and 60M/s on my GT555M.[/QUOTE]
CPU average waiting time for GPU "hunger" (sieving part done in CPU). Values < 100 indicate process is CPU limited, values > 1000 indicate GPU being saturated.

[QUOTE=xilman;268894]Miserable failure here[/QUOTE]Success. :smile:

The 280 series driver turned up and installed fine. Most of the SDK built and run once the gcc version check had been disabled. The only thing missing are the graphical demos and that only because I haven't installed the GL libraries yet.

Thanks, everyone, for your help and/or encouragement.

Paul

[QUOTE=James Heinrich;269101]It is. Processes tab, right-click on mfaktc.exe and choose either "Set Priority" or "Set Affinity..." as appropriate.[/QUOTE]

Thanks, I'll give it a shot next time I'm in Windows. Now, on to the next problem: I can't compile the source in Linux, as detailed above; it doesn't support my newer GCC version. I removed the line that checks the GCC version, and then it compiled, but didn't run anyways. Can somebody zip up a working Linux64 executable for me? (Or anybody else either having compiling problems or not technical enough to try.)

Hi!

[QUOTE=Dubslow;270576]Now, on to the next problem: I can't compile the source in Linux, as detailed above; it doesn't support my newer GCC version. I removed the line that checks the GCC version, and then it compiled, but didn't run anyways. Can somebody zip up a working Linux64 executable for me? (Or anybody else either having compiling problems or not technical enough to try.)[/QUOTE]

can you describe the problem? "didn't run anyways" doesn't help.
I uncommented the version check once on a openSUSE 11.4 with CUDA 4.0 and it seems to work fine for mfaktc.
Anyway I'll try to provide a Linux64 binary later.

Oliver

Hi,

you can find a Linux x86-64 binary here: [url]http://www.mersenneforum.org/mfaktc/mfaktc-0.17.linux64.tar.gz[/url]
let me know if this works. If it tells you that it can't find libcudart.so.3 you can try to run 'LD_LIBRARY_PATH=./lib ./mfaktc.exe'.

Oliver

Cool, thanks. Do you have any idea how to get one worker thread to stop in Linux? It was in the GUI in Windows, but I can't find it anywhere in the -m menu.

Hmm. It runs fine except that it throws errors reading the worktodo.txt file. I'm using the same file as in Windows, and it has the right number of lines, so I know it's reading the same file, but I can't tell why it won't work. The file looks just fine in gedit. It says WARNING: ignoring line () Reason: invalid data

The first thing to check is if the lines end with CRLF instead of just LF. Try running dos2unix against a copy of worktodo.txt and see if it changes size. If it does try running with the new file.

Chris K

Thanks, I've noticed that Windows doesn't separate lines written while in Linux, so I'll give it a shot (although you'd think opening it in nano or gedit would change it back to linux format). What are CRLF and LF? (I imagine they're part of the difference between dos and unix?)

[QUOTE=Dubslow;271107]What are CRLF and LF?[/QUOTE]There is of course a whole [url=http://en.wikipedia.org/wiki/Newline]Wikipedia article on the subject[/url], but in short:

CR = Carriage Return = ASCII character 13, sometimes written as \r
LF = Line Feed = ASCII character 10, sometimes written as \n

Quoting the footnote of the Wikipedia article:[quote]The origin of the older computer term "CRLF" - which redirects to this Newline article - or "Carriage Return [and] Line Feed", derives from standard manual typewriter design, whereby at the end of a line of text the typist pushes a lever at the left end of the carriage to return it to position for beginning the next line. In so doing, a mechanism also rolls the typewriter's platen by one line, advancing ("feeding") the paper to the correct position.[/quote]

Unix uses LF to separate lines.
Mac uses CR to separate lines.
Windows uses CR+LF to separate lines.

If you open a Unix or Mac file in Notepad, for example, it's looking for CR+LF characters to separate the lines, and doesn't find them, so assumes it's all one line. If you open a Windows file on a Mac or Unix machine, you'll get proper line separation, but with an extra (possibly invisible) character at the beginning or end of each line. Of course, any of the better text editors on any platform are aware of the various newline variants and will display all files properly, and also not break them when re-saving them.

"DOS"[CODE]$ cat test.txt | od -c
0000000 a \r \n b \r \n c
0000007[/CODE]"Unix"[code]$ cat test.txt | tr -d '\r' | od -c
0000000 a \n b \n c
0000005
[/code]

Oliver (the Judger) and I are discussing the parser right now, and we intend to make it ignore blank lines in the next version.

Speaking of which, is there any easy way to see what the latest release is? Also, thanks for all the tips, very useful, and also helps me understand why 1. I don't have this problem with M/Prime/95 and 2. Why all the read me files and such with mfaktc came out all wrong in notepad.
Thanks guys!

Latest release is mfaktc0.17. Oliver is working on 0.18pre6.

[QUOTE]Speaking of which, is there any easy way to see what the latest release is?[/QUOTE][url]http://www.mersenneforum.org/mfaktc/[/url]

Hello,

[QUOTE=Dubslow;271257]2. Why all the read me files and such with mfaktc came out all wrong in notepad.
Thanks guys![/QUOTE]

Again LF vs. CRLF. On Windows you can try wordpad instead of notepad.

[url]http://www.mersennewiki.org/index.php/Mfaktc[/url]
[url]http://www.mersenneforum.org/mfaktc/[/url]

[QUOTE=Xyzzy;271298][url]http://www.mersenneforum.org/mfaktc/[/url][/QUOTE]

That link looks a bit hard to find...what page is it on?

[QUOTE=Christenson;271320]That link looks a bit hard to find...what page is it on?[/QUOTE][url]http://www.mersenneforum.org/mfaktc/[/url] [i]is[/i] the page, on which are links to two .gz and two .zip files containing the four diffferent flavors of the latest release.

Mr Cheesehead, I don't think you got my meaning.

I was asking how to navigate to it, assuming I didn't know about it from your nice post above. That is, what page(s) besides this thread, have your link on them? (not that it's really needed, given the wiki page, which is the answer I was looking for.)

I don't know other pages than this thread and the mfaktc article in the mersennewiki.
The directory [url]www.mersenneforum.org/mfaktc/[/url] is quiet new, not so long ago I've ask Xyzzy if he would be so nice and host the files. I've ask him because he is allready operating the (semi-)official mirror of the GIMPS software [url]www.mersenneforum.org/gimps/[/url]. He was so nice to add another directory for mfaktc. I won't attach new releases here in the forum from now, instead I'll just post links. An advantage is that I'm no longer limited to the maximum attachment size here in the forum so I can easily bundle the CUDA library files. So we have to say: thank you, Xyzzy!

Oliver

Hey, is there any reason we can't get mfaktc, mfakto, and CUDALucas all linked in the same way under the GPU Computing subheader? Or a short mersennewiki page made with the list of GPU programs linking things, and a link to that under the GPU computing header?

Indeed, thank you XYZZY...

[QUOTE=Christenson;271386]Hey, is there any reason we can't get mfaktc, mfakto, and CUDALucas all linked in the same way under the GPU Computing subheader? Or a short mersennewiki page made with the list of GPU programs linking things, and a link to that under the GPU computing header?
[/QUOTE]
This week I obtained a mersennewiki account to start working on a GPU computing page(s). First, though, I need to learn how to use the wiki and also look around so that I don't end up duplicating someone else's effort or stepping on their toes.

One of the many things I'd do on such a page would be to list all the GPU programs (and link to their pages, of course).

If a GPU Computing page already exists, please let me know and send a link -- thanks!

Rodrigo

Let me make my suggestion explicit, then:
This subforum gets a link to Rodrigo's page at the top...Rodrigo's page then links to the pages for each of the GPU programs....
Thanks, Rodrigo...I don't think there are any toes to be stepped on here!

[QUOTE=Christenson;271358]I was asking how to navigate to it, assuming I didn't know about it from your nice post above. That is, what page(s) besides this thread, have your link on them?[/QUOTE]Oh, I'm sorry I missed that point. :-(

Turns out Ubuntu doesn't have dos2unix etc., but I wound up using a sed command to get the job done (taken from Wikipedia, of course). The problem now is getting the affinity to work. I'm using the command taskset, and I'm pretty sure the affinity is being set properly, but either way my candidate rate cuts in half whenever I run three MPrime workers alongside mfaktc, even though they're on separate cores. I haven't had this problem in Windows.

mfaktc, at present, thinks it is single-threaded, and relies upon you to set both it's priority and it's core.

With MPrime off, mfaktc runs totally on logical 7, gets an avg. rate of 180-185, and avg. wait of 100-100 us.
When I run MPrime on 1-6 (which order I start them doesn't matter) mfaktc runs on 7 or 8 (as I set it to) but only gets an avg. rate around 90-100, with avg. wait < 100.
They both run with the same Sieve Prime setting. (And auto-adjusting is on.)
This does not occur in Windows. With the same affinities and Prime95 running 1-6, I still get around 165-170 with mfaktc.

wait a minute...are you sure that logical 7 and 8 on your machine are in fact on one core? Surely you don't have 8 physical cores, do you?

[QUOTE]Turns out Ubuntu doesn't have dos2unix…[/QUOTE][CODE]$ apt-cache show dos2unix
Package: dos2unix
Priority: extra
Section: universe/text
Installed-Size: 232
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Jari Aalto <jari.aalto@cante.net>
Architecture: amd64
Version: 5.1.1-2
Depends: libc6 (>= 2.4)
Conflicts: tofrodos (<< 1.7.8.debian.1)
Filename: pool/universe/d/dos2unix/dos2unix_5.1.1-2_amd64.deb
Size: 41770
MD5sum: d5971308a00e5449b2d8143af4ee2a92
SHA1: 9c6683d79f45a7507cef9fd67674a295dedd21a0
SHA256: 48eb2b15691a8e9ee6cc0e16c1fe3bcd764786d29ef2231b7a8a029a8466eb60
Description: convert text file line endings between CRLF and LF
This package contains utilities dos2unix, unix2dos, mac2unix,
unix2mac to convert the line endings of text files between UNIX (LF),
DOS (CRLF) and Mac (CR) formats.
.
Text files under Windows and DOS typically have two ASCII characters
at the end of each line: CR (carriage return) followed by LF (line
feed). Older Macs used just CR, while UNIX uses just LF. While most
modern editors can read all these formats, there may still be a need
to convert files between them.
.
This is the classic utility developed in 1989.
Homepage: http://freshmeat.net/projects/dos2unix
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu[/CODE]

[QUOTE]They both run with the same Sieve Prime setting. (And auto-adjusting is on.)
This does not occur in Windows. With the same affinities and Prime95 running 1-6, I still get around 165-170 with mfaktc.[/QUOTE]

The CPU numbering isn't necessarily the same in Windows and Linux; it's entirely possible that Windows has the pairing of hyperthreads as (12)(34)(56)(78) whilst, on my i7/920, I know that Linux has (18)(27)(35)(46).

Could you put up the result from 'grep apicid /proc/cpuinfo' ?

Hmm... Since I booted back to Windows to get back to the really fast rates, suddenly Windows only gets 75-80M/s... I didn't change anything!!!! What the hell?!?!? :(
Also, in Windows, it increases Sieve Primes massively until the average wait is down to a decent number; that doesn't happen in Linux with 75-80M/s rate. So confused x(
EDIT: Let me clarify. Currently, mfaktc-lin is running ~90M/s, Sieve Primes=5000 (adjust=1) and avg. wait is <100 us. Most recently in Windows, mfaktc was running 90M/s rate, 5000 SP, and 3000+ us avg. wait at start, which would shift to 75M/s, 15000+ SP, and 300-400 us avg wait after enough classes completed. I don't know why/how this behavior changed from the 170M/s +, as far as I know I didn't change anything.

Imma boot to Linux now and run that command. On the other hand, I remember testing it, and it seemed pretty clear to me that it was (12)(34)(56)(78), even though MPrime detects (15)(26)(37)(48). Huh.

This computer hates me.

EDIT:
[CODE]apicid : 0
initial apicid : 0
apicid : 2
initial apicid : 2
apicid : 4
initial apicid : 4
apicid : 6
initial apicid : 6
apicid : 1
initial apicid : 1
apicid : 3
initial apicid : 3
apicid : 5
initial apicid : 5
apicid : 7
initial apicid : 7[/CODE]
Could you please explain what exactly APIC id is?

Also also, each OS seems incapable of reading the checkpoint files of the other. Should I be converting those too?

Hi,

[QUOTE=Dubslow;271807]Also also, each OS seems incapable of reading the checkpoint files of the other. Should I be converting those too?[/QUOTE]

this is [B]not[/B] a CR/CRLF/LF problem. For safety reason mfaktc refuses to load checkpoint files from other versions than itself. Windows and Linux versions have a different version string.

I might change this in the future but not now.

Oliver

[QUOTE=Dubslow;271807]
[CODE]apicid : 0
initial apicid : 0
apicid : 2
initial apicid : 2
apicid : 4
initial apicid : 4
apicid : 6
initial apicid : 6
apicid : 1
initial apicid : 1
apicid : 3
initial apicid : 3
apicid : 5
initial apicid : 5
apicid : 7
initial apicid : 7[/CODE]

Could you please explain what exactly APIC id is?[/QUOTE]

It's a hardware identifier for the processors; the two hyperthreads on processor n have ID 2n and 2n+1, so what you're seeing is (15)(26)(37)(48) as mprime has picked up. I've no idea how Linux assigns the processor numbers that it uses ... I'm reasonably trusting that, on an idle single-chip machine, a job running four threads will get them on four distinct processors rather than having two run in hyperthreads on the same processor, but on more complicated systems it doesn't seem to work as perfectly as I would hope.

Urrgggg....
Now Windows is back to 165-170M/s again and I still haven't changed anything...
In fact, I haven't even shut it down in any way since the last time it was at 75M/s...
Thanks fivemack, I'll look into modifying my MPrime settings.

RRRRRRRAAAAAAAAAGGGGGGGGGEEEEEEEEEE

mfaktc was going at 165M/s. I closed and immediately reopened it, and then it went down to 70M/s again. WHAT CHANGEDa
sdfnva'jub;gvsopofIZJX
IOHNS
io'j;JUB;;kbguxhdvc

Dubslow: just to be sure[LIST][*]precompiled binary or selfcompiled?[*]settings in mfaktc.ini (if not default)?[/LIST]
Did you check if you GPU runs in highest performance mode? On Windows you can use GPU-Z to check the actuall GPU speed (Tab: Sensors). On Linux the you can start nvidia-settings to view the actual performance mode.

Oliver

Pre compiled, 1.7. I couldn't compile anything in Windows for the life of me. I think I had 4 streams, SP=5000. Note: normally I keep SPAdjust=1, but when it's at 90M/s, the avg. wait skyrockets, so the SP goes up, which winds up reducing the avg. rate to 75M/s, so I decided to keep SP stuck to 5000 until I can get back up to previous level, i.e. 165-170M/s. [CODE]
SievePrimes=5000
# Set this to 1 to enable automatically adjustments of SievePrimes during

# runtime based on the "average wait times".


SievePrimesAdjust=0


# Set the number of CUDA streams / data sets used by mfaktc.

# NumStreams must be >= 1. In this case mfaktc can process one stream /

# data set on the GPU while the GPU can preprocess the other one. When

# NumStreams is >= 2 than the time needed to upload (CPU->GPU transfer)

# the data sets can be hidden (if the hardware supports it (most GPUs are

# supporting this)).

# On Linux systems 2 or 3 seems a good numbers. There are comments that

# Windows systems need a greater number of streams.

# A greater number increases the memory consumed by mfaktc (host and GPU

# memory). The current limit for the number of streams is 10!


NumStreams=4
# Set the number of data sets which can be preprocessed on CPU. This allows

# to tolerate more jitter on runtime of preprocessing and GPU stream

# runtime.


CPUStreams=4
# The GridSize affects the number of threads per grid.

# Depending on the number of multiprocessors of your GPU, too, the

# automatic parameter threads per grid is set to:

# GridSize = 0: 65536 < threads per grid <= 131072

# GridSize = 1: 131072 < threads per grid <= 262144

# GridSize = 2: 262144 < threads per grid <= 524288

# GridSize = 3: 524288 < threads per grid <= 1048576 (default)

# A smaller GridSize has more overhead than a bigger GridSize for long

# running jobs. For really small jobs there can be a small benefit on

# computation time if the GridSize is small. A smaller GridSize directly

# reduces the runtime per kernel launch and might result in a better

# interactivity one older GPUs.


GridSize=3
# WorkFile: the name of the file which contains the factoring assignments.

# e.g.

# worktodo.ini (Prime95 v24 and earlier)

# worktodo.txt (Prime95 v25 and newer)


WorkFile=worktodo.txt



# Checkpoints = 0: disable checkpoints

# Checkpoints = 1: enable checkpoints

# Checkpoints are needed for resume capability, after a class is finished a

# checkpoint file is written. When mfaktc is interrupted during the run and

# restarted later it will begin at the last processed class.


Checkpoints=1



# Allow to split an assignment into multiple bit ranges.

# 0 = disabled

# 1 = enabled

# Enabled Stages make only sense when StopAfterFactor is 1 or 2.


Stages=0


# possible values for StopAfterFactor:

# 0: Do not stop the current assignment after a factor was found.

# 1: When a factor was found for the current assignment stop after the

# current bitlevel. This makes only sense when Stages is enabled.

# 2: When a factor was found for the current assignment stop after the

# current class.


StopAfterFactor=2


# possible values for PrintMode:

# 0: print a new line for each finished class

# 1: overwrite the current line (more compact output)


PrintMode=1


# allow the CPU to sleep if nothing can be preprocessed?
# 0: Do not sleep if the CPU must wait for the GPU

# 1: The CPU can sleep for a short time if it has to wait for the
GPU

AllowSleep=0
[/CODE]

The frustrating thing is that I didn't change anything.

I do know it's not related to GPU clock rate. (I use MSI Afterburner in Windows.) When it's at 165M/s, changing the clock rate directly affects the avg. rate. I just tested the 90M/s half rate now: I verified it was somewhat OC'ed. I killed mfaktc, reset the clock to stock, restarted mfaktc, got exactly the same avg. rate (90M/s), then upped the rate back to slight OC (with mfaktc running this time) and the avg. rate didn't budge. (I have previously tested that avg. rate changes with clock rate changes, while mfaktc is running.) This seems to indicate to me that it's something funky with the program. GPU load is 86-87%, same as it was when running at 165M/s (I got that reading sometime last week.)

EDIT: Oh my god Windows/Linux I swear there's no extra lines in mfaktc.cfg or whatever it's called. lol, that's what you guys said :P:)

Hmm, just rebooted, now it's back to 170M/s, though as I said a few posts back, it's not just the rebooting...
How can I restart the graphics driver without rebooting?
Also, GPU-Z now shows 75-76% load, not the 85% I said earlier.

[QUOTE=Dubslow;271892]I do know it's not related to GPU clock rate. (I use MSI Afterburner in Windows.) When it's at 165M/s, changing the clock rate directly affects the avg. rate. I just tested the 90M/s half rate now: I verified it was somewhat OC'ed. I killed mfaktc, reset the clock to stock, restarted mfaktc, got exactly the same avg. rate (90M/s), then upped the rate back to slight OC (with mfaktc running this time) and the avg. rate didn't budge.[/QUOTE]
This is probably the driver downclock bug.

[QUOTE=Ralf Recker;271894]This is probably the driver downclock bug.[/QUOTE]
Yes, exiting from CUDA applications incorrectly causes top perf. levels clocks to be stuck at 410 Mhz core.

Even through Afterburner?
This only started in the last two days, and I'd been starting and stopping it for the past couple of weeks just fine.

[QUOTE=Dubslow;271918]Even through Afterburner?[/QUOTE]
Yes, because Afterburner sets the clocks for performance level 3, which the card won't reach once the "lock" (driver downclock problem) occurs.
[QUOTE=Dubslow;271918] This only started in the last two days, and I'd been starting and stopping it for the past couple of weeks just fine.[/QUOTE]
Did you upgrade your GPU drivers or did you start to overclock your card? Overclocking the CUDA cores by a few MHz already triggered the problem here. Running the card at stock clocks (or using old pre CUDA 4.0 driver versions) helped.

Hit an anomaly last night, where, for one class, GPU performance on my GTX440 suddenly doubled for no apparent reason except that I had just returned to my machine and woke it up and turned on the video in the usual way, by moving the mouse. This is under Xubuntu 10.10.

Can you point to the reports on the downclock bug for me?

[QUOTE=Christenson;271954]Hit an anomaly last night, where, for one class, GPU performance on my GTX440 suddenly doubled for no apparent reason except that I had just returned to my machine and woke it up and turned on the video in the usual way, by moving the mouse. This is under Xubuntu 10.10.

Can you point to the reports on the downclock bug for me?[/QUOTE]
I've PMed you a few links...

No, I'd been using Afterburner for about a week already. On the other hand, since my previous post, I did upgrade the drivers (standard ones, not CUDA) and got roughly a 5-10% performance boost. When mfaktc runs free on the CPU, I got 205M/s. With mfaktc on two (hyperthreaded) cores and 3 Prime95 workers running, I stilll get about 175M/s. (And I haven't noticed it do the cut-in-half thing since the driver update, though I hesitate to say that fixed it.

Fixing Mxxx has a factor reporting to primenet
 

I'd like to fix this so:
Does anyone know what format should mfaktc's "Mxxx has a factor" line should have so prime net does not misattribute it to different kind of task?

[QUOTE=apsen;272538]Does anyone know what format should mfaktc's "Mxxx has a factor" line should have so prime net does not misattribute it to different kind of task?[/QUOTE]I believe for manual result submissions, the attribution is (still) based on the size of the factor as to whether it's most likely found via TF/P-1/ECM. The fact that it has "[mfaktc <version>]" at the end of the (next) line should already be plenty to identify this as a TF factor (since mfakt* doesn't do anything else), but the manual results parser isn't quite as robust as it could be.

However, using the PrimeNet API for automated results submission, there is certainly provision for properly reporting factors according to their method of discovery: each result type (TF-F, TF-NF, P1-F, P1-NF, etc) all have their [url=http://v5.mersenne.org/v5design/v5webAPI_0.97.html#8.0]own unique result type id[/url].

I think if any manual results lines contain mfaktc then the result is attributed to TF

[QUOTE=Prime95;272545]I think if any manual results lines contain mfaktc then the result is attributed to TF[/QUOTE]

OK. I'll try to put mfaktc on the factor line and see what happens, but I think I've already tried that...

Do you have an example of a TF result that is being misattributed, that we can try and see why it might be happening?

[QUOTE=James Heinrich;272648]Do you have an example of a TF result that is being misattributed, that we can try and see why it might be happening?[/QUOTE]

I think I have only one factor that I reported via regular manual submission - and it was attributed to P-1, I think.

BTW "has a factor" line of the output does not really have "mfaktc" in it. Only subsequent one does. But I think I tried to put mfaktc manually in it and it did not help.

After that I would just have prime95 rerun bit levels with factors.

Those factors are:

[CODE]Manual testing 54259081 F-PM1 2011-07-30 12:36 5.6 1464964004267408316167 2.4586
Manual testing 55117351 F-PM1 2011-07-20 11:08 2.8 669422135975942696959 2.4586
[/CODE]

I do not really want to try submitting new factors this way as I do not like them being misattributed. Also it would have been nice if the above ones could be fixed too.

I had a factor a couple of days ago ([url]http://www.mersenne.org/report_exponent/?exp_lo=55343303[/url]) that was reported as a TF factor, and I used the default mfaktc output. Unfortunately, I clear my results file each time, so I don't think I can see what the format was, unless I can do some sort of a system restore on an individual file. The My Results page has the following line:

[CODE]Manual testing 55343303 F 2011-09-19 17:20 2.8 1386725197912266966337 5.3208[/CODE]

Could it be you had a P-1 assignment reserved on the exponent, as well as a TF assignment?

Edit: System restore won't work, not enough resolution from restore points.

Got the format. Tested M1000033 from 22-23 bits, ([url]http://www.mersenne.org/report_factors/?exp_lo=1000033[/url])

and got the following output from mfaktc:

[CODE]M1000033 has a factor: 6000199
found 1 factor(s) for M1000033 from 2^22 to 2^23 (partially tested) [mfaktc 0.17-Win 75bit_mul32][/CODE]

I think I've come to another conclusion, about the slowdowns I've sometimes experienced with mfaktc. I've been recently using CUDALucas, which has run fine without slowdowns. I stopped that and started mfaktc a few times for the above testing (over the course of not more than 5 mins) and then I tried to start it again for a third time, and then everything slowed down to half speed, including CUDALucas. This leads me to believe it's something about mfaktc causing the slowdown, because in the few minutes I was doing nothing else besides web browsing. Thoughts?

[QUOTE=Prime95;272545]I think if any manual results lines contain mfaktc then the result is attributed to TF[/QUOTE]

Looking at the output of manual result submission it seems like the code to parse factors may be not application specific - there are lines for no factors found for different apps but only one for factors found:

[CODE]No factor lines found: 0
Mfaktc no factor lines found: 0
Mfakto no factor lines found: 0
Factors found: 1
Processing result: M1000033 has a factor: 6000199
Error code: 40, error text: Factoring result for M1000033 was not needed
P-1 lines found: 0
LL lines found: 0
Mlucas lines found: 0
Glucas (G29) lines found: 0
Glucas lines found: 0
MacLucasFFTW lines found: 0
CUDALucas lines found: 0
ECM lines found: 0[/CODE]

And this time I've inserted mfaktc into the submitted line like this:

[CODE]M1000033 has a factor: 6000199 [mfaktc 0.17-Win apsen barrett79_mul32]
[/CODE]

If you use a format like that it should work fine for future factors.
Does this also mean that your mfaktc output isn't the same as mine?

Hacking the output of the various TF programs won't help anything if the PrimeNet parser isn't set up to handle them. And if it's changed to handle the new format, then it could just as easily be changed to correctly handle the current results formats.

While I don't particularly support each programmer making up their own variations to results.txt output, I would heartily welcome an "official" revision to the output specs, to which all the programs (Prime95, mfaktc, etc) could/should upgrade. Something that includes some additional useful information in an easily-parsed format, e.g.[code]
M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24]
M47575691 has a factor: 1175429360870558287187321 [PM1;520000;12480000;Prime95 26.6b1 x64][/code](including TF/P1/ECM; bit-range for TF or B1/B2 for P-1/ECM; software+version) in the above examples.

That's a great idea.

[QUOTE=James Heinrich;272707]
While I don't particularly support each programmer making up their own variations to results.txt output, I would heartily welcome an "official" revision to the output specs, to which all the programs (Prime95, mfaktc, etc) could/should upgrade.[/QUOTE]

I'm in it to fix the "official" version of mfaktc in case the problem is in it. But if primenet does not actually expect factors from mfaktc then there's nothing to do until primenet is fixed...

Like I said, the default output for me works fine with PrimeNet. So either you have some different version, or something got corrupted somewhere.

Oliver ("The judger") needs to weigh in, but I do think this tacking on a bit of tag to the "factor found" lines will let the server side do its thing, eventually. The main bit of information I would want when finding factors is whether the bit level was completed or not.

Reporting factors hasn't been such an issue with me, because it happens infrequently, therefore somewheat incorrect handling (credit, etc) doesn't affect results much.

Hi,

not a big deal to change the output style of "factor found" results but I'll do this only if the primenet servers handles them. If primenet can handle this I'll willing to release a quick fix for this (e.g. 0.17p1).

Currently the "manual result form" gives credits for TF for a "factor found" [B]if[/B] the exponent is currently assigned for TF. This can be screwed by increasing the upper TF limit if the result is split into smaller ranges (bitlevel by bitlevel). Once you report the lowest "no factor" result from multiple bitlevels the exponent if no longer assigned for TF.

Oliver

I'm using mfaktc 0.17 and I get the folowing result line when factoring to 68 bit

[CODE]
no factor for M25941901 from 2^67 to 2^68 [mfaktc 0.17-Win barrett79_mul32]
no factor for M25973971 from 2^67 to 2^68 [mfaktc 0.17-Win barrett79_mul32]
[/CODE]

Yet I see result in the [I]Recent Results[/I] list that look like the folowing:

[CODE]
no factor for M55556113 from 2^72 to 2^73 [mfaktc 0.17-Win barrett79_mul32]
no factor for M55556113 from 2^71 to 2^72 [mfaktc 0.17-Win barrett79_mul32]
no factor for M55556113 from 2^70 to 2^71 [mfaktc 0.17-Win 71bit_mul24]
no factor for M55556113 from 2^69 to 2^70 [mfaktc 0.17-Win 71bit_mul24]
[/CODE]

My guess is that the 71 bit kernel is faster for lower bound TF. Why would my machine always pick the 79 bit kernel when it looks like I am using the same version of mfaktc?

Hi,

[QUOTE=diamonddave;272880]My guess is that the 71 bit kernel is faster for lower bound TF. Why would my machine always pick the 79 bit kernel when it looks like I am using the same version of mfaktc?[/QUOTE]

your guess is (partially) wrong. On old GPUs (compute capability 1.x) the 71bit kernel is indeed faster but on newer GPUs (compute capability 2.x) the 79bit kernel is faster.

file: src/mfakt.c
[CODE]
if(kernel == AUTOSELECT_KERNEL)
{
/* select the GPU kernel (fastest GPU kernel has highest priority) */
if(mystuff->compcapa_major == 1)
{
if (bit_max <= 71) kernel = _71BIT_MUL24;
else if((bit_min >= 64) && (bit_max <= 79)) kernel = BARRETT79_MUL32;
else if (bit_max <= 75) kernel = _75BIT_MUL32;
else if((bit_min >= 64) && (bit_max <= 92) && (bit_max - bit_min == 1)) kernel = BARRETT92_MUL32;
else kernel = _95BIT_MUL32;
}
else // mystuff->compcapa_major != 1
{
if((bit_min >= 64) && (bit_max <= 79)) kernel = BARRETT79_MUL32;
else if((bit_min >= 64) && (bit_max <= 92) && (bit_max - bit_min == 1)) kernel = BARRETT92_MUL32;
else if (bit_max <= 75) kernel = _75BIT_MUL32;
else kernel = _95BIT_MUL32;
}
}
[/CODE]
as you can see they have different priorities depending on the major compute capability version.

Oliver

[QUOTE=TheJudger;272875]Hi,
Currently the "manual result form" gives credits for TF for a "factor found" [B]if[/B] the exponent is currently assigned for TF. This can be screwed by increasing the upper TF limit if the result is split into smaller ranges (bitlevel by bitlevel). Once you report the lowest "no factor" result from multiple bitlevels the exponent if no longer assigned for TF.
[/QUOTE]

So, if I report lover bit levels "no factor", then get assignment for the level I have factor, and then report factor it should be assigned to TF?

[QUOTE=Christenson;272826]The main bit of information I would want when finding factors is whether the bit level was completed or not.[/QUOTE]A valid request. Could be handled in my above proposal in a number of ways:[code]
// leave upper-limit blank if not completed (how far it got can be inferred from the factor size):
M10906243 has a factor: 23620567217973346633 [TF;64;;mfaktc 0.18-pre1-Win 71bit_mul24]

// flag the incomplete bit level in some way:
M10906243 has a factor: 23620567217973346633 [TF;64;65*;mfaktc 0.18-pre1-Win 71bit_mul24]

// in either case, this would indicate continued to end of 2^65 after factor
M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24]
[/code]

[QUOTE=James Heinrich;272893]A valid request. Could be handled in my above proposal in a number of ways:[code]
// leave upper-limit blank if not completed (how far it got can be inferred from the factor size):
M10906243 has a factor: 23620567217973346633 [TF;64;;mfaktc 0.18-pre1-Win 71bit_mul24]

// flag the incomplete bit level in some way:
M10906243 has a factor: 23620567217973346633 [TF;64;65*;mfaktc 0.18-pre1-Win 71bit_mul24]

// in either case, this would indicate continued to end of 2^65 after factor
M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24]
[/code][/QUOTE]

Of course I would also adjust mfakto to support any new results syntax, if George agrees too. I'm favoring the second option (flag the incomplete bit level in some way) as with Stages=0 you do not necessarily have adjacent bit levels (and low levels can be combined anyway). Then, the "65*" would have some added value.

So if you assign a job from 69 to 71, and the log2(factor)<70, do you report 70* or 71*? The former would make more sense, I think.

[QUOTE=Dubslow;272953]So if you assign a job from 69 to 71, and the log2(factor)<70, do you report 70* or 71*? The former would make more sense, I think.[/QUOTE]Definitely, it should be reported as [TF;69;70*;version]
It doesn't matter how far you were planning on going. We know that you found a factor somewhere 69<factor<70; what we don't know is whether you also finished checking between factor<70. If it's reported as [TF;69;70*;version] then you stopped as soon as you found the factor, whereas [TF;69;70;version] says that you found the factor but also finished checking the whole range.

it does not really matter, everything should be ok, as an empty filed (double semicolumns, as in case 1), or just a star and no exponent, or some exponent - like 70, 71, 94 (how much you planned, or just log2 of the factor), AND a star... the meaning would be the same: "I did not went behind of the reported factor", or "I stopped after I found this factor". The "eventual more factorization" has to be continued from the reported factor, in any case.

The most difficult part would be to make George and co. to agree with it and do the changes, as his (their) free time is also limited.

[QUOTE=apsen;272892]So, if I report lover bit levels "no factor", then get assignment for the level I have factor, and then report factor it should be assigned to TF?[/QUOTE]

That did not work my factor was again attributed to P-1. Back to rerunning factors with p95 :sad:

[QUOTE=apsen;273016]That did not work my factor was again attributed to P-1. Back to rerunning factors with p95 :sad:[/QUOTE]

No. If your results text contains both "no factor to" lines as well as "has a factor" lines, then factors should be attributed to TF.

[QUOTE=Prime95;273018]No. If your results text contains both "no factor to" lines as well as "has a factor" lines, then factors should be attributed to TF.[/QUOTE]

Well, they didn't. This is what I have submitted via manual submission:

[CODE]
M57841799 has a factor: 2692557022299923757047
found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]
[/CODE]

This is what is on the results page:

[CODE]
Manual testing 57841799 F-PM1 2011-09-30 02:21 0.0 2692557022299923757047 2.4586
[/CODE]

[QUOTE=apsen;273045]Well, they didn't. This is what I have submitted via manual submission:

[CODE]
M57841799 has a factor: 2692557022299923757047
found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]
[/CODE]
[/QUOTE]

Where are the "no factor to" lines?

[QUOTE=Prime95;273057]Where are the "no factor to" lines?[/QUOTE]

I have reported them separately before reporting this bitlevel. Then requested this bitlevel via prime95 and once primenet has assigned an id to it reported the level with factors.

[QUOTE=apsen;273072]I have reported them separately before reporting this bitlevel.[/QUOTE]

That is precisely why you're having trouble. If you submit the "no factor" and "has a factor" together you shouldn't have a problem

[QUOTE=Prime95;273074]That is precisely why you're having trouble. If you submit the "no factor" and "has a factor" together you shouldn't have a problem[/QUOTE]

Does that statement refer only to results reported via mfaktc? Whenever
I report factoring results in the 4M range, found factors always get
credited as F-ECM. A recent example is included below:

[QUOTE]Manual testing 4866401 F-ECM 2011-09-28 19:26 25.7 5425377273887660009 0.2093
Manual testing 4861057 F-ECM 2011-09-28 19:26 25.7 4888029476860013833 0.2093
Manual testing 4858079 F-ECM 2011-09-28 19:26 25.7 7431465676047557503 0.2092
Manual testing 4857739 F-ECM 2011-09-28 19:26 25.7 4637942603388354863 0.2092
Manual testing 4867433 NF 2011-09-28 19:26 25.7 no factor from 2^1 to 2^63 0.3278
Manual testing 4867337 NF 2011-09-28 19:26 25.7 no factor from 2^1 to 2^63 0.3278
Manual testing 4867307 NF 2011-09-28 19:26 25.7 no factor from 2^1 to 2^63 0.3278
Manual testing 4867301 NF 2011-09-28 19:26 25.7 no factor from 2^1 to 2^63 0.3278
Manual testing 4867297 NF 2011-09-28 19:26 25.7 no factor from 2^1 to 2^63 0.3278[/QUOTE]

And the factors and the upper bounds are reported in the same upload.

Gareth

[QUOTE=Prime95;273074]That is precisely why you're having trouble. If you submit the "no factor" and "has a factor" together you shouldn't have a problem[/QUOTE]George: would you mind weighing in with your opinion on the various proposals to rewrite the "has a factor" lines to include additional info (such as my "[TF;69;70*;versionstring]" proposal above). It's not so important to be included in Prime95 itself (although it would be wonderful for consistency), but it's the manual results form that needs to be modified to recognize and use the additional info. The authors of mfaktc et al seem amenable to the idea, we just need your approval of a standard format, which would eliminate any ambiguity surrounding the source of the factor.

[QUOTE=Graff;273077]Does that statement refer only to results reported via mfaktc? [/QUOTE]

Yes, and mfakto too.

[QUOTE=James Heinrich;273083]George: would you mind weighing in with your opinion on the various proposals to rewrite the "has a factor" lines to include additional info (such as my "[TF;69;70*;versionstring]" proposal above).[/QUOTE]

I'm likely to ignore anything other than mfaktc and mfakto in the additional info. Parsing complicated strings in PHP isn't much fun and development time is lacking.

When you find a factor you get CPU credit from the last "no factor to" bit level up to the found factor.

[QUOTE=Prime95;273085]I'm likely to ignore anything other than mfaktc and mfakto in the additional info. Parsing complicated strings in PHP isn't much fun and development time is lacking.[/QUOTE]I happily volunteer my time and PHP expertise to the effort. My own site already parses any and all data from results.txt, so I'm quite familiar with the issues involved.

Incidentally, I also volunteer my services to help [url=http://www.mersenneforum.org/showthread.php?t=16088]rework the reports[/url].

Please let me know what I can do to help in any way; PHP programming is what I've been doing for the last 11 years. :smile:

[QUOTE=James Heinrich;273098]I happily volunteer my time and PHP expertise to the effort. My own site already parses any and all data from results.txt, so I'm quite familiar with the issues involved.[/QUOTE]
Just as an aside, the calculations in your worktodo balancer for seem off. See attached:

James Heinrich, Oliver, All:
When i was looking at this, I liked the idea of having mfkatc simply report precisely, thus:
M42717929 has at least one factor from 2^72 to 2^73
or
M42717929 has exactly one factor from 2^72 to 2^73
depending on whether the bit level was completed or not.
(note: these numbers are made up...If they are true, then lightning has struck and M48 was found last week, too!)

Actually, log2(factor)~=73.23 . Lightning struck the tree standing next to you, which was thankfully taller than you. (But we still haven't found M48.)

[url]http://www.mersenne.org/report_exponent/?exp_lo=42717929[/url]
[url]http://www.wolframalpha.com/input/?i=log%20base%202%20of%2011046426157305102669263&t=crmtb01[/url]

(Based on bit length and factors of q-1, I'd say it was found in P-1 stage 2.)

[QUOTE=Dubslow;273130](Based on bit length and factors of q-1, I'd say it was found in P-1 stage 2.)[/QUOTE]Could be either P-1 or TF, but P-1 is more likely. If you knew the correct P-1 bounds, however, it would be 27x [i]less[/i] effort to find it via P-1 than TF (from zero). The factor would be found with default P-1 bounds.
[url]http://mersenne-aries.sili.net/exponent.php?exponentdetails=42717929[/url]

[QUOTE=Uncwilly;273107]Just as an aside, the calculations in your worktodo balancer for seem off.[/QUOTE]

Use the source, Luke:

[code]
[COLOR=#000000][COLOR=#007700]if ([/COLOR][COLOR=#0000BB]preg_match[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'#^Factor=(|N/A,|[A-F0-9]{32},)([0-9]{4,10}),([0-9]{1,2}),([0-9]{2})$#i'[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$line[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$matches[/COLOR][COLOR=#007700])) {
@list([/COLOR][COLOR=#0000BB]$all[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$aid[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$exponent[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$tf1[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$tf2[/COLOR][COLOR=#007700]) = [/COLOR][COLOR=#0000BB]$matches[/COLOR][COLOR=#007700];
[/COLOR][COLOR=#0000BB]$key [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#0000BB]count[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000BB]$GoodAssignmentsLine[/COLOR][COLOR=#007700]);
[/COLOR][COLOR=#0000BB]$GoodAssignmentsLine[/COLOR][COLOR=#007700][[/COLOR][COLOR=#0000BB]$key[/COLOR][COLOR=#007700]] = [/COLOR][COLOR=#0000BB]$line[/COLOR][COLOR=#007700];
[/COLOR][COLOR=#0000BB]$GoodAssignmentsWork[/COLOR][COLOR=#007700][[/COLOR][COLOR=#0000BB]$key[/COLOR][COLOR=#007700]] = (([/COLOR][COLOR=#0000BB]$_REQUEST[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'easyis'[/COLOR][COLOR=#007700]] == [/COLOR][COLOR=#DD0000]'small'[/COLOR][COLOR=#007700]) ? [/COLOR][COLOR=#0000BB]$exponent [/COLOR][COLOR=#007700]: [/COLOR][COLOR=#0000BB]CalcGHzDaysTrialFactor[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000BB]$exponent[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$tf1[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$tf2[/COLOR][COLOR=#007700]));
}[/COLOR][/COLOR]
[/code]It adds up the exponents. (And then it gets the hose again.)

[QUOTE=ckdo;273156]It adds up the exponents.[/QUOTE]That's what I get for adding features later on and not checking for side effects :redface: I've fixed it now.
(The original incarnation of the balancer did not have a variable definition of "easy", it was just the GHz-days effort, so adding it up made perfect sense.)

[QUOTE=James Heinrich;273098]I happily volunteer my time and PHP expertise to the effort. My own site already parses any and all data from results.txt, so I'm quite familiar with the issues involved.

Incidentally, I also volunteer my services to help [url=http://www.mersenneforum.org/showthread.php?t=16088]rework the reports[/url].

Please let me know what I can do to help in any way; PHP programming is what I've been doing for the last 11 years. :smile:[/QUOTE]

I support the suggestion that James is enabled to help you (George) and Scott with additional development work.

I would also be willing to donate my time to assist James (but without access). While I don't do PHP (except when I have to; and only then under protest -- I'm a Perl guy) I do do Regular Expressions (RegEx) and SQL for a living.

[QUOTE=chalsall;273177]I support the suggestion that James is enabled to help you (George) and Scott with additional development work.[/QUOTE]

James and I are working on the details.

[QUOTE=Prime95;273074]That is precisely why you're having trouble. If you submit the "no factor" and "has a factor" together you shouldn't have a problem[/QUOTE]

What if there're no "no factor lines".

BTW I started doing this after my regular submission were assigned to P-1. From my results page they seem to be at the lowest bit level of an assignment.

What if while reporting "has a factor" result at the lowest bit level of an assignment I swap the lines in manual submission like this:

[CODE]
found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]
M57841799 has a factor: 2692557022299923757047
[/CODE]

Would that work?

If not what would happen if I add false "no factor" line for previously completed bit levels in front. Like:

[CODE]
no factor for M57841799 from 2^70 to 2^71 [mfaktc 0.17-Win apsen 71bit_mul24]
M57841799 has a factor: 2692557022299923757047
found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]
[/CODE]

This is why I like the idea that each line is a complete, true, and accurate statement, thus:
[code]
M57841799 has a factor: 265255702299923757047 [mfaktc 0.18-Win Christenson]
found exactly 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.18-Win Christenson]
found at least 1 factor for M57841799 from 2^71 to 2^72 [mfaktc 0.18-Win Christenson]
[/code]
This way we know if you completed the bit level, what you found, and how you found it, no scrambling of lines from results.txt.