[QUOTE][B]From Dubslow[/B]: I'm running this from a shortcut. Edit: Just tried 'start /b /low /affinity 0x08 mfaktc-win-64.exe', but it again said 'Target not found'. Unfortunate. [/QUOTE][CODE]c:
cd "\Program Files\mfaktc\"
cmd.exe /c "start "mfaktc 1 DCTF" /low /affinity C mfaktc-win-64.exe -v 1"
cd "\Program Files\mfaktc - 2\"
cmd.exe /c "start "mfaktc 2 LLTF" /low /affinity 30 mfaktc-win-64.exe -v 1"
cd "\Program Files\mfaktc - 3\"
cmd.exe /c "start "mfaktc 3 LLTF 74" /low /affinity C0 mfaktc-win-64.exe -v 1"
[/CODE]I have the above in TF.bat. It even works from startup. No error checking and I'm using hex for the affinity.

It gives me three windows with the title of what each is for. Maybe it will give you a starting point.

My problem is I'm trying not to use a batch file, just a shortcut. kladner, it was starting in the correct directory, I checked that when I set it up.

OK, seems I misunderstood.

I made a shortcut by right clicking on mfaktc-win-64.exe and picking sendto desktop (shortcut).

Then I right clicked on the shortcut and picked properties.

Target box had: [CODE]"C:\Program Files\mfaktc\mfaktc-win-64.exe"[/CODE]The options were the added: [CODE]"/low /affinity C mfaktc-win-64.exe -v 1"[/CODE]The Target box now has: [CODE]"C:\Program Files\mfaktc\mfaktc-win-64.exe" "/low /affinity C mfaktc-win-64.exe -v 1"[/CODE]Note that quotes pairs are needed for the program .exe. Quote pairs for the program command line options seem to be optional.

Double click on the shortcut and the programs starts.

If I'm bugging you or really misunderstand, just say so, I will stop.

I run 2 instances of mfaktc, in C:\Prime95\mfaktc\1\ and C:\Prime95\mfaktc\2\
I put this simple batch file in C:\Prime95\mfaktc\mfaktc.bat[code]cd \Prime95\mfaktc\1
start "mfaktc 1" /min /low /affinity 0x01 mfaktc-win-64.exe

cd \Prime95\mfaktc\2
start "mfaktc 2" /min /low /affinity 0x04 mfaktc-win-64.exe[/code]Any shortcut I want simply points to the batch file.

[QUOTE=Dubslow;283482]My problem is I'm trying not to use a batch file, just a shortcut. kladner, it was starting in the correct directory, I checked that when I set it up.[/QUOTE]

OK. Just asking. I'll have to mess around with shortcuts. I'm only speaking in generalities.

[QUOTE=oswald;283490]OK, seems I misunderstood.

I made a shortcut by right clicking on mfaktc-win-64.exe and picking sendto desktop (shortcut).

Then I right clicked on the shortcut and picked properties.

Target box had: [CODE]"C:\Program Files\mfaktc\mfaktc-win-64.exe"[/CODE]The options were the added: [CODE]"/low /affinity C mfaktc-win-64.exe -v 1"[/CODE]The Target box now has: [CODE]"C:\Program Files\mfaktc\mfaktc-win-64.exe" "/low /affinity C mfaktc-win-64.exe -v 1"[/CODE]Note that quotes pairs are needed for the program .exe. Quote pairs for the program command line options seem to be optional.

Double click on the shortcut and the programs starts.

If I'm bugging you or really misunderstand, just say so, I will stop.[/QUOTE]
Thanks for the suggestion. I tried it though and got the same behavior as before, i.e. ^C is sent to cmd.exe, and not to mfaktc-win-64.exe .
[QUOTE=James Heinrich;283494]I run 2 instances of mfaktc, in C:\Prime95\mfaktc\1\ and C:\Prime95\mfaktc\2\
I put this simple batch file in C:\Prime95\mfaktc\mfaktc.bat[code]cd \Prime95\mfaktc\1
start "mfaktc 1" /min /low /affinity 0x01 mfaktc-win-64.exe

cd \Prime95\mfaktc\2
start "mfaktc 2" /min /low /affinity 0x04 mfaktc-win-64.exe[/code]Any shortcut I want simply points to the batch file.[/QUOTE]
Right click on the executable and click "Create shortcut". Of course, I'm only running one instance, so you'd need one for each instance if you didn't want to use the batch file.

I set up two shortcuts. On the left, it sets the directory in Start in: and runs the same command line I use in my batch files. An example is in the text above. Unfortunately, in the captured view of the properties box, the entire line is not visible. It is, however, the same as the last line in the batch file. This works exactly the same as the batch. It sets priority and affinity, but Ctl-C goes to CMD, not mfaktc.

The shortcut on the right also sets the directory, but it simply runs mfaktc. This launches mfaktc, and Ctl-C goes to the program. However, affinity and priority are not set and so default to all cores and normal priority.

I haven't yet tried the approach suggested by James Heinrich, using "Start" by itself without a "cmd.exe" preface.

EDIT: The following command line is not accepted by the shortcut Properties dialog:
[CODE]start "mfaktc_c" /b /low /affinity 0x20 mfaktc-win-64.exe[/CODE]It says "The name 'Start' specified in the target box is not valid."

However, using "Start" by itself in a batch file runs mfaktc. Affinity and Priority are set, and Ctl-C goes to mfaktc.

I am kind of confused by this. I didn't think there was much difference between a Shortcut command line, and one in a batch file.

EDIT2: I suppose that using Start in a batch file has implicitly invoked CMD to run the batch.

Something odd is happening when I run mfakct 0.18 on my GT 555M. After a short while, the GPU usage drops from 100% to +- 70-80%, and a little later, it goes back again to 100% for a short time, before it drops again, ad infinitum. Mfakct 0.17 always runs at 100% GPU usage on this card.

I've noticed mine doing similar things. I don't have a graph, but the avg. rate seems to drop ~10% for around 30-60 seconds, before going back to full throttle for usually at least 90+, often 120-180+ seconds, before it drops 10% again.

Note: BigBrother, your CPU wait times are sky high. They should be around 2-5% -- try increasing SievePrimes. (Your card does seem to be among the slower ones, but you should still be able to get a decent throughput increase with an increase in SievePrimes.)

When these fluctuations happen to me, around 80% of them CPU wait stays the same, in the low 2.xx% range. On the other 20% though it spikes to 10% or 20% -- but like I said, not all the time. Rather weird.

@kladner: 'start' is not its own executable, which is (AFAIK) what shortcuts can recognize. cmd.exe is (obviously) its own executable.

[QUOTE=Dubslow;283578]Note: BigBrother, your CPU wait times are sky high. They should be around 2-5% -- try increasing SievePrimes. (Your card does seem to be among the slower ones, but you should still be able to get a decent throughput increase with an increase in SievePrimes.)[/QUOTE]

I know, I set SievePrimesAdjust=0 and SievePrimes=5000 for this test.

Oh. My apologies.

