A little late to the testing game, but just picked up an iMac 2.8Ghz this weekend to replace my almost 3 year old iMac G5.

Small error with work type assignments.

Initial startup of client, I picked a single core, and type 5 ECM work. Then I stopped the client, set the worker threads to two, set new core work to type 5 ECM. Started up and got an LL test on the 2nd core. Went into the v5 page, unreserved and manually communicated, and got another one. Went into the v5 server, and on the computer properties saw the default work type for the newly added core to be default gimps. So changed it there and did another manual comm, and now have just ECM work.

So it appears adding the 2nd core made it to the server, just not the work type preference from the client side.

I'm still having memory-fighting issues. Thread 1 has P-1 work. Threads 2 and 3 have ECM. Thread 4 is TF. System has 1536MB allocated to Prime95. On startup #3 claims 464MB for ECM; #1 claims 1048MB for P-1. So far so good, but then #2, which had previously noticed "Other worker threads are using a lot of memory right now" restarts "with new memory settings", so there are now 3 threads contending for RAM they think is divided among only 2 threads, so eventually one of them tries to claim 500MB out of 5MB actually available, freaks out and dies with "out of memory" error. The other threads continue on their merry way, but then I'm left with 1 idle core.

The basic problem, as I see it, is that the threads don't quite properly register how many looking-for-RAM threads there are, and how much is already allocated between all of them.

[b]edit:[/b]
Maybe not even that. Just moments after posting the above, thread #2 freaked and said "Out of memory!" four times and died. I'm not sure why. #1 was using 762MB, leaving 774MB available, of which #2 tried to claim 757MB for ECM stage2.

[b]edit2:[/b]
Strange RAM things are happening in general. After posting "edit" above, #1 (being at the time the only thread using a lot of RAM) progressively determined itself to have a "Memory Allocation Error" and reduced the day/night settings from 1536/1792 down to (successively) 1433, 1146, and then 916MB. Now it seems to be happy running with 885MB allocated, but I don't understand why it does that. I currently have about 1300MB still-free physical RAM, so it shouldn't have problems allocating the extra memory.

[QUOTE=Prime95;128995]Looks OK to me. I got TF work this morning.[/QUOTE]I'm once again getting ECM work for my TF threads. Which, in conjunction with my above post regarding "Out Of Memory" errors is a bad thing -- I can't really run more than 1 thread doing work that requires stage2 RAM (P-1, ECM) because they inevitably fight and fail. I came home today to 2 of 4 threads stopped, and my RAM setting automagically reduced from 1536MB to 532MB (step by step, each time it failed).

On another note, it would probably be useful to put a warning in the Worker Threads config that assigning more than 1 thread to TF work is pointless (I get +0% performance increase with the 2nd thread). Possibly also a caution that more than 2 threads on P-1 isn't very useful (I get about +10% out of the 3rd thread).

[QUOTE=James Heinrich;129105]I'm once again getting ECM work for my TF threads.[/QUOTE]And now I can't get any work at all:[code][Mar 18 21:25] Sending result to server: UID: JamesHeinrich/q6600_256, M56549629 no factor from 2^66 to 2^67, Wd1: 1EC57854, AID: 38569EB2A1558E088E631E61A407D
[Mar 18 21:25]
[Mar 18 21:25] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ar&g=7a641ec983ee7558b170f9241820bcc1&k=38569EB2A1558E088E631E61A407D9D0&m=UID:+JamesHei
[Mar 18 21:25] Unexpected CURL library error: Could not resolve host: v5.mersenne.org; No data record of requested type
[Mar 18 21:25] Unexpected CURL library error: Could not resolve host: v5.mersenne.org; No data record of requested type
[Mar 18 21:25] Visit http://mersenneforum.org for help.
[Mar 18 21:25] Will try contacting server again in 18 minutes.
[/code]

I Have this message in my prime.log and and the server is still awaiting the outcome
[Wed Mar 12 07:52:03 2008 - ver 25.6]
Sending result to server: UID: zeit/SRV-110, M69516163 no factor from 2^66 to 2^67, Wd1: 9B34CE9C, AID: B00C1A08E2AD63C7758BABA6FB03E6D8

URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ar&g=618caba13755790435be2d858c35eec3&k=B00C1A08E2AD63C7758BABA6FB03E6D8&m=UID:+zeit/SRV-110,+M69516163+no+factor+from+2^66+to+2^67,+Wd1:+9B34CE9C,+AID:+B00C1A08E2AD63C7758BABA6FB03E6D8%0A&r=4&d=1&n=69516163&sf=66&ef=67&ss=41&sh=10DB459C2FB707D6861EC3A3C83AB08D
RESPONSE:
pnErrorResult=40
pnErrorDetail=TF result for M69516163 was not needed
==END==


thanks

Hi, i've got two overclocked machines (Q6600@3.6ghz) and i've always have runned tests with prime 95 / prime orthos at least 8H, and always worked fine no errors. I've tried the test with all versions and no problems running, tested always more than 8 hours (including 24h) all fine. This version gives me errors in such few time (20m/30m) in 2 or 3 cores. Is this normal? I've stop running 25.6 and try 25.5 and all is fine 24H without erros running both tests (SMALLFFT and BLEND). Something is wrong here and i don't believe its instability from BOTH machines cause they never failed and run without issues with ANY other versions or PROGRAM testing stability. Is 25.6 Beta Version?


Thanks.

I never managed to get my Q6600 Prime95-stable at 3.6GHz (it's currently running at 3.51GHz). Be aware that older versions of Prime95 (v24.x and older) would only run a single thread. At 3.60GHz, at best I could get it running for several hours before one thread failed. Once a thread had failed (and it was only running the 3 remaining threads) it could run indefinitely (well, 24h at least) with no errors, but with 4 threads running it always failed after 1-6 hours. Very close to stable, and for most purposes "good enough", but not good enough for Prime95 unfortunately.

I've been using 25.6.8 (as mprime -v shows) for a few weeks now without a problem.

Found the problem
 

It looks like it's a STRAP problem, now im running 25.6 with at 3.6ghz at the same 1.36v and it's all fine, 25.5 version works well with any STRAP. Solded ;) Thanks anyway.

2304K FFT size ineffective?
 

So, the 2304K FFT size (if it were effective) would have been really good for the now distributed 39.5-42M LL tests.

But as far as I've been able to absorb from one day's reading - it is just simply slower than 2560K FFT size. Has it been decisively tested? Could it be still marginally better on some particular CPUs (because of large cache and whatnot)?

I figured from the general back of the envelope calculations that the radix-10 is just almost as fast as radix-9 (from E.W.Mayer's math elsewhere), and this is the current rationale for not having any 9's; and I don't have enough grasp to estimate that radix-9 in turn is better still than twice radix-6 or radix-12 on top of the rest of powers of 2... Or are they?
2304K = 9 * 2^18 = 6 * 6 * 2^16 = 12 * 12 * 2^14

P.S. I appreciate that 12 is not one of the Winograd's numbers, neither is 9, but 6's are. I also read that two times awkward radix is worse than one time larger awkward radix, but what if 2304K is still faster than 2560K just a bit because of the lesser data size (or fits the cache better)? Could it be included in the bechmarks in 25.7 for starters if it is not too much work?
:google:... and I did!