Are the Nvidias munching steadily or are they pausing at 89% and jumping to 100% after a couple of minutes?
...
The behaviour on my NVIDIA rigs has not changed for "years".
But the length of the pause seems to depend on various/many "factors".
It seems to be a mix of the type of CPU, GPU and the load/burden of the whole system.
I.e., my GTX750Ti rig needs max. 2 (two) seconds to snap from 89 to 100.
The most time is needed by my Titan X(p), but not minutes. Around max. 50 seconds.
I also noticed different "snap times" for the same GPU-type, depending on if the GPU is also using the monitor, the amount of board memory and of the "speed" the CPU and/or the GPU has.
To me, this all seems somewhat logical and is my personal experience and opinion.
There is a thread/post somewhere, as I remember, explaining what GR is doing in this "snap-time" period.
I also saw that explanation - IIRC, the pause happens when the GPU part of the computation has finished, and the results have to be consolidated into a reportable form. This can only be done on the CPU, and the duration of the pause depends more on the CPU - how busy it is, and how powerful. The tasks also vary in the amount of post-processing they need - the ones I've been checking this morning seem to be finishing particularly quickly.
The latest batch of tasks seem to take a couple of hundred seconds longer to crunch (on GPU) than the previous batch.
... tasks with task names starting: LATeah4011L00 are taking substantially longer ...
We've seen it all before.
3 Months ago (March 18 to be precise) we had a new data file LATeah4001L00.dat delivered to replace the previous LATeah3nnnLnn.dat series. It lasted about a week before there was a return to more of the previous LATeah3 series. The crunch characteristics of LATeah4 tasks at that time were pretty much the same as now - around 30% longer elapsed times and a 'follow-up' stage after the main GPU crunching had concluded of no more than 3-4 secs.
So it appears to be just a case of 'deja vu' and it may be that the same thing might happen again, ie, the current slower variety mightn't last all that long.
Make sure you enjoy them while they last! :-).
EDIT: In case anyone is interested, here is a dated listing (UTC +10 times) showing file sizes in bytes and when first received by any one of my hosts. I cache these files and deploy to all in order to save bandwidth. Note that the two '4' series data files have exactly the same size so it's reasonable to assume there would be very similar behaviour.
EDIT2: Worked out how to get rid of extra spurious stuff at line endings of pasted content.
[gary@eros eah_files]$ ls -l LATeah[34]*
-rw-r--r-- 7 gary gary 3218712 Jan 22 05:41 LATeah3001L00.dat
-rw-r--r-- 7 gary gary 3218712 Feb 2 14:40 LATeah3001L01.dat
-rw-r--r-- 7 gary gary 3218712 Feb 5 05:37 LATeah3002L00.dat
-rw-r--r-- 7 gary gary 3218712 Feb 10 17:37 LATeah3002L01.dat
-rw-r--r-- 7 gary gary 3218712 Feb 18 05:37 LATeah3002L02.dat
-rw-r--r-- 7 gary gary 3218712 Feb 21 12:37 LATeah3002L03.dat
-rw-r--r-- 7 gary gary 2765533 Feb 25 05:40 LATeah3003L00.dat
-rw-r--r-- 7 gary gary 2765533 Mar 3 18:31 LATeah3003L01.dat
-rw-r--r-- 7 gary gary 2765533 Mar 10 17:37 LATeah3003L02.dat
-rw-r--r-- 7 gary gary 2765533 Mar 29 16:38 LATeah3003L03.dat
-rw-r--r-- 7 gary gary 2765533 Apr 1 15:38 LATeah3004L00.dat
-rw-r--r-- 7 gary gary 2765533 Apr 8 19:09 LATeah3004L01.dat
-rw-r--r-- 7 gary gary 2765533 Apr 16 05:50 LATeah3004L02.dat
-rw-r--r-- 7 gary gary 2765533 Apr 23 05:38 LATeah3004L03.dat
-rw-r--r-- 7 gary gary 2765533 Apr 27 13:21 LATeah3004L04.dat
-rw-r--r-- 7 gary gary 2765533 Apr 29 10:40 LATeah3004L05.dat
-rw-r--r-- 7 gary gary 2765533 May 2 06:02 LATeah3011L00.dat
-rw-r--r-- 7 gary gary 2765533 May 29 12:38 LATeah3011L01.dat
-rw-r--r-- 7 gary gary 2765533 Jun 15 05:39 LATeah3011L02.dat
-rw-r--r-- 7 gary gary 1221859 Mar 18 05:37 LATeah4001L00.dat
-rw-r--r-- 7 gary gary 1221859 Jun 26 18:40 LATeah4011L00.dat
[gary@eros eah_files]$
As far as I can recall, NV
)
As far as I can recall, NV GPUs always paused at 89.xx% then jump to 100. Still do here, on my 980s.
Tom M wrote: ... Are the
)
The behaviour on my NVIDIA rigs has not changed for "years".
But the length of the pause seems to depend on various/many "factors".
It seems to be a mix of the type of CPU, GPU and the load/burden of the whole system.
I.e., my GTX750Ti rig needs max. 2 (two) seconds to snap from 89 to 100.
The most time is needed by my Titan X(p), but not minutes. Around max. 50 seconds.
I also noticed different "snap times" for the same GPU-type, depending on if the GPU is also using the monitor, the amount of board memory and of the "speed" the CPU and/or the GPU has.
To me, this all seems somewhat logical and is my personal experience and opinion.
There is a thread/post somewhere, as I remember, explaining what GR is doing in this "snap-time" period.
Have a nice Sunday Tom!
I also saw that explanation -
)
I also saw that explanation - IIRC, the pause happens when the GPU part of the computation has finished, and the results have to be consolidated into a reportable form. This can only be done on the CPU, and the duration of the pause depends more on the CPU - how busy it is, and how powerful. The tasks also vary in the amount of post-processing they need - the ones I've been checking this morning seem to be finishing particularly quickly.
The latest batch of tasks
)
The latest batch of tasks seem to take a couple of hundred seconds longer to crunch (on GPU) than the previous batch.
Harri Liljeroos wrote:The
)
I agree that on more than one of my machines GPU GRP tasks with task names starting:
LATeah4011L00
are taking substantially longer elapsed time to complete than the immediately preceding:
LATeah3011L02
tasks did.
The LATeah4 work units take
)
The LATeah4 work units take 20% longer to complete than the LATeah3 work units. Perhaps there is just "more science" in them?
San-Fernando-Valley
)
This pinned post In Cruncher's Corner? https://einsteinathome.org/content/fgrp5-cpu-and-fgrpb1g-gpu-why-does-crunching-seem-pause-90
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht
)
Thank you for reminding me/us. I think what it gets down to is if your CPU is "busy" the "snap" time can be minutes instead of seconds.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor)
archae86 wrote:Harri
)
We've seen it all before.
3 Months ago (March 18 to be precise) we had a new data file LATeah4001L00.dat delivered to replace the previous LATeah3nnnLnn.dat series. It lasted about a week before there was a return to more of the previous LATeah3 series. The crunch characteristics of LATeah4 tasks at that time were pretty much the same as now - around 30% longer elapsed times and a 'follow-up' stage after the main GPU crunching had concluded of no more than 3-4 secs.
So it appears to be just a case of 'deja vu' and it may be that the same thing might happen again, ie, the current slower variety mightn't last all that long.
Make sure you enjoy them while they last! :-).
EDIT: In case anyone is interested, here is a dated listing (UTC +10 times) showing file sizes in bytes and when first received by any one of my hosts. I cache these files and deploy to all in order to save bandwidth. Note that the two '4' series data files have exactly the same size so it's reasonable to assume there would be very similar behaviour.
EDIT2: Worked out how to get rid of extra spurious stuff at line endings of pasted content.
[gary@eros eah_files]$ ls -l LATeah[34]* -rw-r--r-- 7 gary gary 3218712 Jan 22 05:41 LATeah3001L00.dat -rw-r--r-- 7 gary gary 3218712 Feb 2 14:40 LATeah3001L01.dat -rw-r--r-- 7 gary gary 3218712 Feb 5 05:37 LATeah3002L00.dat -rw-r--r-- 7 gary gary 3218712 Feb 10 17:37 LATeah3002L01.dat -rw-r--r-- 7 gary gary 3218712 Feb 18 05:37 LATeah3002L02.dat -rw-r--r-- 7 gary gary 3218712 Feb 21 12:37 LATeah3002L03.dat -rw-r--r-- 7 gary gary 2765533 Feb 25 05:40 LATeah3003L00.dat -rw-r--r-- 7 gary gary 2765533 Mar 3 18:31 LATeah3003L01.dat -rw-r--r-- 7 gary gary 2765533 Mar 10 17:37 LATeah3003L02.dat -rw-r--r-- 7 gary gary 2765533 Mar 29 16:38 LATeah3003L03.dat -rw-r--r-- 7 gary gary 2765533 Apr 1 15:38 LATeah3004L00.dat -rw-r--r-- 7 gary gary 2765533 Apr 8 19:09 LATeah3004L01.dat -rw-r--r-- 7 gary gary 2765533 Apr 16 05:50 LATeah3004L02.dat -rw-r--r-- 7 gary gary 2765533 Apr 23 05:38 LATeah3004L03.dat -rw-r--r-- 7 gary gary 2765533 Apr 27 13:21 LATeah3004L04.dat -rw-r--r-- 7 gary gary 2765533 Apr 29 10:40 LATeah3004L05.dat -rw-r--r-- 7 gary gary 2765533 May 2 06:02 LATeah3011L00.dat -rw-r--r-- 7 gary gary 2765533 May 29 12:38 LATeah3011L01.dat -rw-r--r-- 7 gary gary 2765533 Jun 15 05:39 LATeah3011L02.dat -rw-r--r-- 7 gary gary 1221859 Mar 18 05:37 LATeah4001L00.dat -rw-r--r-- 7 gary gary 1221859 Jun 26 18:40 LATeah4011L00.dat [gary@eros eah_files]$Cheers,
Gary.
If the tasks take 30% more
)
If the tasks take 30% more time shouldn't it give some more BOINC credits too?
Or is it hard to distinguish between the tasks regarding this?