[QUOTE=BigBrother;283560]Something odd is happening when I run mfakct 0.18 on my GT 555M. After a short while, the GPU usage drops from 100% to +- 70-80%, and a little later, it goes back again to 100% for a short time, before it drops again, ad infinitum. Mfakct 0.17 always runs at 100% GPU usage on this card.[/QUOTE]

I was having a similiar problem on my 560Ti, one of the 2 instances of mfaktc I had running would 'pause' and the gpu would drop from 100 to 60 or so %. I ended up opening a ticket with nVidia support, and they had me install their new beta driver and the problem went away. I thought I was having heat related issues since it was running the GPU at around 88C, but they said it can run up to 99C without problems.

[QUOTE=bcp19;283602]I was having a similiar problem on my 560Ti, one of the 2 instances of mfaktc I had running would 'pause' and the gpu would drop from 100 to 60 or so %. I ended up opening a ticket with nVidia support, and they had me install their new beta driver and the problem went away. I thought I was having heat related issues since it was running the GPU at around 88C, but they said it can run up to 99C without problems.[/QUOTE]

I'm pretty sure this problem is not heat related, at least not on my card. I'll try installing some new drivers tonight, what version are you using now?

[QUOTE=BigBrother;283633]I'm pretty sure this problem is not heat related, at least not on my card. I'll try installing some new drivers tonight, what version are you using now?[/QUOTE]

GeForce 290.53 beta for desktop GPUs

[QUOTE=bcp19;283659]GeForce 290.53 beta for desktop GPUs[/QUOTE]

I installed 290.53 beta for laptop, still the same problem with mfaktc 0.18, I'll stick with mfaktc 0.17 for now.

[QUOTE=BigBrother;283560]Something odd is happening when I run mfakct 0.18 on my GT 555M. After a short while, the GPU usage drops from 100% to +- 70-80%, and a little later, it goes back again to 100% for a short time, before it drops again, ad infinitum. Mfakct 0.17 always runs at 100% GPU usage on this card.[/QUOTE]

Do you have AllowSleep enabled?

Oliver

[url]http://gpuz.techpowerup.com/11/12/28/csv.png[/url]

I do not have AllowSleep enabled. I was doing literally the exact same thing for all the time shown in the shot, but for whatever reason load dropped down to 80% from 92%, and avg. rate dropped from ~185 to 170's and 160's, and for one class even down to 130's before going back up to 180. CPU wait remained more or less constant. (The portions with reduced load are the ones that are flat, as opposed to bumpy. I do wish the graph was taller.)

[QUOTE=Dubslow;283859][URL]http://gpuz.techpowerup.com/11/12/28/csv.png[/URL]

I do not have AllowSleep enabled. I was doing literally the exact same thing for all the time shown in the shot, but for whatever reason load dropped down to 80% from 92%, and avg. rate dropped from ~185 to 170's and 160's, and for one class even down to 130's before going back up to 180. CPU wait remained more or less constant. (The portions with reduced load are the ones that are flat, as opposed to bumpy. I do wish the graph was taller.)[/QUOTE]

I do have AllowSleep=1. Most of the time the GPU runs at 95-98%. I do see variations in throughput, but lots of times it has to do with other things going on in the system which is taking over more CPU time and starving mfaktc. For example, anything involving Adobe apps almost always eats a chunk of performance. This shows up as big dips in GPU utilization. Norton and its like can certainly do the same. Are you sure what else is going on in your machine?

[QUOTE=TheJudger;283844]Do you have AllowSleep enabled?

Oliver[/QUOTE]

I did. I disabled it and now it seems to run without performance dips. I'll try to check it out further tonight.

Hi,

[QUOTE=BigBrother;283925]I did. I disabled it and now it seems to run without performance dips. I'll try to check it out further tonight.[/QUOTE]

just for curiosity, can you run 'mfaktc --sleeptest' on your system and post the result? Thank you!

Oliver

[QUOTE=kladner;283903]I do have AllowSleep=1. Most of the time the GPU runs at 95-98%. I do see variations in throughput, but lots of times it has to do with other things going on in the system which is taking over more CPU time and starving mfaktc. For example, anything involving Adobe apps almost always eats a chunk of performance. This shows up as big dips in GPU utilization. Norton and its like can certainly do the same. Are you sure what else is going on in your machine?[/QUOTE]
For me, I just sat and watched the computer that whole time, so only something in the background could have done it. If the process list in the Task Manager is anything to go by, the only thing I could think of would be Steam doing something, but like I said, nothing appeared on screen. The only thing changing were the GPU-Z window and the mfaktc window.

[QUOTE=TheJudger;283928]Hi,



just for curiosity, can you run 'mfaktc --sleeptest' on your system and post the result? Thank you!

Oliver[/QUOTE]

[CODE]my_usleep( 1000): t_min = 492us, t_max = 1083us, t_avg = 999us
my_usleep( 2000): t_min = 1668us, t_max = 2057us, t_avg = 1999us
my_usleep( 4000): t_min = 3631us, t_max = 4070us, t_avg = 3998us
my_usleep( 8000): t_min = 7700us, t_max = 8112us, t_avg = 7997us
my_usleep( 16000): t_min = 15727us, t_max = 16116us, t_avg = 15996us
my_usleep( 32000): t_min = 31617us, t_max = 32033us, t_avg = 31989us
my_usleep( 64000): t_min = 63661us, t_max = 64070us, t_avg = 63985us
my_usleep(128000): t_min = 127679us, t_max = 128055us, t_avg = 127955us[/CODE]

[QUOTE=BigBrother;283973][CODE]my_usleep( 1000): t_min = 492us, t_max = 1083us, t_avg = 999us
my_usleep( 2000): t_min = 1668us, t_max = 2057us, t_avg = 1999us
my_usleep( 4000): t_min = 3631us, t_max = 4070us, t_avg = 3998us
my_usleep( 8000): t_min = 7700us, t_max = 8112us, t_avg = 7997us
my_usleep( 16000): t_min = 15727us, t_max = 16116us, t_avg = 15996us
my_usleep( 32000): t_min = 31617us, t_max = 32033us, t_avg = 31989us
my_usleep( 64000): t_min = 63661us, t_max = 64070us, t_avg = 63985us
my_usleep(128000): t_min = 127679us, t_max = 128055us, t_avg = 127955us[/CODE][/QUOTE]

close to perfect results, this can't be the root issue. I've noticed that some systems have a not so good accuracy, e.g. my own Windows box has a bad sleep accuracy:[CODE]my_usleep( 1000): t_min = 4699us, t_max = 15736us, t_avg = 15612us
my_usleep( 2000): t_min = 15552us, t_max = 15649us, t_avg = 15623us
my_usleep( 4000): t_min = 15564us, t_max = 15645us, t_avg = 15623us
my_usleep( 8000): t_min = 15571us, t_max = 15648us, t_avg = 15622us
my_usleep( 16000): t_min = 31197us, t_max = 31257us, t_avg = 31247us
my_usleep( 32000): t_min = 46819us, t_max = 46879us, t_avg = 46872us
my_usleep( 64000): t_min = 78075us, t_max = 78129us, t_avg = 78120us
my_usleep(128000): t_min = 140576us, t_max = 140627us, t_avg = 140618us[/CODE]
This box has three OSes installed: Windows XP SP3, Windows 7 professional 64bit, openSUSE 11.1 64bit. Both Windows installations have a bad accuracy while under Linux I get close to perfect sleep results. So I guess this is a software issue, not an hardware issues. I've observed multiples of 15.6ms asweel as 7.8ms and 3.9ms for different Windows installations on different machines.

