Topics

Fred

in ver 2 to 2.3 when you rescedule from cpu to gpu the main screen does not update correctly for VHAR's


as i hope you can see the VHAR number under GPU is not updated correctly as well as the cpu vhar number

Fred

is there a limit on the size of the history

got an error this morning when opening BT (0.76) that history was too large - (10 days)

yes this machine has done a lot of tasks recently but was unaware of a limit

not a huge problem have reduced to 5 days now

Fred

i have disabled one of my GPU (via cc_config file) as running vlars on GPU (as have no other work) and it makes the pc very choppy if i run one on the GPU that i have a monitor attached to.

this made me notice something

in BT you number the GPU's d0, d1 etc

now i disabled GPU no 2 or NVIDIA GPU 1 as its called below

e.g.
28/09/2010 18:35:07      NVIDIA GPU 0: GeForce GTX 295 (driver version 25896, CUDA version 3010, compute capability 1.3, 878MB, 647 GFLOPS peak)
28/09/2010 18:35:07      NVIDIA GPU 1 (ignored by config): GeForce GTX 295 (driver version 25896, CUDA version 3010, compute capability 1.3, 877MB, 647 GFLOPS peak)
28/09/2010 18:35:07      NVIDIA GPU 2: GeForce GTX 295 (driver version 25896, CUDA version 3010, compute capability 1.3, 878MB, 647 GFLOPS peak)
28/09/2010 18:35:07      NVIDIA GPU 3: GeForce GTX 295 (driver version 25896, CUDA version 3010, compute capability 1.3, 878MB, 647 GFLOPS peak)

but in BT i have d0, d1??, d2 but not d3 as i was expecting to see d0, d2, d3

one final thing why d and not g? unless d means device?

Hi Fred

Had a problem today after a BSOD (was messing around doing Over Clock testing )

i lost all my history info for all my machines - not the end of the world i know but...

I guess BT holds these in memory until its closed (properly!) - if my guess is correct could it say write them to disk/make a backup say once an hour?

I did not appear to loose any of the message info or settings when my pc crashed

Fred

could you add a new column to the tasks tab to be able to see the received date for tasks

you have the info in the properties window but would be good to see in the task window as well

Thanks

T

Fred

would it be possible to write to the log file which wu's got rescheduled and what parameters were changed and why etc

and do this when the reschedule is committed i.e. we press run

this would give (if the file was structured correctly) an option to reverse the changes back if necessary

also could a new tab be added to list the wu to be modified and why or why not - i think this would be useful feed back

and if we had the option to exclude a file as well this would be good etc

Thanks

T

Fred

could i request a bit more info and possibly a modification to BRS

as i understand it if i check the Expert option Limit rsc_fpops_bounds to avoid -177 errors RS does the following( - should this not be called extend the bounds of rsc_fpops as that is what it will do )

BRS looks at rsc_fpops for each wu and replaces the <rsc_fpops_bound> value with 500000000000000000.000000 so that a wu cannot reach a point where it has not completed crunching before the bounds value is reached
not sure if it does this for all wu or just the ones it reschedules but i think it is causing boinc problems or its related

it appears to be that any wu that has been rescheduled then has inconsistent times to complete values which can vary wildly (based on the dcf as well)

as the wu's from seti before rescheduling have rsc_bounds 10 times larger than the rsc_fpops_est could we not use this estimate combined with say the fpops value in either the app info file (assuming its there) or put these values into RS so as the rsc_fpops_est will be wrong (too low) for cpu to gpu or (too high) for gpu to cpu and when boinc does its calcs this throws out the time to complete

this would allow more realistic estimates of the new bounds values and estimates to keep boinc happy - especially with the server side dcf for cpu, gpu and soon ap

with the new vlar policy its becoming less necessary to move work around for vlar reasons but being able to shuffle work between the cpu and gpu - especially in the outages is a very useful option

Hopefully i have explianed the above enough for you to follow what i am suggesting 

[est_ratio_cpu_max: 4.000000]

Fred

just noticed something in the log window it might be just cosmetic but...

From log window
est_ratio_cpu_min: 0.500000
est_ratio_cpu_max: 2.500000
est_ratio_gpu_min: 0.500000
est_ratio_cpu_max: 4.000000

from config file
<est_ratio_cpu_min>0.5</est_ratio_cpu_min>
<est_ratio_cpu_max>2.5</est_ratio_cpu_max>
<est_ratio_gpu_min>0.5</est_ratio_gpu_min>
<est_ratio_gpu_max>4.0</est_ratio_gpu_max>

as you can see the last line of the log window is incorrectly showing cpu rather than gpu

Fred

couple of ideas around the task tab

Could we have a double click event say in Status column so we could apply the filter options a bit more easily - as a toggle so first double click turns filter off then second double click turns it back on by status type of row clicked on? - reason is that you have to select on row before you can get to filter list - left click then right click navigate menu check/uncheck filter - laborious if want to change several filters in one session

second option have it so there is a "+" sign by a filter applied in status column and "-" when not applied - i.e. a bit like a listview of directory structure or something simple to click on an off

Anyway a couple of ideas as i usually have lots of tasks and use the filter options a lot

T

Fred

we have the option to put in ratios for cpu and gpu

whats the basis for these numbers so i can put the correct values in

you thread only show 0.5 to 1.5 for both

how do we decide what the values should be?

Thanks

Tim

Hi

with Milkyway reporting a lot of my CUDA wu appear as "missed" in the History log on both 0.62 and 0.66 when in fact they are not missed reporting - have checked on Milkyway site

it appears that for all of them (12)  if the wu is completed and reported at exactly the same time - boinctasks shows it as a "missed" status

also just checking it has done the same on three SETI wu as well - cant verify these but i never get close to a wu running out

other work units not with the same times are fine

is this a bug or am i missing something?

Cheers

Tim