[QUOTE=Prime95;256446]Try putting "NumCPUs=4" and "[color=blue]NumCpu[/color]Hyp[color=red]y[/color]erthreads=1" in local.txt.[/QUOTE]I think that should be "CpuNumHyperthreads=1"

[QUOTE=clarke;256423]Prime95 26.5 on Celeron D340 2.9GHz (256k L2) throws error after passing 960k blend self-test:[/QUOTE]

Fixed in next release. To work around problem choose a Custom test with a minimum FFT length of 100K

[QUOTE=Batalov;256114]worktodo.txt needs to be updated when temp p* files are written (e.g. if the interval is 15 minutes).
It seems to be out of date.[/QUOTE]

Did you set WellBehavedWork=1?? As far as I can see, this is the only reason worktodo.txt would not get updated immediately. That option tells prime95 to write worktodo.txt every half hour.

[QUOTE=Prime95;256481]Did you set WellBehavedWork=1?? As far as I can see, this is the only reason worktodo.txt would not get updated immediately. That option tells prime95 to write worktodo.txt every half hour.[/QUOTE]
Yup. That, indeed, is totally correct (because of some older batch of work). I (silently) found it a day later (and reverted it) but forgot to report. I actually mentally gave you a >>50% chance to find it, - and I was not disappointed. Kudos! ;-)

[QUOTE=Prime95;256446]Try putting "NumCPUs=4" and "CpuNumHyperthreads=1" in local.txt.[/QUOTE]

Thanks, but it didn't work.
I also re-enabled hyperthreading. Still didn't work.
It doesn't even load into memory when I click it.

I'm using a core i7 2600k
8 GB Ram
Gigabyte p67a-ud5 mainboard.

Everything is perfect on 26.4, though.

[QUOTE=Falkentyne;256741] Still didn't work.
It doesn't even load into memory when I click it.
I'm using a core i7 2600k
Everything is perfect on 26.4, though.[/QUOTE]

I'm working on a new theory. 26.5 uses the xgetbv instruction
to see if AVX is supported. I'm guessing XP does not support
this instruction, resulting in this strange failure mode.

In 26.6, I've added some code to bypass xgetbv in your case.
I'll have a version ready for you to test once I can get some
Celeron benchmarks to work on a different bug.

Can I help you with Celeron benchmarks? Some quite old Celeron Conroe-L 512k, Willamette-128, Northwood-128, Celeron D Prescott-256 s478/775, Tualatin-256, Coppermine-128 are still running around.

[QUOTE=Prime95;256993]I'm working on a new theory. 26.5 uses the xgetbv instruction
to see if AVX is supported. I'm guessing XP does not support
this instruction, resulting in this strange failure mode.

In 26.6, I've added some code to bypass xgetbv in your case.
I'll have a version ready for you to test once I can get some
Celeron benchmarks to work on a different bug.[/QUOTE]

Oh ok, thank you.

[QUOTE=clarke;257016]Can I help you with Celeron benchmarks? Some quite old Celeron Conroe-L 512k, Willamette-128, Northwood-128, Celeron D Prescott-256 s478/775, Tualatin-256, Coppermine-128 are still running around.[/QUOTE]

Thanks. I could use the Conroe-L 512K benchmark. See this thread for details:
[url]http://www.mersenneforum.org/showthread.php?t=15468[/url]

Improvement suggestion
 

I often manually start/stop workers. With increasing number of CPU cores it would help to enhance the dialog labelled with "Worker number to start/stop".
Given the "all option" is not selected I suggest that instead of single numbers user can also enter intervals.
For example:
2,5-8 --> start/stop 2 and 5 to 8. Derived from print page selection. Label would become "Worker number(s) to start/stop"
Shouldn't be too much work...

Minor bugs when using #workers < #cores
 

I ran into a couple of less than optimum issues when running 2 workers on my 4 core i7 920 processor. (My electric bill has sent me on a frugality hunt)

i7-920 @ 3.5 GHz w/ HT
Gigabyte Mobo GA-EX58-UD3R
3x 2GB 1333 MHz DDR3
Prime95 Windows 64-bit 26.5 build 5


[B]Smart Assignment isn't so smart: [/B]
I noticed that my iteration times were slowing down by up to 10% on an otherwise untouched system, from 17 ms to 19ms on a LL-D in the 25M range. From the looks of my Task Manager performance graphs at high speed, the task was switching between cores. Not a disaster, but when changed the cpu assignments to a fixed core (5 & 7), the iterations dropped back to a consistent 17 ms. My guess is the L2 cache was getting dumped during core switches, slowing things down a touch.


[B]CPUS are numbered differently in Worker Window and Status window:[/B]
When editing the Worker Window assignments, CPUs are numbered 1-8. In the status window, they are numbered 0-7. E.g. My worker #1 assigned to CPU #5 is described as affinity set to logical CPU #4 and #7 shows up as #6. No biggie, just slightly confusing.