Oliver

I'm having weird an unusual slowdowns as well with version 0.18.

Seems to be across all my machines.

Only affects when multiple instances run on same video card.

As an example, when I start both instances the first reported times per class are 17.796s & 11.830s, after a couple of classes it increases to 20.059s & 13.568s where it stays. M48121669 71-73, and M47551541 72-73. Initial run has CPU wait <5% and increases to over 20%.

Machine is 2600k@4.5GHz with GTX580.

The initial times seem more in line with version 0.17.

I tried mucking around with sieve primes, grid size, cpu streams, num streams and no luck.

Any ideas?

-- Craig

Aaah scratch that.

I put a faster fan in front of the case dropped the GPU further a few degrees and it stays constant.

I thought I ruled at GPU thermal throttling as the GPU% didn't drop. Oh well.

-- Craig

[QUOTE=TheJudger;283986]close to perfect results, this can't be the root issue. I've noticed that some systems have a not so good accuracy, e.g. my own Windows box has a bad sleep accuracy:[CODE]my_usleep( 1000): t_min = 4699us, t_max = 15736us, t_avg = 15612us
my_usleep( 2000): t_min = 15552us, t_max = 15649us, t_avg = 15623us
my_usleep( 4000): t_min = 15564us, t_max = 15645us, t_avg = 15623us
my_usleep( 8000): t_min = 15571us, t_max = 15648us, t_avg = 15622us
my_usleep( 16000): t_min = 31197us, t_max = 31257us, t_avg = 31247us
my_usleep( 32000): t_min = 46819us, t_max = 46879us, t_avg = 46872us
my_usleep( 64000): t_min = 78075us, t_max = 78129us, t_avg = 78120us
my_usleep(128000): t_min = 140576us, t_max = 140627us, t_avg = 140618us[/CODE]
This box has three OSes installed: Windows XP SP3, Windows 7 professional 64bit, openSUSE 11.1 64bit. Both Windows installations have a bad accuracy while under Linux I get close to perfect sleep results. So I guess this is a software issue, not an hardware issues. I've observed multiples of 15.6ms asweel as 7.8ms and 3.9ms for different Windows installations on different machines.

Oliver[/QUOTE]

Here are two other results:
[CODE]my_usleep( 1000): t_min = 927us, t_max = 15734us, t_avg = 14110us
my_usleep( 2000): t_min = 1748us, t_max = 15776us, t_avg = 13341us
my_usleep( 4000): t_min = 15308us, t_max = 15722us, t_avg = 15597us
my_usleep( 8000): t_min = 10336us, t_max = 20743us, t_avg = 15595us
my_usleep( 16000): t_min = 15911us, t_max = 31302us, t_avg = 25924us
my_usleep( 32000): t_min = 31827us, t_max = 46911us, t_avg = 43794us
my_usleep( 64000): t_min = 77618us, t_max = 78120us, t_avg = 77972us
my_usleep(128000): t_min = 140214us, t_max = 140414us, t_avg = 140367us

my_usleep( 1000): t_min = 861us, t_max = 15852us, t_avg = 11617us
my_usleep( 2000): t_min = 1889us, t_max = 16597us, t_avg = 8094us
my_usleep( 4000): t_min = 15170us, t_max = 15762us, t_avg = 15597us
my_usleep( 8000): t_min = 7921us, t_max = 18629us, t_avg = 13621us
my_usleep( 16000): t_min = 15933us, t_max = 31917us, t_avg = 28255us
my_usleep( 32000): t_min = 31753us, t_max = 46860us, t_avg = 41721us
my_usleep( 64000): t_min = 77831us, t_max = 78041us, t_avg = 77993us
my_usleep(128000): t_min = 127993us, t_max = 140137us, t_avg = 129739us[/CODE]

By the way, AllowSleep=0 didn't fix my problem.

What was the old format for a found factor? I want to manually edit them until PrimeNet is updated.

[QUOTE=Dubslow;284143]What was the old format for a found factor? I want to manually edit them until PrimeNet is updated.[/QUOTE]Makes no difference. Primenet doesn't look at that part of the result line in detail.

But it was like this:[quote]M148989163 has a factor: 92743592786721447289
found 1 factor(s) for M148989163 from 2^64 to 2^68 (partially tested) [mfaktc 0.13-Win 71bit_mul24][/quote]

Thanks. I just wanted to make sure it wasn't recorded as P-1.

[QUOTE=Dubslow;284145]Thanks. I just wanted to make sure it wasn't recorded as P-1.[/QUOTE]That's a server-side issue that is as-yet unaddressed. Doesn't matter what format you submit for manual results, Primenet will (currently) ignore the differences and process it however it sees fit. Which is usually right, but not always.

[QUOTE=James Heinrich;284146]That's a server-side issue that is as-yet unaddressed. Doesn't matter what format you submit for manual results, Primenet will (currently) ignore the differences and process it however it sees fit. Which is usually right, but not always.[/QUOTE]

As for the GHz days, it's wrong, but it's not that big of a deal. However, it messes up the statistical results on your website which i think are really important for historical purposes. Do you think the data will get fixed in the future or is it permanent? I have kept an archive of all my results files, maybe one day they can be used to fix the data in PrimeNet?

Edit: I was just reading [URL="http://www.mersenneforum.org/showpost.php?p=284184&postcount=1035"]here[/URL] that you have to upload results to James' site. I did not know it was separtate. I'll have to spend some time uploading my files.

I still wonder if it's possible to ever fix PrimeNet's data for all out GPU TFs that show as P-1?

