Hi Matt,

So far, all tasks ending in error. Some stop immediately, some run for a while.

Here's my main question. Over at Milkyway@home, they are able to control the threads assigned to a multi-thread task using an app_config.xml file. I put together a similar app_config.xml file for the cpumd tasks and tried it on a few tasks.

My BOINC client has 10 threads assigned. I have an app_config.xml set up to limit the threads assigned to cpumd tasks to 6 threads. In BOINC Manager, the task shows that it is using 6 CPU's. However, the stderr.txt shows that it is using 10 openmp threads and system usage indicates that it is using all 10 threads.

My app_config:

Refer to the Application configuration documentation.

For most multi-threaded applications you need

<cmdline>--nthreads 6</cmdline>

to control the behaviour of the application, in addition to the <avg_ncpus>6</avg_ncpus> (which only controls BOINC's scheduling, as you've found).

I've only ever used --nthreads under Windows: I'm not sure whether it's applicable under Linux. Perhaps you or Matt could find out for us.

<cmdline>--nthreads 6</cmdline>

Matt and Richard,

Thanks for the advice. The cmdline option seemed to do the trick. It is now running on 6 threads.

Thanks for the help,
captainjack

I've just updated the app to correct for crashes on clients with venerable Core2 CPUs.

Matt

Could someone please report on the success or otherwise of suspend/resume of WUs?

Matt

Is there any real advantage in making the app multithreaded? It saves memory, but that's all that comes to mind. On the other hand I expect it to be less efficient than running several single-threaded tasks. Plus the BOINC scheduler seems to be bad at managing multithreaded apps.

Is there any real advantage in making the app multithreaded?

Plus the BOINC scheduler seems to be bad at managing multithreaded apps.

For the use we intend for it we need the results back in a timely manner. Running these WUs on a single core will work, but the results are likely to come back too late to be useful.

Plus the BOINC scheduler seems to be bad at managing multithreaded apps.

Well that's another thing entirely, and our problem to solve. I'm more concerned that the client doesn't give the user the desired level of control.

Matt said,

Could someone please report on the success or otherwise of suspend/resume of WUs?

Matt

Looks like it worked fine.

Matt,

I had a second task that was running when I shut down BOINC and started it back up again. That task has finished and validated.

Ubuntu 14.04
BOINC 7.2.42 installed using the Berkeley installer

Let us know if you want us to run some other tests.

Hi Everyone,

The new test application is now available for Windows as well as Linux. Please do help us test it!

This application does the same type of simulations as ACEMD, our GPU application. We reason why we are testing it now is that, in pinciple, modern CPUs are now finally fast enough to do process some of our WUs within an acceptable amount of time.

To get to that point though, it is essential to use multiple CPU simultaneously, so this is a multithreaded app. I'd encourage you to let the WUs run on all cores (which it will do by default). The performance scales linearly with core count.

The main objective of this first phase is to test application stability and measure achieved simulation rates and total throughput.

It's a Beta application - to get work for it, you'll need to have your profile set to allow CPU work, allow beta work and enable the application "Molecular Dynamics on CPU".

The app is largely feature-complete. The only issue I know is outstanding is that % completion statistics are wrong. I'm sure you'll all find other issues -
please post your experiences and observations here.

Matt
Matt

Hi Matt,

My Haswell 4771 on win7 did one but with error. Five of my wing(wo)man had error too. You can see it here: http://www.gpugrid.net/result.php?resultid=12877823

Off topic: my error page has also still one error on it from 31 Aug 2013 and one form 19 Nov 2013.
____________
Greetings from TJ

Hi Matt,

Just ran one of the multithread CPU tasks on a Windows 7 machine with 16 threads.

Matt said:

I'd encourage you to let the WUs run on all cores (which it will do by default). The performance scales linearly with core count.

My Haswell 4771 on win7 did one but with error.

My Haswell 4771 on win7 did one but with error.

Those were with the previous version. 844 is current, and should already have fixed those problems.

Matt

Thanks, will wait for new ones.

Matt,

you already know about the incorrect progress display, together with the elapsed and remaining run times, but you haven't mentioned if you see a way to fix this. If not, I'd like to point out that all calculations based on those values are of course wrong too, like computing speed, estimated run times and credits, possibly affecting system operations and user acceptance.

For completeness, all my 8.43 WUs so far have finished and validated without further issues, including one that restarted after a system shutdown. WU size seems reasonable.

There'll be a new version out later today, after stumps.

As promised, version 845 should report progress correctly.

Matt

Or not, because I don't know the difference between percentages and fractions. 846 out now, which should also correctly report to the client when a checkpoint was performed.

Matt

Just aborted a V845 that has been been at 100% complete forever...
According to BOINC it was 4,706.000% DONE

According to BOINC it was 4,706.000% DONE

Matt,
currently running a v 8.46 -
http://www.gpugrid.net/result.php?resultid=12898547

It has been running 1 hour and reports that it is 1% complete, with time to completion 5days and 36 minutes?

EDIT - Also, there are no other BOINC tasks or non-BOINC app's running. BOINC reports CPU usage at 100%, but Win XP Task Manager reports only 50% CPU usage.

Mine ran for roughly 5 1/2 hours, and went from 8732% to complete instantly, and the part that is really bothering me is that I have the test applications turned off.

Hi Matt,

Just started up an 8.46 job in Windows 7. My app_config is listed below, but the app seems to ignore the app_config settings for number of CPU's. Can you see something that needs to be changed in my app_config. BOINC Manager is not showing any errors when it reads the app_config.

The 8.46 task on Windows 7 just finished. It was running on 16 threads. Here are the estimates:

