Forum > Discussion Forum

BOINC 6.10.58 incorrect running time estimation

<< < (2/4) > >>

Raistmer:

--- Quote from: Claggy on 08 Feb 2012, 09:00:37 am ---Eithier bother DA or Eric to fix the server side Estimates for Anonymous Platform users that aren't using flops entries,

or put flops into your app_info (use the APR figure with e09 at the end), eg 17.686758629915e09 for CPU MB  app & 255.03870331506e09 for Nvidia GPU MB app,

or use Jason's 6.10.58 boinc.exe,

Claggy

--- End quote ---
Hehe, I think it will more bother me than them so I skip directly to local methods ;)

Raistmer:

--- Quote from: Richard Haselgrove on 08 Feb 2012, 11:24:06 am ---
--- Quote from: Raistmer on 08 Feb 2012, 08:25:00 am ---On my  NV host newly recived GPU tasks always get time estimation ~2h (just as CPU ones) though real elapsed time ~30 minutes or less.
In the past I ran re-scheduler on this host but it was not running few months (!) already.
And estimation time still hugely incorrect.
It prevents host from downloading enough work to allow running with disabled network for statistic collection...

Please, any advices how it can be fixed w/o BOINC upgrade?

--- End quote ---

That's not a client issue - it's the result of server changeset 24128, much discussed on the SETI message boards since 05 September 2011.

Options are:

* Only run one application type at a time (probably advisable for statistical collection anyway)
* Populate app_info with appropriate <flops> values for every app specified
* Use Jason's aDCF client variant
* Join us in lobbying DA and SETI staff to restore the server configuration to documented operating mode - safely
--- End quote ---
Ok, I use Jason's build at ATi host so will transfer executable there too.... It's very irritating to not get such basics things work correctly... work cache is really one of the basic BOINC's functions  :-\

And about any limitation in app types usage for statistics - no, I measure real-life performance so better to get all mixes... That host runs only one MB GPU task at once anyway so AP and MB wull not bother each other...
My ATi host from other dside running 3 at once - here MV/AP mixes are possible indeed...

Josef W. Segur:

--- Quote from: Mike on 08 Feb 2012, 09:05:05 am ---I have the same issue with GPU times ETA since i removed flops entry.
So long i get enough work i dont care.
But its funny at least.
I remember Joe telling me at main it will correct itself.
Maybe in 100 years.

Mike
--- End quote ---

Not in any amount of time now. BOINC changeset 24128 as revised by 24217 mean that if your host is telling the servers the app is less than 1/10 it's actual speed, the situation cannot correct itself. And if you don't specify <flops> in app_info.xml, the core client does a "conservative" estimate based on the notion that the Whetstone benchmark is peak FLOPS for the CPU and a GPU might actually be slower than a CPU.

Added note: Those assumptions underlying the estimate may be true at some other project, either now or in the future. IOW, I don't expect them to change. Similarly, the 1/10 factor in changeset 24217 applies to all projects which allow anonymous platform, so getting that changed to better suit S@H may not be likely.
                                                            Joe

Richard Haselgrove:
But we got David to write http://boinc.berkeley.edu/trac/changeset/24225/boinc (and bugfixes) specifically "for applications like SETI@home", as a more scientific and targeted approach to solving Claggy's presenting problem.

If we could get the project to adopt that code as intended, there would be no need for the crude, blunderbuss, APR capping.

Jason G:

--- Quote from: Raistmer on 08 Feb 2012, 11:36:06 am ---.... It's very irritating to not get such basics things work correctly... work cache is really one of the basic BOINC's functions  :-\ ...
--- End quote ---

In principle I agree, even though in computer science such scheduling/logistics problems are techniically condidered 'NP-Hard' meaning they can't be solved 'optimally' by machine in reasonable/finite time.  The usual approaches to coming to an acceptable answer are to settle on some  'near enough' acceptable answer using heuristics (i.e. human logic) which is time proven and can be effective.  Unfortunately there seems to be some disparity between what Boinc devs & end users consider acceptable, and that Boinc devs can think like humans is debatable  :D

Jason

Navigation

[0] Message Index

[#] Next page

[*] Previous page