15 years ago, when I started BOINCing SETI, it was the case, and as far as I know still is, that a feature of BOINC was/is to use only spare cycles, by running at low priority.

Why do JMHARVEYs run at high priority?

15 years ago, when I started BOINCing SETI, it was the case, and as far as I know still is, that a feature of BOINC was/is to use only spare cycles, by running at low priority.

Why do JMHARVEYs run at high priority?

Different usage and meaning of the word 'priority'.

In the first case, when SETI first started (long before the BOINC platform was created and opened up for other projects), 'priority' referred to the thread/process priority of the task running on the CPU - and it was (and remains) low by comparison to the other primary tasks running on the computer - writing documents, surfing the web, reading emails etc. etc.

In the second case - where you are seeing it displayed in BOINC Manager - the word priority merely refers to the relative processing order of the BOINC tasks in the queue: there is some urgency to run that particular task because the time estimate is suggesting that it might not be completed before deadline.

15 years ago, when I started BOINCing SETI, it was the case, and as far as I know still is, that a feature of BOINC was/is to use only spare cycles, by running at low priority.

Why do JMHARVEYs run at high priority?

Different usage and meaning of the word 'priority'.

In the first case, when SETI first started (long before the BOINC platform was created and opened up for other projects), 'priority' referred to the thread/process priority of the task running on the CPU - and it was (and remains) low by comparison to the other primary tasks running on the computer - writing documents, surfing the web, reading emails etc. etc.

In the second case - where you are seeing it displayed in BOINC Manager - the word priority merely refers to the relative processing order of the BOINC tasks in the queue: there is some urgency to run that particular task because the time estimate is suggesting that it might not be completed before deadline.

Many thanks for the clarification, Richard :)

WU started 8.3 hours ago. It's done 5%. 8.3x20÷24=6.9 days to finish, two days after its deadline.

Tomba- runtime estimates for MDCPU are incorrect. For SSE2/SSE4/AVX tasks you're AMD CPU completes a task in under 24hr with 8threads. For 4threads: 48-72hr.

Unless something changed with App 9.03- a progress file exists showing how many steps have been computed. The progress file is located in allotted slot for MDCPU. 5million total steps for each work unit. An update for amount of steps computed happens every ten or so minutes.

http://www.gpugrid.net/forum_thread.php?id=3898

I've tweaked the estimated cost, but it'll take a while for the change to propagate.

Matt

For 4 threads: ~48hr.

OK. I had aborted that WU and stopped any more, but because of the above I decided to have another go.

At that time BOINC use-at-most preference was at 62.5% = five CPU threads. Darn me if the next MJHARVEY grabbed six! That is not gentlemanly!

I aborted that WU, set the preference to 50%, and the next one grabbed four, but stopped one of my GPU tasks. I gave BOINC another 12.5% and the stopped GPU task resumed, but, lo and behold, I immediately got another MJHARVEY!! (See my post below).

More thought needed, methinks...

At that time BOINC use-at-most preference was at 62.5% = five CPU threads. Darn me if the next MJHARVEY grabbed six! That is not gentlemanly!

That's a real number to integer rounding problem. Might be able to fix that, depending on where the conversion's made.

Mjh

Holy Moses! Just finished my dinner and checked. One of my GPU tasks had stopped!

Suspended the active MJHARVEY and the other one, which should never have been downloaded, started.

I've had enough nurse-maiding. I'm out of here. Sorry...

Tomba:

Please understand what is happening with the task scheduling, by reading this post:
http://www.gpugrid.net/forum_thread.php?id=3898&nowrap=true#38505

And if you feel the need to go into the web prefs to temporarily disable the GPUGrid MT CPU app, then by all means, feel free. It's obviously got some time estimation issues that are erroneously making them run as "high-priority" (earliest deadline first) mode, scheduled ahead of GPU jobs, which could interfere with your normal scheduling.

Kind regards,
Jacob

I am running the CPU application version 9.01 I noticed when I opened the progress text file it tells me I am running the following CPU

Build CPU brand:    Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz

