Messages

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

Yep i am getting crashes too with 0.79 on Win7 64 bit

first time i had noticed BT crash before and just checked my dump files and only four

two from today where had two icons in the task bar - BT would not close from the main menu or the system tray

had to manually kill with task manager although took a couple of goes to work

do you want the dump files even rar'd the smallest is 24meg in size

can put them on dropbox and send you the link if thats easier?

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

no problem for me (0.76)

simply as i had nothing left but vlars so wanted my GPU's to crunch something while waiting and had loooooots of vlars

sorry Fred it appears that Boinc Manager renumbers them!!!

if you use properties of task in BM it show d0, d1 or d2 not d0, d2 and d3 (d for device)

oh well not much we can do about that

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

  

ah that would possible explain why i was struggling to understand some of the calcs and effects!

Great looking forward to V2

T

Fred

sorry i am happy to work out how to roll back just need the info to do it and see what is happening

was not asking for you to add the roll back in 

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 

Sorry should have said this is v1.6

[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