View Single Post
Old 2009-08-09, 21:34   #3
A Sunny Moo
mdettweiler's Avatar
Aug 2007

3·2,083 Posts

Just today I've noticed somewhat of an oddity that appeared before in PFGW 3.2.0, but now is appearing in 3.2.1 in places where it didn't appear before. When a test is in progress, I'm not seeing the "mro=x sum=y/z" part on the status line. I'm not sure exactly what this refers to, but I'd assumed it has to do with roundoff checking. Thus, I was a little surprised when I didn't see it now, and was wondering if this means that PFGW isn't doing roundoff checking for numbers that it doesn't display it on.

Here's two specific examples of this:
PRP: 452*93^51672-1 227500/337900
This is from a run on a file containing 452*93^n-1 for n=50K-100K that was started earlier today on PFGW 3.2.0, but was switched to 3.2.1 not long ago. While on 3.2.0 it displayed the additional output, but it suddenly stopped (in the middle of a test, if memory serves) when I switched to 3.2.1.
PRP: 166*43^36252+1 7500/196720
In this case, it's testing a file containing two k's (166 and 648) for Sierpinski base 43, n=25K-100K. Like the above example, this was started earlier today on v3.2.0, and switched to 3.2.1 a few minutes ago, but this time it didn't display the "mro=" stuff with either version.

P.S.: Yowch! I just discovered another really odd occurrence since switching to PFGW 3.2.1. On 3.2.0, I got these timings on the two ranges mentioned above:
452*93^51464-1 is composite: RES64: [7AB30B57B2E2DBB3] (240.6095s+0.0107s)
452*93^51498-1 is composite: RES64: [C26986F583B81467] (256.2330s+0.0111s)
452*93^51608-1 is composite: RES64: [7985AC0305B44E65] (247.3637s+0.0106s)
648*43^36047+1 is composite: RES64: [D7CDA03750C324F9] (68.9006s+0.0050s)
166*43^36048+1 is composite: RES64: [147EC266EEEA3410] (68.0290s+0.0051s)
648*43^36067+1 is composite: RES64: [2F47965A2883BD43] (70.9499s+0.0050s)
However, when I switched to 3.2.1, the timings changed drastically for base 43 but not for base 93:
452*93^51666-1 is composite: RES64: [E410C86F842311A6] (244.1942s+0.0104s)
452*93^51672-1 is composite: RES64: [51B76772CED926B9] (247.2918s+0.0106s)
452*93^51711-1 is composite: RES64: [F8F10DE402182490] (249.0358s+0.0105s)
166*43^36084+1 is composite: RES64: [E67C4A5407871B82] (250.9955s+0.0066s)
648*43^36163+1 is composite: RES64: [9258F8073A0532F0] (244.2465s+0.0052s)
648*43^36183+1 is composite: RES64: [2775A27E5644CCCB] (246.0343s+0.0053s)
I've verified that each PFGW instance is getting an entire core to itself, as before. However, I can't seem to find any obvious clue to why this is happening; the two instances are in completely separate folders, so that can't be the problem. Possibly v3.2.1 is picking the wrong FFT size for base 43 or something? I tried restarting the program, but the problem persists, so thus I'd suspect something with the software.

BTW, is it possible to make PFGW output the FFT size it's using to screen for each test?

Edit: Oh, and while I'm at it, I was able to download this one just fine with IE 8. Possibly the problem is specific only to something with the 3.2.0 download.

Edit2: I've switched both clients back to 3.2.0 for now (which seems to work stably for this type of work at least), and the times went back to normal for base 43, but interestingly enough, for base 93, when I first restarted again with 3.2.0 it resumed showing the "mro=" stuff, but now it's stopped (after 3 tests into the resumed load). Anyway, it may not make much of a difference, but I figured I'd mention it for the sake of completeness.

Last fiddled with by mdettweiler on 2009-08-09 at 21:56
mdettweiler is offline   Reply With Quote