[QUOTE=flashjh;284188]However, it messes up the statistical results on your website which i think are really important for historical purposes. Do you think the data will get fixed in the future or is it permanent? I have kept an archive of all my results files, maybe one day they can be used to fix the data in PrimeNet?[/quote]Any data that is uploaded directly to [url=http://mersenne-aries.sili.net/]my site[/url] should be accurately credited for both work type and GHz-days. If it's not, let me know.

Primenet's interpretation of manual results remains an issue for now, but one that I can hopefully help address within the next few weeks/months. Where that affects my data is when I spider new results from PrimeNet; if these are mis-reported then I will import bad data. If you also upload your real results.txt data to my site then it's much easier to find invalid TF-PM1 confused results and potentially fix them.

[quote]I still wonder if it's possible to ever fix PrimeNet's data for all out GPU TFs that show as P-1?[/QUOTE]Unfortunately I'm not convinced that Primenet retains detailed logs for factoring assignments (just increments factor-type counter for the user, and records the factor for the exponent). But it still should be possible to later go through the data and look for improbable P-1s (where it would be hard to find said factor with P-1, but relatively easy with TF). But I need to fix Primenet's poor interpretation of manual results first.

[quote]I'll have to spend some time uploading my files.[/quote]Shouldn't take that long to upload. Bundle up all your results into one or two files and upload away. Results files with PrimeNet-style user/computer IDs at the beginning of the line are automatically handled correctly; for mfakt* results which have no user/computer data you should specify your username and "computer" ID in the appropriate boxes. If you work with multiple GPUs, upload data for one GPU at a time to avoid confusion. Other than that there's no real limit on upload size (my server parses results [i]much[/i] faster than primenet :smile:).

Feature request for [i]TheJudger[/i] / [i]Bdot[/i]:
Can you put two optional fields in mfaktc.ini for username and computerid, so that if the user fills them out then it puts the Primenet-style "UID: username/computername, " at the beginning of results lines? Makes parsing results much easier and less subject to confusion.

I have quite a few TF and TF DC results that were reported to PrimeNet but they are still showing up in my assignments page on GPU to 72. It's been over 4 hours since the report to PrimeNet. Will they eventually get detected or is something wrong?

Uploading results
 

I have gotten all my Windows Prime95-64bit and mfaktc results submitted. EDIT: To [URL]http://mersenne-aries.sili.net[/URL]

I'm not sure how to submit results from a defunct 32bit Prime95 setup.

Then there's a headless Linux box. I'm still really inept in this area, in that I don't know any easy way to copy that results.txt to Windows for submission. I attempted to extract the results from the PrimeNet Results page, but that is not correctly formatted and so was not recognized.

I'm accessing the Linux system via putty. Any guidance in getting those results would be appreciated.

EDIT2: Perhaps this query would have been better off posted here: [url]http://www.mersenneforum.org/showthread.php?t=11101&page=42[/url]
but at this point I'll leave well enough alone.

[QUOTE=kladner;284252]Then there's a headless Linux box. I'm still really inept in this area, in that I don't know any easy way to copy that results.txt to Windows for submission.

I'm accessing the Linux system via putty. Any guidance in getting those results would be appreciated.[/QUOTE]
It's possible something like scp might work. I don't know exactly how to use it, but it should get you started. 'man scp'

[QUOTE=flashjh;284238]I have quite a few TF and TF DC results that were reported to PrimeNet but they are still showing up in my assignments page on GPU to 72. It's been over 4 hours since the report to PrimeNet. Will they eventually get detected or is something wrong?[/QUOTE]Put this in the GPU272 forum, in the 'Assignments discrepancy' thread.

[QUOTE=Dubslow;284265]It's possible something like scp might work. I don't know exactly how to use it, but it should get you started. 'man scp'

[/QUOTE]

Thanks, Dubslow. I'll have a look. Just having a name is a big step forward.

[QUOTE=flashjh;284238]I have quite a few TF and TF DC results that were reported to PrimeNet but they are still showing up in my assignments page on GPU to 72. It's been over 4 hours since the report to PrimeNet. Will they eventually get detected or is something wrong?[/QUOTE]

Sorry...

I had turned off the Observation spider while I drilled down on the assignment dependency problem. I figured out what was going on at about 0500 my time, but was so tired I forgot to turn it back on...

I'll have a full report over in the G72 sub-forum in a few hours (or maybe tomorrow -- it is Old Years Night, after all... :smile:).

[QUOTE=James Heinrich;284229]Feature request for [I]TheJudger[/I] / [I]Bdot[/I]:
Can you put two optional fields in mfaktc.ini for username and computerid, so that if the user fills them out then it puts the Primenet-style "UID: username/computername, " at the beginning of results lines? Makes parsing results much easier and less subject to confusion.[/QUOTE]
I've added it to my list ...

[QUOTE=James Heinrich;284229]Feature request for [i]TheJudger[/i] / [i]Bdot[/i]:
Can you put two optional fields in mfaktc.ini for username and computerid, so that if the user fills them out then it puts the Primenet-style "UID: username/computername, " at the beginning of results lines? Makes parsing results much easier and less subject to confusion.[/QUOTE]Second similar feature request:
Can you please also add a .ini option to output datestamp lines in results.txt, the same way Prime95 does? e.g.:[quote][color=green][b][Sat Dec 31 21:29:40 2011][/b][/color]
no factor for M50370833 from 2^70 to 2^71 [mfaktc 0.18 barrett79_mul32][/quote]

[QUOTE=James Heinrich;284229]Feature request for [i]TheJudger[/i] / [i]Bdot[/i]:
Can you put two optional fields in mfaktc.ini for username and computerid, so that if the user fills them out then it puts the Primenet-style "UID: username/computername, " at the beginning of results lines? Makes parsing results much easier and less subject to confusion.[/QUOTE]

Shouldn't be a problem. We'll need those two entries in mfaktc.ini for automated primenet interaction, too.

[QUOTE=James Heinrich;284360]Second similar feature request:
Can you please also add a .ini option to output datestamp lines in results.txt, the same way Prime95 does? e.g.:[/QUOTE]

Do we need this as an option or should we enable this allways?

Oliver

[QUOTE=TheJudger;284375]Do we need this as an option or should we enable this allways?[/QUOTE]My preference would be that it's always there.

Feature request...
 

Since we're asking for new features / abilities...

It would be nice (if it's not already there) to have a function like Prime95's worktodo.add feature. This would allow for automated reservation and processing of work from PrimeNet and/or G72 by way of another spider until Christenson has completed his integrated functionality.

I understand from another thread that the mfakt* programs allow for editing live worktodo.txt files (except for the first line), but I personally would prefer not to have a 'bot touch it.

Isn't GPU trial factoring unfair for GHzday-statistics?
I'm running it on my GTX 570M, for less than a month; and I already have doubled my GHz-days.

It's also the reason I shut down my old desktop. (Which only did TF.)
If that desktop needs 3 days to TF to 2^69, where the GPU does up to 2^72 in 12h for the same exponent, I don't see the point in wasting more electricity on an old PC. (Never mind the "you might be addicted to GIMPS if..." thread.)

[QUOTE=sonjohan;284523]Isn't GPU trial factoring unfair for GHzday-statistics?
It's also the reason I shut down my old desktop. (Which only did TF.)
If that desktop needs 3 days to TF to 2^69, where the GPU does up to 2^72 in 12h for the same exponent, I don't see the point in wasting more electricity on an old PC. (Never mind the "you might be addicted to GIMPS if..." thread.)[/QUOTE]

That old machine would probably still make a fine contribution doing DC or P-1 work.

Don't knock GPU TF. Hardware advances will always seem unfair to the practitioners of previous technology. If there were similar comparisons available, I'm sure that 486's seemed unfairly fast to those with 386's.

[QUOTE=kladner;284524]That old machine would probably still make a fine contribution doing DC or P-1 work.

Don't knock GPU TF. Hardware advances will always seem unfair to the practitioners of previous technology. If there were similar comparisons available, I'm sure that 486's seemed unfairly fast to those with 386's.[/QUOTE]

Agreed! I have an older socket 478 P4 3.4GHz 2Gb system that I've had for many years now (upgraded to that slowly over the years). Civ V played ok on it, but when you get too far along it would lockup sometimes (my Son requested a better system :smile:). So, I finally upgraded and then dedicated it to P-1 and to mfakto. It has an HD 4670 AGP card that gives about 12M/s (200,000 SievePrimes) (I'm pretty sure the card would do better in a faster system). It does ~four DC TF checks 68^69 per day and each P-1 takes ~3-4 days.

All in all nothing special, but it's more than nothing.

[QUOTE=sonjohan;284523]Isn't GPU trial factoring unfair for GHzday-statistics?
[/QUOTE]
Many (including myself) have [url=http://www.mersenneforum.org/showthread.php?t=16273]made that argument[/url], however figuring out what to actually do about it is what's given us trouble. I think we've all just kind of given up on it. (The main problem is in figuring out what the 'average' CPU and GPU working for GIMPS can do.)



As for that old PC, you can do DC or P-1 as others have mentioned, or you could even do TF-LMH. That's something that still yields a factor every couple of days, even on that slow a machine, and each factor is anywhere from 500 to many thousands of GHz-Days of LL work (admittedly far off in the future, but still.) In fact, at a minimum, the chalsall (GPU to 72 creator and admin) has his old PC's doing TF-LMH (obviously he knows better than I, but that's my understanding).

[QUOTE=kladner;284524]That old machine would probably still make a fine contribution doing DC or P-1 work.

Don't knock GPU TF. Hardware advances will always seem unfair to the practitioners of previous technology. If there were similar comparisons available, I'm sure that 486's seemed unfairly fast to those with 386's.[/QUOTE]

I had an 8088 laptop and had a program running to calculate how many entries would be needed to get every possible 4 number combination in a 51 number lottery. Program ran for somewhere around 6 months. Put it on my first Pentium and it took about 12 hours.

[QUOTE=bcp19;284558]I had an 8088 laptop and had a program running to calculate how many entries would be needed to get every possible 4 number combination in a 51 number lottery. Program ran for somewhere around 6 months. Put it on my first Pentium and it took about 12 hours.[/QUOTE]
(51 * 50 * 49 * 48) / 4! to 1
Your pocket 8 digit calculator can do that one. That is a super trivial calculation.

[QUOTE=bcp19;284558]I had an 8088 laptop and had a program running to calculate how many entries would be needed to get every possible 4 number combination in a 51 number lottery. Program ran for somewhere around 6 months. Put it on my first Pentium and it took about 12 hours.[/QUOTE]

This post is good for xyzzy's top. Sure that program was not doing something else too? There are only 249900 of them, and even a 8-bit Sinclair could spit them out in a blink, or use a matrix (needle) printer to print them in less then 12 hours...

Both of you are, of course, completely wrong in case bcp19 didn't talk about a "4 out of 51" lottery in the first place. :razz:

[QUOTE=James Heinrich;284376]My preference would be that it's always there.[/QUOTE]

I'd like it as an option. I've run into cases where I have to break up results.txt when pasting it into the manual results page, presumably because it's too much data for one shot. Adding time stamps will make this happen quicker, meaning more chance for error when submitting results.

Once we get automated Primenet interaction it won't be a big deal.

[QUOTE=kjaget;284593] Once we get automated Primenet interaction it won't be a big deal.[/QUOTE]
I [B]so[/B] like the manual upload of results. I like to see the extreme jump in stats.:showoff:

Also, with automated Primenet interaction, it's impossible to force TF to 72, which I'm currently doing for all exponents I received.

[QUOTE=Dubslow;283578]<SNIP>
@kladner: 'start' is not its own executable, which is (AFAIK) what shortcuts can recognize. cmd.exe is (obviously) its own executable.[/QUOTE]

Did you ever work anything out on this front?

And a related question, why do you avoid batch files? Something similar to what James Heinrich said -start without cmd in a batch- is what I'm using now. It does all the affinity/priority stuff as before, but now passes Ctl-C to mfaktc.

Of course it's your choice, to bat or not to bat. I'm just curious as to why you don't like them.

[QUOTE=kladner;284632]Of course it's your choice, to bat or not to bat. I'm just curious as to why you don't like them.[/QUOTE]

The Riddler will only riddle The Batman.

Yes, if you are going to type it more than a couple of times, script or batch it. I must admit I'm an [B]Algorithm Junky.[/B] The beauty of it when you make it work is a joy into itself. The challenge of debug. Oops, sorry. I sound like Monty Python.

Anyway, I'd like to know the outcome as well.

I was trying to see if it was possible in the shortcut, with its greater simplicity (also, while not really relevant here, for the 'average' user, 'batch file' will put them off completely while 'shortcut' is less terrifying). Also, I only have one instance, unlike the vast majority of people here. If I get unlazy I might re-implement it.

[QUOTE=Uncwilly;284563](51 * 50 * 49 * 48) / 4! to 1
Your pocket 8 digit calculator can do that one. That is a super trivial calculation.[/QUOTE]

[QUOTE=LaurV;284573]This post is good for xyzzy's top. Sure that program was not doing something else too? There are only 249900 of them, and even a 8-bit Sinclair could spit them out in a blink, or use a matrix (needle) printer to print them in less then 12 hours...[/QUOTE]

1) Not a math major
2) you're forgetting I am not a major programmer
3) program was running in basic
4) misspoke... program was looking for the MINIMUM number of tickets it would take to get ALL possible 4 number combos; IE: 1,2,3,4,5,6 has 1,2,3,4 1,2,3,5 1,2,3,6 1,2,4,5 1,2,4,6 1,2,5,6 1,3,4,5 1,3,4,6 1,2,5,6 2,3,4,5 2,3,4,6 2,3,5,6 2,4,5,6 3,4,5,6, so that is 1 card.

