[QUOTE=Bdot;288034]Yes, you're right - if it is reproducible at all.

bcp19, could you please rerun one of the slow exponents, just to make sure it is something in mfakto? If it is slow again, then I'd like to know what Windows you're running, and which Catalyst version so I can setup the same ...[/QUOTE]

Ok, reruning 29504443 which was 56 min. I'm running Win 7 and the driver under device manager says 8.892.0.0, which I think is the latest version, 12.1?

[QUOTE=bcp19;288044]Ok, reruning 29504443 which was 56 min. I'm running Win 7 and the driver under device manager says 8.892.0.0, which I think is the latest version, 12.1?[/QUOTE]

You are both exactly correct -- rerun the unusual in the exact same environment, and see if the results are the same.

Einstein once said "Insanity: doing the same thing over and over again and expecting different results.

Of course, he never believed in quantum undertainty; and certainly had never encountered Windows.... :grin:

[QUOTE=chalsall;288046]You are both exactly correct -- rerun the unusual in the exact same environment, and see if the results are the same.

Einstein once said "Insanity: doing the same thing over and over again and expecting different results.

Of course, he never believed in quantum undertainty; and certainly had never encountered Windows.... :grin:[/QUOTE]

Too true. Exp complete, 46 minutes. So some stray protons or neutrons must have been flying around causing time to warp on my 4th core.

[QUOTE=bcp19;288044]Ok, reruning 29504443 which was 56 min. I'm running Win 7 and the driver under device manager says 8.892.0.0, which I think is the latest version, 12.1?[/QUOTE]

Thanks, I should be able to run the same and see if I can find out what's up.

Edit: Oops, did not see this before:
[quote=bcp19]
Too true. Exp complete, 46 minutes. So some stray protons or neutrons must have been flying around causing time to warp on my 4th core.
[/quote]
Was that the same exponent again (a third time)? So we have 56m 20.353s, 56m and 46m? Sorry, I'm a bit confused ... :confused:

[QUOTE=Bdot;288062]Thanks, I should be able to run the same and see if I can find out what's up.

Edit: Oops, did not see this before:

Was that the same exponent again (a third time)? So we have 56m 20.353s, 56m and 46m? Sorry, I'm a bit confused ... :confused:[/QUOTE]

I only ran it twice. If you look close, I said I was rerunning the exp "which was 56 min".

File locks for worktodo and results
 

[QUOTE=bcp19;288091]I only ran it twice. If you look close, I said I was rerunning the exp "which was 56 min".[/QUOTE]
Sorry, my poor English had made me think this meant that the rerun took 56 min. Probably one of the occasions when it becomes obvious that I'm not a native English speaker ...

Anyway, thanks for the test - it seems the case can be blamed on Windows (or other applications running there), after all.

I have a question for the scripters among you. In the next mfakto version I plan to add file locking for worktodo and results files. While on Windows all APIs seems to boil down to the same underlying locking mechanism, on Linux we have fcntl/lockf and flock locks which are independent. In case you have scripts or programs for Linux to maintain worktodo and results files (such as [URL="http://www.gpu72.com/spider/"]Chalsall's Submission Spider[/URL]), would you consider synchronizing file accesses with mfakto? Do you have preferences which one to use? Is anyone accessing these files over NFS? Any other reasons why I should use one or the other? Of course I will provide these changes to Oliver when I got the locking to work, so that mfaktc can get the same.

[QUOTE=Bdot;288114]Sorry, my poor English had made me think this meant that the rerun took 56 min. Probably one of the occasions when it becomes obvious that I'm not a native English speaker ...

[/QUOTE]
FWIW, you've managed to get by me for *checks join date* 8 months. I only just now looked at your location.

[QUOTE=Bdot;288114]I have a question for the scripters among you. In the next mfakto version I plan to add file locking for worktodo and results files. While on Windows all APIs seems to boil down to the same underlying locking mechanism, on Linux we have fcntl/lockf and flock locks which are independent. In case you have scripts or programs for Linux to maintain worktodo and results files (such as [URL="http://www.gpu72.com/spider/"]Chalsall's Submission Spider[/URL]), would you consider synchronizing file accesses with mfakto? Do you have preferences which one to use?[/QUOTE]

This would be excellent. And it doesn't really matter which is used, just so long as everyone agrees to use the same one (which would effectively be defined by you). Perl (and, of course, C) can do any of them. fcntl is more powerful, but in this case lockf would be just fine (and is a little easier to use).

[QUOTE]Is anyone accessing these files over NFS? Any other reasons why I should use one or the other? Of course I will provide these changes to Oliver when I got the locking to work, so that mfaktc can get the same.[/QUOTE]

I know at least a few people are using NFS, so I would suggest in addition to the locking, you also consider implementing the same functionality as Prime95/mprime's worktodo.add feature. This would allow scripts to add work to mfakto with no risks, even on NFS, as it would be mfakto which would be the sole writer of the file.

I asked for this feature on the mfaktc thread; don't know if it was added to a todo list. Since you're looking at working at related functionality, could you consider doing so? I would then write a reservation spider to complement it (actually two, one for PrimeNet, and one for GPU72).

FWIW, I like being able to modify the worktodo without having to worry about mfatk*. I only check to make sure it's not close to finishing an assignment, which is the only time it writes files. When would it lock the file? All the time? (I personally find it a pain to have to stop MPrime to modify worktodo, especially if I have S2 P-1 going. From what I can tell, most of the changes I typically make would not be possible with worktodo.add, e.g. adding only in sequence only whenver MPrime feels like looking at the file.)

[QUOTE=Dubslow;288204]FWIW, I like being able to modify the worktodo without having to worry about mfatk*. I only check to make sure it's not close to finishing an assignment, which is the only time it writes files.[/QUOTE]

Or, depending on the settings, when it (randomly) finds a factor, which you cannot predict.

[QUOTE=Dubslow;288204]From what I can tell, most of the changes I typically make would not be possible with worktodo.add, e.g. adding only in sequence only whenver MPrime feels like looking at the file.)[/QUOTE]

But you are exceptional (with all meanings of the word intended :smile:).

Most would find this function useful....

Well then make the file locking a user option?