Elapsed minutes: 42
% complete: 1.75
Estimated to finish: 40:53:39

Elapsed minutes: 103
% complete: 4.2
Estimated to finish: 39:53:44

Elapsed minutes: 107
Finished

Hope that helps.

Captainjack,

That app config looks ok to me. Have a look in the stderr reported by the job, that will say at the top how many threads the program is using.

Matt

Excellent job. Multithreaded application works fine on my host, V846 report progress correctly. Now GPUGRID is like Folding@Home project - with apps for the GPUs and multi-core CPUs. Thx.

I don't have time to check my BOINC client all that often so I am not sure how long this has been going on. I had "Test Applications" disabled but I still found these work units running on my system. It appears GPU tasks will not run with these WUs using all the cores. At least that is my assumption, possibly an incorrect one, since no GPU WU was running or even pending.

I disabled the "Molecular Dynamics on CPU" jobs, updated the BOINC client, aborted all the MT WUs and updated the client again. No GPU WUs were loading so I tried updated the client again with the same results. The BOINC client log says no short or long GPU tasks are available. I checked the server and there are thousands of short and long WU that are unsent. I rebooted and I am still getting the same thing.

Any guesses on how long my GPU will remain idle?

The client log also says I have processed my daily quota of 16 tasks. :-(

I suppose that means I won't get any new tasks until tomorrow. I guess my GPU will get another day of vacation. :-)

Could someone confirm that a client without any special configuration will obtain and execute both CPU and GPU WUs simultaneously?

Matt

Could someone confirm that a client without any special configuration will obtain and execute both CPU and GPU WUs simultaneously?

Matt

I don't know about obtaining but I can confirm that Linux BOINC 7.2.47 does not suspend my Einstein GPU WUs when running cpumd on all cores. That must be a BOINC error however.

Matt asked:

Could someone confirm that a client without any special configuration will obtain and execute both CPU and GPU WUs simultaneously?

Hey there,

I received a very long WU (4377-MJHARVEY_CPUDHFR-0-1-RND8587_1) on my windows machine which has a runtime of approx. 305 hours. Really? The deadline is in one week. ;)

After ~ 10 min my computer has crunched ~ 0,042 %.

I guess, I will not be able to send this WU back in time. ;)

If I remember correctly, then one of my linux machines has such a WU as well.

Should I abort these ones?

Hi Matt,

Alrighty. I will ignore both. :)

Thx for the information.

I got one of the test applications for CPUMD.

http://www.gpugrid.net/result.php?resultid=13209824
http://www.gpugrid.net/workunit.php?wuid=10166393

Now at 0.442% progress (occasionally increasing by about 0.002%), 06:43:9 elapsed, 2930:20:57 estimated remaining.

Running high priority. Using 3 CPU cores, the maximum I allow BOINC to use on that computer.

If the estimated time to completion is anything close to accurate, I probably won't allow any more of these to run on that computer.

Running under 64-bit Windows Vista.

Haven't been able to receive any new AVX CPUMD tasks with BOINC version 7.4.21 even though 8000 CPUMD tasks are available.

14/10/21 04:21:30 | GPUGRID | No tasks are available for Test application for CPU MD
14/10/21 04:34:59 | GPUGRID | No tasks are available for Test application for CPU MD
14/10/21 07:42:57 | GPUGRID | No tasks are available for Test application for CPU MD
14/10/21 07:49:08 | GPUGRID | No tasks are available for Test application for CPU MD

I was also *unable* to get a new CPU task, on BOINC 7.4.22 x64.
Why?

10/21/2014 8:03:18 AM | GPUGRID | [work_fetch] set_request() for CPU: ninst 6 nused_total 2.00 nidle_now 6.00 fetch share 1.00 req_inst 6.00 req_secs 41472.00
10/21/2014 8:03:18 AM | GPUGRID | [sched_op] Starting scheduler request
10/21/2014 8:03:18 AM | GPUGRID | [work_fetch] request: CPU (41472.00 sec, 6.00 inst) miner_asic (0.00 sec, 0.00 inst) NVIDIA GPU (0.00 sec, 0.00 inst)
10/21/2014 8:03:18 AM | GPUGRID | Sending scheduler request: To fetch work.
10/21/2014 8:03:18 AM | GPUGRID | Requesting new tasks for CPU
10/21/2014 8:03:18 AM | GPUGRID | [sched_op] CPU work request: 41472.00 seconds; 6.00 devices
10/21/2014 8:03:18 AM | GPUGRID | [sched_op] miner_asic work request: 0.00 seconds; 0.00 devices
10/21/2014 8:03:18 AM | GPUGRID | [sched_op] NVIDIA GPU work request: 0.00 seconds; 0.00 devices
10/21/2014 8:03:19 AM | GPUGRID | Scheduler request completed: got 0 new tasks
10/21/2014 8:03:19 AM | GPUGRID | [sched_op] Server version 613
10/21/2014 8:03:19 AM | GPUGRID | No tasks sent
10/21/2014 8:03:19 AM | GPUGRID | Project requested delay of 31 seconds
10/21/2014 8:03:19 AM | GPUGRID | [work_fetch] backing off CPU 603 sec
10/21/2014 8:03:19 AM | GPUGRID | [sched_op] Deferring communication for 00:00:31
10/21/2014 8:03:19 AM | GPUGRID | [sched_op] Reason: requested by project

For my work fetch request which yielded 0 CPU tasks...
Computer ID was: 153764

It's an 8-logical-CPU machine, setup to run 75% of CPUs (since I'm running 2 cpu-intensive VM tasks outside of BOINC)... so I usually get MT tasks that run 6 CPUs on this machine. The machine also has 3 NVIDIA GPUs.