6 nested for next loops 1 to 46, 2 to 47, 3 to 48, 4 to 49, 5 to 50 and 6 to 51 = 9,474,296,896 iterations of the calculation process. Don't ask me for the program, this was around 20 years ago and I am going from memory with what I have here. If I am remembering correctly, it ran through this more than once, as on the first run through it would only write to the 'array' if there were no duplicate instances; IE: 1,2,3,4-6,x,x+1 to 51 would be bypassed after 1,2,3,4,5,6 was processed, seems like it looked for all 14, then for 10/14, then 6/14 and then just spit out the remaining unchecked 'array' items as it was easier to use human calculations than continue deeper into the computer calculations.

[QUOTE=ckdo;284582]Both of you are, of course, completely wrong in case bcp19 didn't talk about a "4 out of 51" lottery in the first place. :razz:[/QUOTE]
[QUOTE=bcp19;284699]1,2,3,4,5,6 [...] is 1 card.[/QUOTE]
QED.

[QUOTE=oswald;283490]OK, seems I misunderstood.

I made a shortcut by right clicking on mfaktc-win-64.exe and picking sendto desktop (shortcut).

Then I right clicked on the shortcut and picked properties.

Target box had: [CODE]"C:\Program Files\mfaktc\mfaktc-win-64.exe"[/CODE]The options were the added: [CODE]"/low /affinity C mfaktc-win-64.exe -v 1"[/CODE]The Target box now has: [CODE]"C:\Program Files\mfaktc\mfaktc-win-64.exe" "/low /affinity C mfaktc-win-64.exe -v 1"[/CODE]Note that quotes pairs are needed for the program .exe. Quote pairs for the program command line options seem to be optional.

