I have started the runs


ps_separation_85_DR8_rev_2_2
de_separation_85_DR8_rev_2_2

ps_separation_86_DR8_rev_2_2
de_separation_86_DR8_rev_2_2



Jeff Thompson

I have added these runs.....

ps_separation_84_DR8_rev_2_2
de_separation_84_DR8_rev_2_2

ps_separation_83_DR8_rev_2_2
de_separation_83_DR8_rev_2_2

Hi Jeffrey,

is there something wrong with these runs?

I have six and the first has been running on my CPU for 17 hours and still only 90% complete.

I checked the progress that others have had with these separation wus and it seems that no one has had any success.

I will continue to plod on and report back here if I have any progress.

John

Checking out the machine you have connected I noted this

NVIDIA GeForce 9300 GE (256MB) driver: 314.22 OpenCL: 1.00

So my first suggestion is when the long unit is done to update the driver on the video card and than detach and reattach to the project.


The OpenCL 1.1 driver is described in the article below but I do not have experience with your particular card you may want to ask other users in the Number Crunching forum to see if they have direct experience with the card.

http://www.gpu-tech.org/content.php/162-Nvidia-supports-OpenCL-1-1-with-Geforce-280-19-Beta-performance-suffers

Thanks Jeffrey,

I am set not to use the GPU as, since I started with BOINC, my GPU was too weak to recommend its use. I really do not want to receive GPU tasks.

The Runtime was 73,811 and the CPUtime was 5,933 so I do not know what was going on in all these blank seconds. When I looked at the task and work number I noticed that there were no results from a wingman even though it has been validated.

Please see Task 508422281 and wu 387829872.

If the other 5 are like this then I am not sure that I should crunch them.

Please advise me how to proceed.

John

I was checking the turnaround time on your work units compared to other users.

All the current one are GPU though so a direct comparison was not possible. Though I found one of your current work units finished by a user who was CPU only.

When 387981432 is done I will compare the times.

But just comparing it to the previous units you are running longer than a comparable user by a significant factor.

This would suggest that there is a local issue that delaying processes. Most likely for this large of CPU time it may be the application is using swap space. I would suggest suspending all tasks but one and see if it improves the run time.

Jeff

Ok Jeffery,

the unit that gave me the trouble is 387829872. For 5,000 odd cpu with Milky way I would normally expect about 7,000 odd total time not 70,000 odd so something is wrong somewhere. It is an old E4700 dual core Acer but I run it 24/7

I don't run games or watch TV or anything like that the only other thing running on the second core is SETI@H and I have been running both successfully for years.

There is something different with that wu?

What I will do is to start one of the other 6 and see what happens but if it runs for 18 hours then I will have to call it quits and see if I can download something with a shorter run time.

Thanks for your input I will post here if there are any developments.

John

For 5,000 odd cpu with Milky way I would normally expect about 7,000 odd total time not 70,000 odd so something is wrong somewhere.

Check wether the CPU is @ 100% load. If that's the case, check what is using it (since Milkyway is apparently not getting much of it).

---

Thanks Link,

I am running at 100%. I have looked at process explorer and task manager and think that a proprietary backup system from Acer has been hanging on to my processing time. I have stopped it and hope to see a difference over the next 24 hours.

I have checked the SET@H results and the are now showing a lack of CPU time as well.

It looks as if that is the solution.

Apologies to Jeffery it seems to have been a coincidence that the separation runs came along at the same time as this program started to hang.

Thanks to all for the input.

John

Apology accepted but not needed.
I have been trolling through the database for estimated vs actual run times trying to fix the n-body calculations so it wasn't a big research jump from what I have been doing.

Jeff