however I am actually running and I 7 980 X the task is currently 62.9% complete. With another estimated 16 hours to go task name 1981-MJHARVEY_CPUDHFR-0-1-RND0908_2

For those interested the above task finished much sooner than I expected. Finished in 16.4 hours run-time and a CPU time 193.15 CPU hours

I am running the CPU application version 9.01 I noticed when I opened the progress text file it tells me I am running the following CPU

Build CPU brand:    Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz

however I am actually running and I 7 980 X the task is currently 62.9% complete. With another estimated 16 hours to go task name 1981-MJHARVEY_CPUDHFR-0-1-RND0908_2

Has anyone else noticed this? The reporting of wrong CPU.
Also could somebody please explain to me how the time is worked out in the progress file? E.g. after 3686000 steps it says under time 7372.00000

I think that CPU is the CPU used to compile the software...
In other words it might be MJH's CPU.

---

I am running the CPU application version 9.01 I noticed when I opened the progress text file it tells me I am running the following CPU

Build CPU brand:    Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz

however I am actually running and I 7 980 X the task is currently 62.9% complete. With another estimated 16 hours to go task name 1981-MJHARVEY_CPUDHFR-0-1-RND0908_2

Has anyone else noticed this? The reporting of wrong CPU.
Also could somebody please explain to me how the time is worked out in the progress file? E.g. after 3686000 steps it says under time 7372.00000

I think that CPU is the CPU used to compile the software...
In other words it might be MJH's CPU.

Thank you for the explanation, that would make sense. Interesting how the application doesn't get this information direct from Boinc. However I can understand how the above works

Tomba:

Please understand what is happening with the task scheduling, by reading this post:
http://www.gpugrid.net/forum_thread.php?id=3898&nowrap=true#38505

Thanks for the post, Jacob. I checked that thread but must confess most of it went right over my head!

Yesterday I reactivated the new CPU WUs. There were none, but overnight I got an MJHARVEY. I was happy to see that, with BOINC given 50% of my CPUs, no GPU task had been suspended.

The MJHARVEY just completed in a little over 16 hours, having used four CPUs.

I was not a little disappointed to get a mere 922 credits for my PCs efforts vs. 12k-19k for my GPUs. Perhaps the difference is a measure of the relative importance to the project of these new CPU tasks?

I encourage you to try to read through the thread one more time. Basically, when a task has a risk of not being able to meet a deadline unless it is given priority, BOINC will run it in "high-priority" mode.

And, if you read that post, paying special attention to the ordering, you will see that "high-priority CPU tasks" get scheduled BEFORE any "regular-priority GPU tasks".

So, if an MT task happens to go high-priority, then you can expect BOINC to only schedule up-to-1-CPU-worth of regular-priority GPU tasks. And, if *2* MT tasks go high-priority, then you can expect BOINC to not run any GPU tasks. I suspect that is the behavior that you saw.

Hope that helps,
Jacob

I encourage you to try to read through the thread one more time. Basically, when a task has a risk of not being able to meet a deadline unless it is given priority, BOINC will run it in "high-priority" mode.

I guess priority is a dead duck for these WUs. The task I got here did not say "high priority", and the deadline was Jan 5!!

Runtime is excellent with 4 threads. As is performance--
(ns/day)
7.436
(hour/ns)
3.228
AVX or SSE2 task-- stderr text states: projects/www.gpugrid.net/mdrun-463-901-sse-32.exe

If task priority is a "dead duck" then a system with two or more GPU's won't need "nurse-maiding"!

Are more January 5 deadline MJH tasks available for testing?

Runtime is excellent with 4 threads.

That's my trusty AMD FX-8350!

If task priority is a "dead duck" then a system with two or more GPU's won't need "nurse-maiding"!

In fact, it looks like Matt has fixed "That's a real number to integer rounding problem. Might be able to fix that, depending on where the conversion's made."

Why CPU MD running on does not show the percentage of the job?

is there AVX version of this app for new CPUS?

Why CPU MD running on does not show the percentage of the job?

is there AVX version of this app for new CPUS?