Double click on the shortcut and the programs starts.

If I'm bugging you or really misunderstand, just say so, I will stop.[/QUOTE]
Whatever I was doing then, it wasn't right. I just tried this again, with opposite results: ^C is passed to mfaktc. Unfortunately, the options aren't recognized and the affinity isn't set properly (not set at all).

So that still leaves me clueless.

[QUOTE=bcp19;284699]1) 1,2,3,4,5,6 .... is 1 card.[/QUOTE]

[QUOTE=ckdo;284719]QED.[/QUOTE]

They are much less in this case, and their number is easier to compute, and they are easy to "spread" (how do you call this process in English? is it "spread"? like writing down all permutations of some set, or all coefficients of some polynomial multiplication, or some sum/series formula?) with a simple algorithm if you want them printed. It will take even less time then I said initially.

Hint: you have maximum 249k of them with the trivial cover: each 1234 is covered by a 1234xy with a random x,y. From here you start cutting. As C(6,4)=15, the theoretical minimum is 16660, assuming you can cover it in a disjunctive manner. Can you?

[QUOTE=LaurV;284865]They are much less in this case, and their number is easier to compute, and they are easy to "spread" (how do you call this process in English? is it "spread"? like writing down all permutations of some set, or all coefficients of some polynomial multiplication, or some sum/series formula?) with a simple algorithm if you want them printed. It will take even less time then I said initially.

Hint: you have maximum 249k of them with the trivial cover: each 1234 is covered by a 1234xy with a random x,y. From here you start cutting. As C(6,4)=15, the theoretical minimum is 16660, assuming you can cover it in a disjunctive manner. Can you?[/QUOTE]

As mentioned before, I am not a math major, nor a major programmer. When I wrote the program I did not take into consideration the 1,2,3,4,x,y as you state, so the program ran through all 9.4 billion iterations.

EDIT: One of the other things to consider, the 8088 was a 5MHz processor and probably had at most 64MB memory, which means the program had to do it's array through disc access, which would considerable slow the process, in addition to the slowdown already caused by using basic.

[QUOTE=Dubslow;284645]I was trying to see if it was possible in the shortcut, with its greater simplicity (also, while not really relevant here, for the 'average' user, 'batch file' will put them off completely while 'shortcut' is less terrifying). Also, I only have one instance, unlike the vast majority of people here. If I get unlazy I might re-implement it.[/QUOTE]

OK. I get your point. I guess I've dealt with batches for so long it comes naturally, at least for simple things.

[QUOTE=bcp19;284920]

EDIT: One of the other things to consider, the 8088 was a 5MHz processor and probably had at most [SIZE=2][U][B]64MB[/B][/U] [/SIZE]memory, [/QUOTE]

That would be KB, right?:rolleyes:

[QUOTE=Dubslow;284721]Whatever I was doing then, it wasn't right. I just tried this again, with opposite results: ^C is passed to mfaktc. Unfortunately, the options aren't recognized and the affinity isn't set properly (not set at all).

So that still leaves me clueless.[/QUOTE]

Well, if you want to reconsider, this will do affinity and priority. You can add switches at the end of the last line, if you want them.

[CODE][your drive letter]:
cd \[your directory]\[your subdirectory if needed]
start /low /affinity 0x20 mfaktc-win-64[/CODE]

Edit: Ctl-C will go to mfaktc.

Hehe, thanks. (Though I did have to use affinity 0x80 :rolleyes:)

[QUOTE=Dubslow;284945]Hehe, thanks. (Though I did have to use affinity 0x80 :rolleyes:)[/QUOTE]

Yeah. I didn't put in [your hex value] in line 3.

[QUOTE=kladner;284936]That would be KB, right?:rolleyes:[/QUOTE]

Of course. The fingers need to pay more attention to what the brain is thinking.

[QUOTE=bcp19;284976]Of course. The fingers need to pay more attention to what the brain is thinking.[/QUOTE]

It's been so long since such numbers were pertinent. The first computer in this household had 8MB of RAM (I insisted on upping it from the 4MB on offer), and a 120MB HDD. The second machine had 256MB of RAM, or double what the first had in the HDD. The first was a 486DX 33MHz with DOS 5 and Windows 3.1. The second was a Pentium Pro, which had a few OS upgrades in its life span.

He, found another problem. It works great when I double click the file -- but if I pin the resulting icon to the taskbar and just click on that icon, it doesn't work. Pain the butt.
Edit: Making a shortcut and pinning that doesn't work either.
Double clicking the shortcut on the desktop works though.

[QUOTE=Dubslow;285018]He, found another problem. It works great when I double click the file -- but if I pin the resulting icon to the taskbar and just click on that icon, it doesn't work. Pain the butt.
Edit: Making a shortcut and pinning that doesn't work either.
Double clicking the shortcut on the desktop works though.[/QUOTE]

Hmm. Haven't tried that. I have icons on the desktop.

EDIT: But I've been lazy about consolidating the start up of the two instances I run.

I am completely new to GPU TFing and have some stats to share with you guys.

System
2600K/GTX460 stock

During TFing on the GPU it seems like the CPU is rather busy as well, which in turns use a fair bit of power, 26.8 watt in this case. Is this normal? Is there anyway to run this more effectively? The same CPU idling uses about 5-7w of power.

The GTX seems to churn out a 70-71 bit TF in about 1 hour and a 71-72 in about 2 hours which is fairly fast (i think) compared to pure CPU TFing.

[QUOTE=xtreme2k;285078]seems like the CPU is rather busy as well, which in turns use a fair bit of power, 26.8 watt in this case. Is this normal?[/QUOTE]Perfectly normal. You're using one core's worth of CPU power to keep the GPU pretty well fed. Looks good.

[QUOTE=xtreme2k;285078]I am completely new to GPU TFing and have some stats to share with you guys.

System
2600K/GTX460 stock

During TFing on the GPU it seems like the CPU is rather busy as well, which in turns use a fair bit of power, 26.8 watt in this case. Is this normal? Is there anyway to run this more effectively? The same CPU idling uses about 5-7w of power.

The GTX seems to churn out a 70-71 bit TF in about 1 hour and a 71-72 in about 2 hours which is fairly fast (i think) compared to pure CPU TFing.[/QUOTE]

Your CPU does some sieving, so that's normal. Everything from you're picture seems good. You could try running two instances to see if you get more throughput.

Thanks guys.

Great info, I will try to run 2 instances, would that be by running 2 separate ones from 2 folders?

Would you also run prime95 on 3 CPU cores (TF or other units) at the same time?

[QUOTE=flashjh;285081]Your CPU does some sieving, so that's normal. Everything from you're picture seems good. You could try running two instances to see if you get more throughput.[/QUOTE]

