Excellent news.

Ah, Keith, I see you are reading my mind !!! I was just going to ask the 'priority' question because I have both OET and FAHB selected on my machine, but only seeing OET WUs. Thanks for the info.

CJSL

Crunching for a brighter future...

OK, created a query map from your second day xml import.

WEB
1
https://secure.worldcommunitygrid.org/stat/vi...amp;projectShortName=fahb

Selection=EntirePage
Formatting=None
PreFormattedTextToColumns=True
ConsecutiveDelimitersAsOne=True
SingleBlockTextImport=True
DisableDateRecognition=True
DisableRedirections=True

All needs doing now is create a copy of the mapping file rahter than starting from scratch, change the ShortName tag and import this. Office was happy to accept this [in a one time test]. Will know on next project launch if this works or falls over, doubt it though as the exported map does not seem to include the tags, just says EntirePage.

[/osot]

There's various dynamic control values that are used to every so many seconds recompute if the total work in buffer will be completed in time. Either your buffer is too high or the control values have degraded <on_frac> and or <active_frac>. For a 24/7 machine they would be near 0.999999. Part time devices have a lower value. For instance if 0.5 [12 hours a day] and your buffer is worth 2 full days computing, BOINC computes 2 / 0.5 is 4 calendar days needed. At that point you get "Tasks won't finish in time:..." for FAHB. The value degrades rapidly if e.g. powering off Friday and then restart on Monday and increases slowly again. It can take 10 days continuous crunching to get it back to 0.999999. On the other hand if your have a stable computing pattern, BOINC will automatically reduce the amount of work buffered.

At any rate, let it run and things will balance over time.

Edit: Theoretically the write down of the On/Active fraction values does not happen if a client is off for longer than 10 days. My Linux host with 7.4 client usually starts off with getting just enough to get all cores busy when launched after one month off and then slowly gets more the longer it is left on.

There are known instances where 64 bit compiles are slower than 32 bit. If that was found in the case of BEDAM, why waste time on compiling 64 bit? OTOH, by having 32 bit only you get a more consistent result series. OTOH to the OTOH, there's as I understood no platform tying, homogeneity concern for FAHB i.e. one task can run on windows and the next in the series can run on Mac or Linux, which overturns the 32 bit point again as then 32bit generated steps can be concatenated with 64 bit Linux (and probably Mac too, think that's what it says on the system requirement page). I.e. there's a reason but not one Spock could logically reason without more input, Jim ;P)