Problem with per-app DCF
Nicolas Alvarez
http://code.google.com/p/synecdoche/source/detail?r=1350
The main issue I see is that we're not sending a DCF in scheduler requests
anymore, so the server cannot use it to better estimate how long tasks will
take, when deciding whether the client will finish in time. That is,
assuming the server ignores a missing DCF and performs no duration
correction...
In practice it's even worse than that. I just found in the server code that
a missing <duration_correction_factor> tag will just leave the variable at
0.0, which is then clamped up to 0.1. It doesn't use a default of 1.0.
So BOINC servers think Synecdoche r1350 does work 10 times slower than
reality, and will send less work accordingly.
I just posted to boinc_dev reporting the server issue, but obviously we
can't rely on the server fix being there (if it gets fixed at all).
For now, I suggest that we revert this change. and if we want to keep trying
to implement this, continue in a "feature branch" instead of trunk.
Synecdoche trunk has been usually stable, and I think getting 1/10th of the
work isn't quite that. Doing it in a branch would also make things easier if
we decide we're in a dead-end: just don't merge it back.
--
Nicolas
(I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.)