Doubtful. The sieveprimes is not down to 5000 which means the GPU is not outperforming the CPU. From his M/s I'd guess that he'd only see a 10-15% increase with 2 instances, which is kind of a waste of a second core.

Yes, you'd need 2 folders to run 2 instances.

[QUOTE=xtreme2k;285078]I am completely new to GPU TFing and have some stats to share with you guys.

System
2600K/GTX460 stock

During TFing on the GPU it seems like the CPU is rather busy as well, which in turns use a fair bit of power, 26.8 watt in this case. Is this normal? Is there anyway to run this more effectively? The same CPU idling uses about 5-7w of power.

The GTX seems to churn out a 70-71 bit TF in about 1 hour and a 71-72 in about 2 hours which is fairly fast (i think) compared to pure CPU TFing.[/QUOTE]

When mfaktc is running the CPU prepares data to feed to the GPU. It is normal for the CPU usage to go up. Many people here (though not all, I think) assign affinity for an instance of mfaktc to a particular core. There is considerable discussion in this thread on ways to do this when mfaktc is started. The previous page has some of this discussion.

The GPU is a lot faster than a CPU for TF. The GTX 460 is a good worker in this, though of course not the latest and greatest. My 460 does turn out lots of TF work.

EDIT: The consensus now seems to be that it is a waste of CPU time to do TF there. Fortunately, there are other tasks at which an i7 will shine, such as LL or P-1.

[QUOTE=xtreme2k;285082]Would you also run prime95 on 3 CPU cores (TF or other units) at the same time?[/QUOTE]Absolutely run Prime95 on the other 3 cores (as said above, best if affinity is locked to individual cores for both mfaktc and Prime95). But do [i]not[/i] run TF on the CPU cores, that's a waste of time (your GPU is much much faster), use your CPU for P-1 or L-L.

Thanks for all the response. I have used task manager to set the affinity for the thread for now. Its getting late for me now in Sydney so I will come back to this tomorrow!

How much quicker does a 570/580GTX TF?

[QUOTE=bcp19;285083]Doubtful. The sieveprimes is not down to 5000 which means the GPU is not outperforming the CPU. From his M/s I'd guess that he'd only see a 10-15% increase with 2 instances, which is kind of a waste of a second core.

Yes, you'd need 2 folders to run 2 instances.[/QUOTE]

You're right. I wouldn't put more than one core per instance, but I think his GPU could handle more.

[QUOTE=kladner;285084]When mfaktc is running the CPU prepares data to feed to the GPU. It is normal for the CPU usage to go up. Many people here (though not all, I think) assign affinity for an instance of mfaktc to a particular core. There is considerable discussion in this thread on ways to do this when mfaktc is started. The previous page has some of this discussion.

The GPU is a lot faster than a CPU for TF. The GTX 460 is a good worker in this, though of course not the latest and greatest. My 460 does turn out lots of TF work.

EDIT: The consensus now seems to be that it is a waste of CPU time to do TF there. Fortunately, there are other tasks at which an i7 will shine, such as LL or P-1.[/QUOTE]

This is how I run my dual GTX 580s on a Phenom 1055T:

- Five instances each running TF on one 580.
- CUDA running on the other 580
- Prime95 running 1 P-1

Instances 1 - 5 affinity set to one core, respectively.
CUDA uses core 5 also
Prime95 uses core 6

Instances 1-4 run First time TFs. Instance 5 runs DC TF.

This balance gives me SievePrimes about 10,000, wait times range from 2.3 to 16 depending on the work being done. CUDA is 9ms per iteration and Prime95 gets the leftover time not used by the OS on core 6. System get a little laggy during stage 2 P-1 using 16Gb of ram, but otherwise it all runs well.

Without settig affinity I never get a good balance and SievePrimes always bottoms out at 5000.

[QUOTE=xtreme2k;285089]Thanks for all the response. I have used task manager to set the affinity for the thread for now. Its getting late for me now in Sydney so I will come back to this tomorrow!

How much quicker does a 570/580GTX TF?[/QUOTE]

Check out James' site [URL="http://mersenne-aries.sili.net/mfaktc.php"]here[/URL]. It will give you a good idea of what performace you'd get on different GPUs.

