Running 5.10.45x64 Q6600 8gb Ram Vista Ultimate 64bit

Everything loads fine and runs fine (Riesel Sieve x64)
for about 1 hour after installation. Fantastic run times of 45 minutes per. Then, the run times start creeping up until they reach 32 bit levels or a bit higher and they stay there. Stopping and starting has no affect. Task Manager shows I'm still running the 64 bit versions. Am I missing something here. Memory not clearing? Virtual memory not clearing? Not a clue. I did the above with Prime Grid from scratch and got the same result.

PS: I tried 5.10.28x64 from scratch and had the same problem.

Well start discovering that either Q6600 or Vista have bottlenecks. I've been finding that if certain math sciences were on core0, they'd cause others to go much slower.... longer run times. Relegate them to core3 using affinity and all races at the combined max. Don't know why, but it's like there's only one of something.

How to experiment: Open task Manager or Process Explorer, right click the process and play around. It does not stick as the next job starting goes back to default getting any core0-core3 range assigned.

Think someone wrote a type of scripting to allow 1 of a target science, but think it was only designed to handle one and not multiple and not dealing with affinity.

There is a compile around that has the affinity option added, so think it's not only useful for stopping the OS to randomly assign cores and say reserve core2-3 for BOINC when it's allowed to only run 50% on a quad (the 6.1.x pref gives % not processor counts).

Well the answer was close to what you surmised.

Riesel Sieve and Prime Grid (PSP) run exactly the same program with different parameters and data files. If I put both on one machine, the symptoms popped up. If I kept them on separate machines, everythings fine. I'm assuming that something got hosed in the registry or OS. Rebooting didn't fix it, but reloading the OS and only starting one project per machine did. Strange.

I've been finding that if certain math sciences were on core0, they'd cause others to go much slower.... longer run times. Relegate them to core3 using affinity and all races at the combined max. Don't know why, but it's like there's only one of something.

How to experiment: Open task Manager or Process Explorer, right click the process and play around. It does not stick as the next job starting goes back to default getting any core0-core3 range assigned.

Think someone wrote a type of scripting to allow 1 of a target science, but think it was only designed to handle one and not multiple and not dealing with affinity.

There is a compile around that has the affinity option added, so think it's not only useful for stopping the OS to randomly assign cores and say reserve core2-3 for BOINC when it's allowed to only run 50% on a quad (the 6.1.x pref gives % not processor counts).

Summary of the verbose: It's time to get this as an official option, hidden in ultra-advanced view (protection against the Simple view user just peaking into the advanced view ;>)

Weird it is.....

Until something like this will be implemented, manually (per affinity mask) sticking the Boinc client to any set of cores (e.g. the mentioned c2+c3) should do it until the next Boinc restart - all subsequently started project applications, being client's child processes, will also be forced to stick to the same set of cores.

Peter

Riesel Sieve and Prime Grid (PSP) run exactly the same program with different parameters and data files. If I put both on one machine, the symptoms popped up. If I kept them on separate machines, everythings fine. I'm assuming that something got hosed in the registry or OS. Rebooting didn't fix it, but reloading the OS and only starting one project per machine did. Strange.

IIRC both use (possibly the same) wrapper? Shouldn't harm at all. Anyway I'd rather bet the actual science apps, started from the wrapper, do somehow interfere - it may depend on particular CPU: FSB saturation, concurrent usage of the same CPU internal unit like FPU or any else, maybe cache lines thrashing or whatever.

Different execution efficiency while running Seti+Seti, Seti+Einstein and Einstein+Einstein were already observed many years ago. I believe the same might be true for any combination of CPU/memory/etc. intensive applications.

Peter

Riesel Sieve and Prime Grid (PSP) run exactly the same program with different parameters and data files. If I put both on one machine, the symptoms popped up. If I kept them on separate machines, everythings fine. I'm assuming that something got hosed in the registry or OS. Rebooting didn't fix it, but reloading the OS and only starting one project per machine did. Strange.

IIRC both use (possibly the same) wrapper? Shouldn't harm at all. Anyway I'd rather bet the actual science apps, started from the wrapper, do somehow interfere - it may depend on particular CPU: FSB saturation, concurrent usage of the same CPU internal unit like FPU or any else, maybe cache lines thrashing or whatever.

The wrapper shouldn't matter.

The actual science app is the same on both projects.

---

@Pepo, thanks for that mask comment...

You're welcome!

Someone was listening to the plight and created Bill2's Process Manager (Windows incl.Vista). It handles affinity, multiple instances, priority and throttling.... running right now on the test dual core with 90% ceiling.

http://www.bill2-software.com/processmanager/screenshots.shtml

Might be an interesting app, but I'm fighting hard with French language. Just guessing the meaning of images and sentences :-(

Peter

...English interface for the non frog speaking...

:-)

Quack!