2 questions:

Are you sure my computer is avx capable? [This machine just celebrated its 5-year-birthday, with no upgrades to mobo nor CPU] */**
Are you sure the BOINC client is supposed to be able to detect that and relay that to the server scheduler?

If the answer is yes to both, then I'll pass the info to the BOINC Alpha mailing list to see if it's a bug.

* This website seems to indicate I might legitimiately NOT have avx, based on dates:
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
** Here's my CPU, I believe: http://ark.intel.com/products/37149/Intel-Core-i7-965-Processor-Extreme-Edition-8M-Cache-3_20-GHz-6_40-GTs-Intel-QPI

I am not receiving any CPU tasks from GPUGrid, as evidenced by my work fetch request/response that I pasted a couple posts up.

BOINC 7.4.21 properly reporting CPU feature set for Intel Ivy Bridge.

14/10/20 18:23:06 | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes f16c rdrandsyscall nx lm avx vmx tm2 pbe fsgsbase smep


14/10/21 09:05:00 | GPUGRID | No tasks are available for Test application for CPU MD

On this page:
http://www.gpugrid.net/apps.php
... it seems that the only x64 version offered is avx.

Or, is it supposed to send me the x86 (mtsse4) app, even though I'm using x64? Because, that did not happen :(

Getting 901 now?

My first avx with error:
http://www.gpugrid.net/result.php?resultid=13227076

Name 86-MJHARVEY_TEST1001-0-1-RND5489_1
Workunit 10157681
Created 17 Oct 2014 | 11:36:40 UTC
Sent 21 Oct 2014 | 15:34:02 UTC
Received 21 Oct 2014 | 15:35:57 UTC
Server state Over
Outcome Computation error
Client state Compute error
Exit status 255 (0xff) Unknown error number
Computer ID 169357
Report deadline 26 Oct 2014 | 15:34:02 UTC
Run time 0.41
CPU time 0.00
Validate state Invalid
Credit 0.00
Application version Test application for CPU MD v9.01 (mtavx)
Stderr output

<core_client_version>7.4.22</core_client_version>
<![CDATA[
<message>
The extended attributes are inconsistent.
(0xff) - exit code 255 (0xff)
</message>
]]>
____________

Multiple Test application for CPU MD v9.01 (mtavx) failures- all with the same error message: The extended attributes are inconsistent. (0xff) - exit code 255 (0xff)

All tasks have 0.00 CPU/run time.

My machine got work now, a 9.01 mtsse4 task. I will start it soon, and reply with the result.

9.02 is working--BOINC progress is 0.023 at fifteen minutes. Task has 10000hr estimated runtime throwing the 20mgx GPU task to the side. Estimated runtime is going up as task computes- currently @ 12000hr.

If BOINC is correctly reporting task progress-- CPU time till complete-- 10hr for every 1% computed > 1000hr/44days total runtime?

14/10/21 17:06:26 | GPUGRID | [cpu_sched_debug] unfoldx476-NOELIA_UNFOLD-3-72-RND3785_0 sched state 2 next 2 task state 1
14/10/21 17:06:26 | GPUGRID | [cpu_sched_debug] 20mgx396-NOELIA_20MG2-2-50-RND9100_1 sched state 1 next 1 task state 0
14/10/21 17:06:26 | GPUGRID | [cpu_sched_debug] 4083-MJHARVEY_CPUDHFR-0-1-RND9529_1 sched state 2 next 2 task state 1
14/10/21 17:10:45 | GPUGRID | [rr_sim_detail] 0.00: starting 4083-MJHARVEY_CPUDHFR-0-1-RND9529_1 (4.00 CPU) (514480914.05G/12.54G)
14/10/21 17:10:45 | | [rrsim_detail] rpbest: 4083-MJHARVEY_CPUDHFR-0-1-RND9529_1 (finish delay 40205433.52)
14/10/21 17:11:45 | GPUGRID | [rr_sim] 4083-MJHARVEY_CPUDHFR-0-1-RND9529_1 misses deadline by 40416714.74

does it work for pricese puppy 5.7? I do not get any WUs. Thanks.

Just tried one of these WUs. My BOINC preference is set to used 50% of the processors, which is four of my eight. The WU grabbed four; Task Manager showed this task using 50%.

Thermal Radar normally shows my CPU temp at 41C. Within five minutes the temp had shot up to 65C and the red warning came on. I killed the WU.

Anyone else having CPU overheating problems with these WUs?

I did. i changed "Use at moust 40.00% of CPU time ( 0 means no restriction ).

____________

Just tried one of these WUs. My BOINC preference is set to used 50% of the processors, which is four of my eight. The WU grabbed four; Task Manager showed this task using 50%.

Thermal Radar normally shows my CPU temp at 41C. Within five minutes the temp had shot up to 65C and the red warning came on. I killed the WU.

Anyone else having CPU overheating problems with these WUs?

65C is hardly an unreasonable operating temperature for a CPU.

Who says red is bad? Maybe red is just "hi", and then ultraviolet neon green is "nuclear"?

:)

Basically, your TjMax is 90. You should feel comfortable going up to 80*C or maybe even 85*C, I'd think, before worrying about heat and stability.

Is the time estimate for these work units incorrect? I have no slouch of a processor, a 4790K @ stock speeds, and it estimates 66 hours to completion with just shy of four hours of work done. If this is accurate, I will barely be able to complete the two I have downloaded before their turn in time on the 28th assuming I use my computer for a standard 8 hours a day.

I am getting "Download failed" when downloading the CPU app (avx version) on a Windows 7 x64.

EDIT: MD5 check fail.
EDIT2: Checking the "skip image file verification" under BOINC preferences fixed the error... but I'm pretty sure this is not how things should be done.
EDIT3: I re-enabled the image file verification and it managed to download it correctly, yet it only uses 1 core (although BOINC says 8), and the progress report seems to have gotten stuck with:

Log file opened on Fri Oct 24 01:12:46 2014
Host: unknown pid: 6588 rank ID: 0 number of ranks: 1
GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2

GROMACS is written by:
Emile Apol Rossen Apostolov Herman J.C. Berendsen Par Bjelkmar
Aldert van Buuren Rudi van Drunen Anton Feenstra Sebastian Fritsch
Gerrit Groenhof Christoph Junghans Peter Kasson Carsten Kutzner
Per Larsson Justin A. Lemkul Magnus Lundborg Pieter Meulenhoff
Erik Marklund Teemu Murtola Szilard Pall Sander Pronk
Roland Schulz Alexey Shvetsov Michael Shirts Alfons Sijbers
Peter Tieleman Christian Wennberg Maarten Wolf
and the project leaders:
Mark Abraham, Berk Hess, Erik Lindahl, and David van der Spoel

Copyright (c) 1991-2000, University of Groningen, The Netherlands.
Copyright (c) 2001-2014, The GROMACS development team at
Uppsala University, Stockholm University and
the Royal Institute of Technology, Sweden.
check out http://www.gromacs.org for more information.

GROMACS is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License
as published by the Free Software Foundation; either version 2.1
of the License, or (at your option) any later version.

GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2
Executable: D:\ProgramData\BOINC\slots\8\projects\www.gpugrid.net\mdrun-502-902-avx-64.exe
Library dir: C:\Program Files\Gromacs\share\gromacs\top
Command line:
mdrun-502-902-avx-64 -ntomp 8 -nt 8 -x traj.xtc -s topol.tpr -g progress.log -cpi state.cpt

Gromacs version: VERSION 5.0.2
Precision: single
Memory model: 64 bit
MPI library: thread_mpi
OpenMP support: enabled
GPU support: disabled
invsqrt routine: gmx_software_invsqrt(x)
SIMD instructions: AVX_256
FFT library: fftw3
RDTSCP usage: enabled
C++11 compilation: disabled
TNG support: enabled
Tracing support: disabled
Built on: Unknown date
Built by: Anonymous@unknown [CMAKE]
Build OS/arch: Windows-6.1 AMD64
Build CPU vendor: GenuineIntel
Build CPU brand: Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz
Build CPU family: 6 Model: 42 Stepping: 7
Build CPU features: apic clfsh cmov cx8 lahf_lm mmx msr pse rdtscp sse2 sse3 ssse3
C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe MSVC 16.0.30319.1
C compiler flags: /arch:AVX /DWIN32 /D_WINDOWS /W3 /MD /O2 /Ob2 /D NDEBUG
C++ compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe MSVC 16.0.30319.1
C++ compiler flags: /arch:AVX /DWIN32 /D_WINDOWS /W3 /GR /EHsc /wd4800 /wd4355 /wd4996 /wd4305 /wd4244 /wd4101 /wd4267 /wd4090 /MD /O2 /Ob2 /D NDEBUG
Boost version: 1.55.0 (internal)



++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
B. Hess and C. Kutzner and D. van der Spoel and E. Lindahl
GROMACS 4: Algorithms for highly efficient, load-balanced, and scalable
molecular simulation
J. Chem. Theory Comput. 4 (2008) pp. 435-447
-------- -------- --- Thank You --- -------- --------


++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
D. van der Spoel, E. Lindahl, B. Hess, G. Groenhof, A. E. Mark and H. J. C.
Berendsen
GROMACS: Fast, Flexible and Free
J. Comp. Chem. 26 (2005) pp. 1701-1719
-------- -------- --- Thank You --- -------- --------


++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
E. Lindahl and B. Hess and D. van der Spoel
GROMACS 3.0: A package for molecular simulation and trajectory analysis
J. Mol. Mod. 7 (2001) pp. 306-317
-------- -------- --- Thank You --- -------- --------


++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
H. J. C. Berendsen, D. van der Spoel and R. van Drunen
GROMACS: A message-passing parallel molecular dynamics implementation
Comp. Phys. Comm. 91 (1995) pp. 43-56
-------- -------- --- Thank You --- -------- --------

Changing nstlist from 10 to 20, rlist from 0.9 to 0.928

Input Parameters:
integrator = md-vv
tinit = 0
dt = 0.002
nsteps = 5000000
init-step = 0
simulation-part = 1
comm-mode = Linear
nstcomm = 100
bd-fric = 0
ld-seed = 1993
emtol = 10
emstep = 0.01
niter = 20
fcstep = 0
nstcgsteep = 1000
nbfgscorr = 10
rtpi = 0.05
nstxout = 0
nstvout = 0
nstfout = 0
nstlog = 1000
nstcalcenergy = 100
nstenergy = 1000
nstxout-compressed = 25000
compressed-x-precision = 1000
cutoff-scheme = Verlet
nstlist = 20
ns-type = Grid
pbc = xyz
periodic-molecules = FALSE
verlet-buffer-tolerance = 0.005
rlist = 0.928
rlistlong = 0.928
nstcalclr = 10
coulombtype = PME
coulomb-modifier = Potential-shift
rcoulomb-switch = 0
rcoulomb = 0.9
epsilon-r = 1
epsilon-rf = inf
vdw-type = Cut-off
vdw-modifier = Potential-switch
rvdw-switch = 0.75
rvdw = 0.9
DispCorr = No
table-extension = 1
fourierspacing = 0.1
fourier-nx = 64
fourier-ny = 64
fourier-nz = 64
pme-order = 4
ewald-rtol = 1e-005
ewald-rtol-lj = 1e-005
lj-pme-comb-rule = Geometric
ewald-geometry = 0
epsilon-surface = 0
implicit-solvent = No
gb-algorithm = Still
nstgbradii = 1
rgbradii = 1
gb-epsilon-solvent = 80
gb-saltconc = 0
gb-obc-alpha = 1
gb-obc-beta = 0.8
gb-obc-gamma = 4.85
gb-dielectric-offset = 0.009
sa-algorithm = Ace-approximation
sa-surface-tension = 2.05016
tcoupl = Nose-Hoover
nsttcouple = 10
nh-chain-length = 10
print-nose-hoover-chain-variables = FALSE
pcoupl = No
pcoupltype = Isotropic
nstpcouple = -1
tau-p = 1
compressibility (3x3):
compressibility[ 0]={0.00000e+000, 0.00000e+000, 0.00000e+000}
compressibility[ 1]={0.00000e+000, 0.00000e+000, 0.00000e+000}
compressibility[ 2]={0.00000e+000, 0.00000e+000, 0.00000e+000}
ref-p (3x3):
ref-p[ 0]={0.00000e+000, 0.00000e+000, 0.00000e+000}
ref-p[ 1]={0.00000e+000, 0.00000e+000, 0.00000e+000}
ref-p[ 2]={0.00000e+000, 0.00000e+000, 0.00000e+000}
refcoord-scaling = No
posres-com (3):
posres-com[0]=0.00000e+000
posres-com[1]=0.00000e+000
posres-com[2]=0.00000e+000
posres-comB (3):
posres-comB[0]=0.00000e+000
posres-comB[1]=0.00000e+000
posres-comB[2]=0.00000e+000
QMMM = FALSE
QMconstraints = 0
QMMMscheme = 0
MMChargeScaleFactor = 1
qm-opts:
ngQM = 0
constraint-algorithm = Shake
continuation = FALSE
Shake-SOR = FALSE
shake-tol = 0.0001
lincs-order = 4
lincs-iter = 1
lincs-warnangle = 30
nwall = 0
wall-type = 9-3
wall-r-linpot = -1
wall-atomtype[0] = -1
wall-atomtype[1] = -1
wall-density[0] = 0
wall-density[1] = 0
wall-ewald-zfac = 3
pull = no
rotation = FALSE
interactiveMD = FALSE
disre = No
disre-weighting = Conservative
disre-mixed = FALSE
dr-fc = 1000
dr-tau = 0
nstdisreout = 100
orire-fc = 0
orire-tau = 0
nstorireout = 100
free-energy = no
cos-acceleration = 0
deform (3x3):
deform[ 0]={0.00000e+000, 0.00000e+000, 0.00000e+000}
deform[ 1]={0.00000e+000, 0.00000e+000, 0.00000e+000}
deform[ 2]={0.00000e+000, 0.00000e+000, 0.00000e+000}
simulated-tempering = FALSE
E-x:
n = 0
E-xt:
n = 0
E-y:
n = 0
E-yt:
n = 0
E-z:
n = 0
E-zt:
n = 0
swapcoords = no
adress = FALSE
userint1 = 0
userint2 = 0
userint3 = 0
userint4 = 0
userreal1 = 0
userreal2 = 0
userreal3 = 0
userreal4 = 0
grpopts:
nrdf: 48414
ref-t: 300
tau-t: 0.8
annealing: No
annealing-npoints: 0
acc: 0 0 0
nfreeze: N N N
energygrp-flags[ 0]: 0

I'm currently running the mdrun-502-902-avx-64.exe program for Windows 64 bit. The program has been running for about 7 hours and is about to go to 6% complete. However, if I start the task manager it reports the program is only using 27-28% cpu, even though it should be running all 4 cores.

Does it take a while for the program to start using all 4 of the cores?

Here is the stderr.txt output:

BOINC wrapper for GROMACS.
Arg 0 [projects/www.gpugrid.net/mdrun-502-902-avx-64.exe]
Arg 1 [--nthreads]
Arg 2 [4]
BOINC running with [4] threads
BOINC resolving [traj.xtc] to [traj.xtc]
BOINC resolving [topol.tpr] to [topol.tpr]
BOINC resolving [progress.log] to [progress.log]
BOINC resolving [state.cpt] to [state.cpt]
GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2

GROMACS is written by:
Emile Apol Rossen Apostolov Herman J.C. Berendsen Par Bjelkmar
Aldert van Buuren Rudi van Drunen Anton Feenstra Sebastian Fritsch
Gerrit Groenhof Christoph Junghans Peter Kasson Carsten Kutzner
Per Larsson Justin A. Lemkul Magnus Lundborg Pieter Meulenhoff
Erik Marklund Teemu Murtola Szilard Pall Sander Pronk
Roland Schulz Alexey Shvetsov Michael Shirts Alfons Sijbers
Peter Tieleman Christian Wennberg Maarten Wolf
and the project leaders:
Mark Abraham, Berk Hess, Erik Lindahl, and David van der Spoel

Copyright (c) 1991-2000, University of Groningen, The Netherlands.
Copyright (c) 2001-2014, The GROMACS development team at
Uppsala University, Stockholm University and
the Royal Institute of Technology, Sweden.
check out http://www.gromacs.org for more information.

GROMACS is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License
as published by the Free Software Foundation; either version 2.1
of the License, or (at your option) any later version.

GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2
Executable: C:\ProgramData\BOINC\slots\1\projects\www.gpugrid.net\mdrun-502-902-avx-64.exe
Library dir: C:\Program Files\Gromacs\share\gromacs\top
Command line:
mdrun-502-902-avx-64 -ntomp 4 -nt 4 -x traj.xtc -s topol.tpr -g progress.log -cpi state.cpt

Reading file topol.tpr, VERSION 4.6.1 (single precision)
Note: file tpx version 83, software tpx version 100
Changing nstlist from 10 to 20, rlist from 0.9 to 0.928

Astiesan wrote:

Is the time estimate for these work units incorrect?

Also, my other AVX-capable machine only downloads SSE2 WUs, not AVX.

Does it take a while for the program to start using all 4 of the cores?

I'm using the mdrun-502-902-avx-64.exe program and it should be running on 4 cores but its only running on one core. Task manager says its only using 27% cpu, so about 1 core. I also tested multithreading with the only other MT app I can think of, Milkyway N-Body Simulation, and it runs about 80-85% of the total cpu's (all 4 cpus). I've reset and removed and reattached the project, and it still uses only 1 core. There are no other programs taking heavy compute cycles in the background.

So the mdrun-502-902-avx-64.exe program is tying up 4 cores but it is only using one core (about 27%). However, if I use 1 core (refreshing the GPUGrid account on BOINC Manager telling it to use 1 core) it uses the same amount of cpu (27% according to task manager) but the time estimate quadruples and the progress is markedly slower. I don't get it. Its obvious that it isn't using 4 cores when it is supposed to... I would expect AVX running on 4 cores would be moderately warm or hot running. Even process explorer reports only about 26 to 27% cpu usage.

Install Process Explorer. Find the process that is running the task. Double click it. Click the Threads tab. Sort that Threads tab by CPU descending.

If it's running 4-threaded, then the Threads tab should show 4 threads utilizing some CPU.

What do you see there?

Install Process Explorer. Find the process that is running the task. Double click it. Click the Threads tab. Sort that Threads tab by CPU descending.

If it's running 4-threaded, then the Threads tab should show 4 threads utilizing some CPU.

What do you see there?

Sorry I literally killed the process without thinking about it. However, I did download another one and it is doing the exact same thing (using 3 threads, 24.8% cpu). The thread IDs have changed but they are still using the same start addresses:

mdrun-502-902-avx-64.exe!bwlzh_decompress_verbose+0x131ac

mdrun-502-902-avx-64.exe!bwlzh_decompress_verbose+0x12880

MSVCR100.dll!endthreadex+0x60

Yes estimates are incorrect.
With AVX 8 threads- the task will take a total ~16hr.

I also Googled AVX. I guess my AMD FX 8350 has it, but do I need to do anything to activate it?

After resetting the project, same thing happened. It says "using 8 threads", yet it only uses one (13% CPU usage).
The progres.txt file doesn't update at all after this:

Log file opened on Fri Oct 24 16:28:33 2014
Host: unknown pid: 5364 rank ID: 0 number of ranks: 1
GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2

GROMACS is written by:
Emile Apol Rossen Apostolov Herman J.C. Berendsen Par Bjelkmar
Aldert van Buuren Rudi van Drunen Anton Feenstra Sebastian Fritsch
Gerrit Groenhof Christoph Junghans Peter Kasson Carsten Kutzner
Per Larsson Justin A. Lemkul Magnus Lundborg Pieter Meulenhoff
Erik Marklund Teemu Murtola Szilard Pall Sander Pronk
Roland Schulz Alexey Shvetsov Michael Shirts Alfons Sijbers
Peter Tieleman Christian Wennberg Maarten Wolf
and the project leaders:
Mark Abraham, Berk Hess, Erik Lindahl, and David van der Spoel

Copyright (c) 1991-2000, University of Groningen, The Netherlands.
Copyright (c) 2001-2014, The GROMACS development team at
Uppsala University, Stockholm University and
the Royal Institute of Technology, Sweden.
check out http://www.gromacs.org for more information.

GROMACS is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License
as published by the Free Software Foundation; either version 2.1
of the License, or (at your option) any later version.

GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2
Executable: D:\ProgramData\BOINC\slots\0\projects\www.gpugrid.net\mdrun-502-902-avx-64.exe
Library dir: C:\Program Files\Gromacs\share\gromacs\top
Command line:
mdrun-502-902-avx-64 -ntomp 8 -nt 8 -x traj.xtc -s topol.tpr -g progress.log -cpi state.cpt

Gromacs version: VERSION 5.0.2
Precision: single
Memory model: 64 bit
MPI library: thread_mpi
OpenMP support: enabled
GPU support: disabled
invsqrt routine: gmx_software_invsqrt(x)
SIMD instructions: AVX_256
FFT library: fftw3
RDTSCP usage: enabled
C++11 compilation: disabled
TNG support: enabled
Tracing support: disabled
Built on: Unknown date
Built by: Anonymous@unknown [CMAKE]
Build OS/arch: Windows-6.1 AMD64
Build CPU vendor: GenuineIntel
Build CPU brand: Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz
Build CPU family: 6 Model: 42 Stepping: 7
Build CPU features: apic clfsh cmov cx8 lahf_lm mmx msr pse rdtscp sse2 sse3 ssse3
C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe MSVC 16.0.30319.1
C compiler flags: /arch:AVX /DWIN32 /D_WINDOWS /W3 /MD /O2 /Ob2 /D NDEBUG
C++ compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe MSVC 16.0.30319.1
C++ compiler flags: /arch:AVX /DWIN32 /D_WINDOWS /W3 /GR /EHsc /wd4800 /wd4355 /wd4996 /wd4305 /wd4244 /wd4101 /wd4267 /wd4090 /MD /O2 /Ob2 /D NDEBUG
Boost version: 1.55.0 (internal)



++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
B. Hess and C. Kutzner and D. van der Spoel and E. Lindahl
GROMACS 4: Algorithms for highly efficient, load-balanced, and scalable
molecular simulation
J. Chem. Theory Comput. 4 (2008) pp. 435-447
-------- -------- --- Thank You --- -------- --------


++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
D. van der Spoel, E. Lindahl, B. Hess, G. Groenhof, A. E. Mark and H. J. C.
Berendsen
GROMACS: Fast, Flexible and Free
J. Comp. Chem. 26 (2005) pp. 1701-1719
-------- -------- --- Thank You --- -------- --------


++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
E. Lindahl and B. Hess and D. van der Spoel
GROMACS 3.0: A package for molecular simulation and trajectory analysis
J. Mol. Mod. 7 (2001) pp. 306-317
-------- -------- --- Thank You --- -------- --------


++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
H. J. C. Berendsen, D. van der Spoel and R. van Drunen
GROMACS: A message-passing parallel molecular dynamics implementation
Comp. Phys. Comm. 91 (1995) pp. 43-56
-------- -------- --- Thank You --- -------- --------

Changing nstlist from 10 to 20, rlist from 0.9 to 0.928

Input Parameters:
integrator = md-vv
tinit = 0
dt = 0.002
nsteps = 5000000
init-step = 0
simulation-part = 1
comm-mode = Linear
nstcomm = 100
bd-fric = 0
ld-seed = 1993
emtol = 10
emstep = 0.01
niter = 20
fcstep = 0
nstcgsteep = 1000
nbfgscorr = 10
rtpi = 0.05
nstxout = 0
nstvout = 0
nstfout = 0
nstlog = 1000
nstcalcenergy = 100
nstenergy = 1000
nstxout-compressed = 25000
compressed-x-precision = 1000
cutoff-scheme = Verlet
nstlist = 20
ns-type = Grid
pbc = xyz
periodic-molecules = FALSE
verlet-buffer-tolerance = 0.005
rlist = 0.928
rlistlong = 0.928
nstcalclr = 10
coulombtype = PME
coulomb-modifier = Potential-shift
rcoulomb-switch = 0
rcoulomb = 0.9
epsilon-r = 1
epsilon-rf = inf
vdw-type = Cut-off
vdw-modifier = Potential-switch
rvdw-switch = 0.75
rvdw = 0.9
DispCorr = No
table-extension = 1
fourierspacing = 0.1
fourier-nx = 64
fourier-ny = 64
fourier-nz = 64
pme-order = 4
ewald-rtol = 1e-005
ewald-rtol-lj = 1e-005
lj-pme-comb-rule = Geometric
ewald-geometry = 0
epsilon-surface = 0
implicit-solvent = No
gb-algorithm = Still
nstgbradii = 1
rgbradii = 1
gb-epsilon-solvent = 80
gb-saltconc = 0
gb-obc-alpha = 1
gb-obc-beta = 0.8
gb-obc-gamma = 4.85
gb-dielectric-offset = 0.009
sa-algorithm = Ace-approximation
sa-surface-tension = 2.05016
tcoupl = Nose-Hoover
nsttcouple = 10
nh-chain-length = 10
print-nose-hoover-chain-variables = FALSE
pcoupl = No
pcoupltype = Isotropic
nstpcouple = -1
tau-p = 1
compressibility (3x3):
compressibility[ 0]={0.00000e+000, 0.00000e+000, 0.00000e+000}
compressibility[ 1]={0.00000e+000, 0.00000e+000, 0.00000e+000}
compressibility[ 2]={0.00000e+000, 0.00000e+000, 0.00000e+000}
ref-p (3x3):
ref-p[ 0]={0.00000e+000, 0.00000e+000, 0.00000e+000}
ref-p[ 1]={0.00000e+000, 0.00000e+000, 0.00000e+000}
ref-p[ 2]={0.00000e+000, 0.00000e+000, 0.00000e+000}
refcoord-scaling = No
posres-com (3):
posres-com[0]=0.00000e+000
posres-com[1]=0.00000e+000
posres-com[2]=0.00000e+000
posres-comB (3):
posres-comB[0]=0.00000e+000
posres-comB[1]=0.00000e+000
posres-comB[2]=0.00000e+000
QMMM = FALSE
QMconstraints = 0
QMMMscheme = 0
MMChargeScaleFactor = 1
qm-opts:
ngQM = 0
constraint-algorithm = Shake
continuation = FALSE
Shake-SOR = FALSE
shake-tol = 0.0001
lincs-order = 4
lincs-iter = 1
lincs-warnangle = 30
nwall = 0
wall-type = 9-3
wall-r-linpot = -1
wall-atomtype[0] = -1
wall-atomtype[1] = -1
wall-density[0] = 0
wall-density[1] = 0
wall-ewald-zfac = 3
pull = no
rotation = FALSE
interactiveMD = FALSE
disre = No
disre-weighting = Conservative
disre-mixed = FALSE
dr-fc = 1000
dr-tau = 0
nstdisreout = 100
orire-fc = 0
orire-tau = 0
nstorireout = 100
free-energy = no
cos-acceleration = 0
deform (3x3):
deform[ 0]={0.00000e+000, 0.00000e+000, 0.00000e+000}
deform[ 1]={0.00000e+000, 0.00000e+000, 0.00000e+000}
deform[ 2]={0.00000e+000, 0.00000e+000, 0.00000e+000}
simulated-tempering = FALSE
E-x:
n = 0
E-xt:
n = 0
E-y:
n = 0
E-yt:
n = 0
E-z:
n = 0
E-zt:
n = 0
swapcoords = no
adress = FALSE
userint1 = 0
userint2 = 0
userint3 = 0
userint4 = 0
userreal1 = 0
userreal2 = 0
userreal3 = 0
userreal4 = 0
grpopts:
nrdf: 48414
ref-t: 300
tau-t: 0.8
annealing: No
annealing-npoints: 0
acc: 0 0 0
nfreeze: N N N
energygrp-flags[ 0]: 0

BOINC wrapper for GROMACS.
Arg 0 [projects/www.gpugrid.net/mdrun-502-902-avx-64.exe]
Arg 1 [--nthreads]
Arg 2 [8]
BOINC running with [8] threads
BOINC resolving [traj.xtc] to [traj.xtc]
BOINC resolving [topol.tpr] to [topol.tpr]
BOINC resolving [progress.log] to [progress.log]
BOINC resolving [state.cpt] to [state.cpt]
GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2

GROMACS is written by:
Emile Apol Rossen Apostolov Herman J.C. Berendsen Par Bjelkmar
Aldert van Buuren Rudi van Drunen Anton Feenstra Sebastian Fritsch
Gerrit Groenhof Christoph Junghans Peter Kasson Carsten Kutzner
Per Larsson Justin A. Lemkul Magnus Lundborg Pieter Meulenhoff
Erik Marklund Teemu Murtola Szilard Pall Sander Pronk
Roland Schulz Alexey Shvetsov Michael Shirts Alfons Sijbers
Peter Tieleman Christian Wennberg Maarten Wolf
and the project leaders:
Mark Abraham, Berk Hess, Erik Lindahl, and David van der Spoel

Copyright (c) 1991-2000, University of Groningen, The Netherlands.
Copyright (c) 2001-2014, The GROMACS development team at
Uppsala University, Stockholm University and
the Royal Institute of Technology, Sweden.
check out http://www.gromacs.org for more information.

GROMACS is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License
as published by the Free Software Foundation; either version 2.1
of the License, or (at your option) any later version.

GROMACS: mdrun-502-902-avx-64, VERSION 5.0.2
Executable: D:\ProgramData\BOINC\slots\0\projects\www.gpugrid.net\mdrun-502-902-avx-64.exe
Library dir: C:\Program Files\Gromacs\share\gromacs\top
Command line:
mdrun-502-902-avx-64 -ntomp 8 -nt 8 -x traj.xtc -s topol.tpr -g progress.log -cpi state.cpt

Reading file topol.tpr, VERSION 4.6.1 (single precision)
Note: file tpx version 83, software tpx version 100
Changing nstlist from 10 to 20, rlist from 0.9 to 0.928

After resetting the project, same thing happened. It says "using 8 threads", yet it only uses one (13% CPU usage).
The progres.txt file doesn't update at all after this:

Yes estimates are incorrect.
With AVX 8 threads- the task will take a total ~16hr.

I've been though this thread. I installed BOINC 7.4.22 and the estimated remaining time dropped dramatically.

I also Googled AVX. I guess my AMD FX 8350 has it, but do I need to do anything to activate it?

How many hours for AVX 4 threads? In 24 hours I only did 20%.

After resetting the project, same thing happened. It says "using 8 threads", yet it only uses one (13% CPU usage).
The progres.txt file doesn't update at all after this:

Excellent point... I couldn't remember how often the progress.log file updates after the program starts. Like workunits do for some other projects, I figured it has some preliminary work to do before started really crunching with all threads. I thought it was a problem with my computer. It doesn't seem like the program is spinning up enough threads.

And reviewing the older MT tasks I've crunched there is usually a note in stderr.txt or progress.log that mentions running 1 MPI thread and 4 OpenMP threads. I don't see the same note using the AVX program. Perhaps its something very simple like a missing command line argument?

Are CPUMD SSE2/4 tasks being sent to AVX hosts?

Are CPUMD SSE2/4 tasks being sent to AVX hosts?

I keep getting CPU WUs (that don't work...) even though I unchecked the "Use CPU?" in the setting page for GPUGRID (along with unchecking everything BUT ACEMD LONG RUNS). If the AVX WU problem is not fixed or the whole not-obeying the settings thing, then I'm going to be forced to detach the project entirely (I don't want to play cop and manually abort the CPU WUs that are bugged, it defeats the whole set-it-and-forget-it purpose of BOINC...).
____________

does it work for pricese puppy 5.7? I do not get any WUs. Thanks.

Who is Princess Puppy?

Does anybody else have unusually high Task duration correction for GPUGRID since computing or downloading a MDCPU task?

Since I've completed or downloaded a CPUMD task-- GPUGRID Task duration correction factor (9.829525) has sky rocketed. Other Projects are have the correct factor number and task estimates are within normal ranges for CPU/GPU completion times.
Currently there is no CPUMD tasks running or in cache while factor has stayed the same. I just downloaded a new GPU task and the estimate time is at 370Hr.(All CPU/GPU task from GPUGRID are abnormal estimates for a week or so) 7.4.21 Client reverting task factor to the proper number isn't happening (re-setting/letting all tasks in cache finish/completing 10 GPU tasks since)
What is causing the continuation of high correction factors?

Also- Will future MD tasks have GPU support enabled?

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

The buggy Windows AVX app is gone now. Please abort any instances of it still running. It's replaced with the working SSE2 app.