As a matter of fact, for all those talking about whether or not he should run another instance, I have the exact same setup. A 2600K hosting a 460. They are both slightly OCd, however if his are both at stock his experience should be pretty much the same. I run it with hyper threading on, Prime95 with 3 workers running two threads per worker on cores 1-6, which correspond to physical cores 1-3 in Windows. That is, Worker 1 has one thread on 1 and one thread on 2, Worker 2 has one thread on 3 and one thread on 4, etc. I pin mfaktc to core 8 (I've found little difference between running it on just one of the pair or both of the pair of logical cores) with SievePrimes=5000 (and AutoAdjust=0) and get, depending on frequencies, 80-95% load, (sometimes up to 100%) which for me, the gain from running two instances is less than the LL/P-1 that the core can do for Prime95.

Would you guys recommend running 4-6 threads on 1 LL test? (due to HT)

[QUOTE=xtreme2k;285152]Would you guys recommend running 4-6 threads on 1 LL test? (due to HT)[/QUOTE]No, best performance is one L-L test per (real) core. You can assign 2 threads per test to make use of hyperthreading if you like, it may or may not make any actual performance difference.

As I said above, on my 2600K, I run two threads per test, where each thread is assigned to half of the same physical core.

I've finally migrated all mfaktc instances over to version 0.18.

Last 6day average across the entire farm with all results by ver 0.18 is 1662GHz-days/day.

Previous average was 1400-ish GHz-days/day. To confuse things, I've added about 100GHz-days/day capacity in there as well by swapping out a cpu. :)

What I've noticed is that v0.18 needs a little more cpu grunt to max out GPUs.

-- Craig

[QUOTE=xtreme2k;285089]Thanks for all the response. I have used task manager to set the affinity for the thread for now. Its getting late for me now in Sydney so I will come back to this tomorrow!

How much quicker does a 570/580GTX TF?[/QUOTE]

I have two instances of mfaktc running. Each does TF 71—>72 in a little under two hours on GTX580 and corei7-970 @ 3.8 GHz.

[QUOTE=flashjh;285091]You're right. I wouldn't put more than one core per instance, but I think his GPU could handle more.
[/quote]

It depends on the setup. I have a Core 2 Quad that runs 2 instances on a GTS 450. Main reason why is that if I run 1 instance, I get 80M/s, where with the 2 running each instance gets 60M/s. Since I don't like to let SievePrimes move from 5000, my CPU's have 10+% of wait time, so I actually run P95 on all 4 cores, but the 2 sharing with mfaktc take about 8-10 times as long to run. My 2400 runs a GTX 560Ti and has the same setup, but the shared cores only take about 3x as long. It runs about 180M/s single instance, 260M/s combined.

[QUOTE=nucleon;285162]What I've noticed is that v0.18 needs a little more cpu grunt to max out GPUs.[/QUOTE]

Yepp, the GPU code is a little bit faster in 0.18 thus you'll need a bit more CPU power (or lower SievePrimes) to keep the GPU busy. There will be another little boost for especially for CC 2.0 chips once CUDA 4.1 is available.
[url]http://www.mersenneforum.org/showpost.php?p=279285&postcount=1328[/url]
[url]http://www.mersenneforum.org/showpost.php?p=280853&postcount=1368[/url]
[url]http://www.mersenneforum.org/showpost.php?p=281726&postcount=1409[/url]

Oliver

Heh. I've noticed my cpu wait go up, not down. I'll try and figure it out later.

mfaktc for repunits
 

Hi,

how much effort would it be to extend mfaktc to handle (generalized) repunits? The factors have the same (or similar) properties as Mersenne primes: 2kp+1.
If it is not too much work I would like to put this on the wish-list for mfaktc.

Thanks...

Hi!

[QUOTE=MrRepunit;285615]Hi,

how much effort would it be to extend mfaktc to handle (generalized) repunits? The factors have the same (or similar) properties as Mersenne primes: 2kp+1.
If it is not too much work I would like to put this on the wish-list for mfaktc.[/QUOTE]

Do you have any more information about generalized repunits (math)?

Oliver

[QUOTE=TheJudger;285775]Hi!

Do you have any more information about generalized repunits (math)?

Oliver[/QUOTE]

Here you go:
[URL]http://www.cs.uwaterloo.ca/journals/JIS/VOL3/DUBNER/dubner.pdf[/URL]
[URL]http://www.maths.tcd.ie/pub/ims/bull59/R5901.pdf[/URL]
[URL]http://en.wikipedia.org/wiki/Repunit[/URL]

I hope this is what you wanted.

Danilo

[QUOTE=TheJudger;283172]Can you try to upgrade the driver: [URL="http://developer.download.nvidia.com/compute/cuda/4_0/drivers/devdriver_4.0_linux_64_270.41.19.run"]devdriver_4.0_linux_64_270.41.19.run[/URL]


Well, if everything is right the CUDA SDK and CUDA Toolkit is [B]not[/B] needed to run the precompiled mfaktc executable. You'll need a proper driver, nothing more.

Oliver[/QUOTE]
Here's the issues I've had over the last 4 months or so with drivers.
[url]http://forums.nvidia.com/index.php?showtopic=220802[/url]

Hi Danilo,

[QUOTE=MrRepunit;285796]Here you go:
[URL]http://www.cs.uwaterloo.ca/journals/JIS/VOL3/DUBNER/dubner.pdf[/URL]
[URL]http://www.maths.tcd.ie/pub/ims/bull59/R5901.pdf[/URL]
[URL]http://en.wikipedia.org/wiki/Repunit[/URL]

I hope this is what you wanted.

Danilo[/QUOTE]

OK, might take some days until I look into it.

Oliver

[QUOTE=TheJudger;286386]Hi Danilo,

OK, might take some days until I look into it.

Oliver[/QUOTE]

Many thanks in advance!

[QUOTE=TheJudger;282838]Hello!

[URL]http://www.mersenneforum.org/mfaktc/mfaktc-0.18.tar.gz[/URL]
[URL]http://www.mersenneforum.org/mfaktc/mfaktc-0.18.win.zip[/URL]
[URL]http://www.mersenneforum.org/mfaktc/mfaktc-0.18.linux64.tar.gz[/URL]

The executables need at least a [B]CUDA 4.0[/B] capable driver (270 series driver or newer). The Windows zip archive contains both, the 32 bit and 64 bit version. I'll upload new executables once [B]CUDA 4.1[/B] is public available. The sources should compile with older CUDA version, too, but they might be slower. CUDA 4.1 will give another performance improvement for the barrett based kernels on compute capability 2.x GPUs (especially on 2.0).


Compared to mfaktc 0.17 there are "more than usuall" minor changes. Highlights from the Changelog.txt:[LIST][*]autoadjustment of SievePrimes is now less dependend on the gridsize and
absolute speed. Instead of measuring the absolute (average) time waited
per precessing block (grid size) now the relative time spent on waiting
for the GPU is calculated. In the per-class output "avg. wait" is replaced
by "CPU wait".[*]new commandline option: "-v" (verbosity) let the user decide how many
informations are printed
(suggested by aspen on [URL="http://www.mersenneforum.org"]www.mersenneforum.org[/URL])[*]"has a factor" result lines now contain informations (program name,
versions, bitlevel, ...) James Heinrich is working on this on the server
side. This should give more accurate credits for "has a factor" results
from the primenet server once this is fully implemented.[*]mfaktc no longer refuses to load a checkpoint file from a Linux version
with a Windows version of mfaktc and vice versa. Of course mfaktc still
refuses to load checkpoint files from other versions than itself
(identical version string!)[*]added a (simple) signal handler (captures SIGINT and SIGTERM).
1st ^C: mfaktc will exit after the currently processed class is finished.
2nd ^C: mfaktc will stop immediately[*]added a minimum delay between two checkpoint file writes. The user can set
the delay in mfaktc.ini (CheckpointDelay).[*]added a new code path to barrett79_mul32 and barrett92_mul32 kernels, CUDA
>= 4.1 features multiply-add with carry for compute capability >= 2.0.
On my GTX 470 (compute capability) this yields up to 15% for
barrett92_mul32 and up to 7% for barrett79_mul32 extra throughput.[/LIST]As usuall: finish your current assignments with your current version and do the update after it, mfaktc 0.18 will refuse foreign checkpoint files.

Oliver[/QUOTE]

Ok, so I'm having some problems. I've been running .18 for some time now, 5 instances with no problems.

Then, last couple of days only instance 1 has started crashing, no error window or anything -- it's just closes. The other problem is that it's duplicating work. For no apparent reason it will do the same factor 2 or 3 times at the same bit level (which is a huge waste) and it always crashes after a duplicate so it's wasting even more time. I tried deleting the .exe and using a fresh copy with no luck. I haven't changed anything else, so I don't know what it could be. The other four instances work fine, no lock-ups or closes or duplicate work. I at a loss here. Anyone having similar problems? Using Win7 64bit with two GTX 580s.

[QUOTE=flashjh;286436] it's duplicating work. For no apparent reason it will do the same factor 2 or 3 times at the same bit level [/QUOTE]
smells like no rights to write the worktodo file, is that opened by somebody else? did you change the rights? file attributes? (hidden, system?)
mfaktc needs to access worktodo file to modify the first line, therefore eliminate the work already done. If it can not do that, it will certainly repeat the work.

[QUOTE=LaurV;286443]smells like no rights to write the worktodo file, is that opened by somebody else? did you change the rights? file attributes? (hidden, system?)
mfaktc needs to access worktodo file to modify the first line, therefore eliminate the work already done. If it can not do that, it will certainly repeat the work.[/QUOTE]

I agree. I've tried all the normal stuff. The wierd part is it consistently repeats each factor one time and then force closes. I'll figure it our eventually.

EDIT: Just figured it out... program is fine. The script I use to open everything was opening the first two instances from the same directory. My fault, though I don't remember editing that file recently.

Thanks for the help

Jerry