And of course the cache size to allow for at least 12 hours to cover maintenance. This can be check by turn around time/consecutive valids. If a computer is returning tasks at a fast rate and reliable rate, give them more. This could be calculated something like the greater of 100 OR 100/TurnAroundTime. Slow computers would still get 100 (100/10d==100 tasks), and fast computers (100/0.2d=500 tasks). The 100 value could be modified so that everyone has the same cache size (in days).

This is a project specific item, not a BOINC general one. Each project can either set a limit on the number of tasks allowed (as SETI has done), or use a expect run time based cache as many other projects do.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

This is a project specific item, not a BOINC general one. Each project can either set a limit on the number of tasks allowed (as SETI has done), or use a expect run time based cache as many other projects do.

Yes, I understand that this is a project specific setting. But if the option was included in the server source code to easily implement such a system, more projects might use it (or similar) rather than just a default number of tasks.

And of course the cache size to allow for at least 12 hours to cover maintenance. This can be check by turn around time/consecutive valids. If a computer is returning tasks at a fast rate and reliable rate, give them more. This could be calculated something like the greater of 100 OR 100/TurnAroundTime. Slow computers would still get 100 (100/10d==100 tasks), and fast computers (100/0.2d=500 tasks). The 100 value could be modified so that everyone has the same cache size (in days).

This is a project specific item, not a BOINC general one. Each project can either set a limit on the number of tasks allowed (as SETI has done), or use a expect run time based cache as many other projects do.

Which actually causes me a problem.

Cache size - "Store at least --- days of work", and the same for additional - is a global preference, common across all projects. I use the same GPUs for GPUGrid and SETI.

GPUGrid likes to have work completed and returned within 24 hours - and tasks are currently running for about 15 of those 24 hours. I've settled on a cache which allows GPUGrid to fetch new work when about 3 hours remains on the current task - that seems to work.

But SETI needs at least a 12 hour cache every Tuesday... At the moment, I'm manually overfetching every Tuesday morning, then trying to remember to set everything back to normal after the outage has started.

The option is already there, and the majority of projects use the "time based" cache.
It's just that some, as Richard has described, abuse the deadlines so making any meaningful cache control a waste of time and effort.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

The option is already there, and the majority of projects use the "time based" cache.
It's just that some, as Richard has described, abuse the deadlines so making any meaningful cache control a waste of time and effort.

It's the science which abuses the deadlines. SETI can allow relaxed deadlines, because any contact with ET is bound to take place over a timescale of years, possibly centuries. And as astronomer-in-charge, Eric chooses to allow users of slower devices - such as Android phones, only able to crunch when charging back at base - to participate in the project.

But GPUGrid is running huge biochemical simulations, in competition with other research groups around the world. If they don't get their data back pronto, they'll lose their chance to publish.

Something Jason G has mentioned in the past- more flexible Computing Resource allocation.

Presently we have CPU and GPU processing, and with the advent of USB Type C and Thunderbolt interfaces the possibility of "Other" Computing Resources.
Also the present Manager is able to select the most efficient (fastest) application out of several candidates (although the mechanism needs work. On Beta on one run I ended up with the slowest application being selected due to the work that was allocated to each application while it was determining which was fastest - CUDA42 got almost all Arecibo mid range and shorty work , SoG almost all GBT WUs or Arecibo VLARs so CUDA42 looked like it was the fastest).
On Seti, due to issues with older applications & older Nvidia hardware, Arecibo VLARs were blocked from going to all NVidia hardware. However with current highend hardware & the SoG application Arecibo VLARs can be run without issues.


Under the present system when work is downloaded, it is allocated to either CPU, GPU, or Other (when it becomes available). Yet with Seti, GBT work is processed much faster on the CPU than much of the Arecibo work, Arecibo work is processed much faster on the GPU than GBT work.
It would be best if the work was able to be downloaded & allocated dynamically to the Computing Resource most able to process it. It would also be good of there were project settings that allowed those that feel the need to allocate work to certain resources to be able to do so. eg systems with highend NVidia hardware capable of handling Arecibo VLARs without issue can opt to accept it for GPU processing, yet it remains blocked by default for all others.

By default, the Manager will allocate work to the most capable Computing Resource. Given cache settings, server side limits, turn around times & WU deadlines etc, etc if a particular Computing Resource has reached it's cache limit, then new work downloaded will be allocated to the next most capable Computing Resource, down the line, till all such Computing Resources have reached their limits. As work is processed and returned, work is re-allocated to the most capable Computing Resource, and new work received from the servers allocated to the most capable, next most capable & so on till all Computing Resources have once again reached their set limits.

I agree with Grant's proposal. this is exactly the mechanism that should be put in place. I have to do a lot of manual intervention to accomplish the same goals for my resources. It would be best if the project handled that automatically.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

In the category of mild annoyances, it sure would be nice to dispense with that "finish file present too long" feature. I know it's been brought up and discussed many times before, so hopefully it's already on the list, but it really does irritate me when a task finishes successfully only to have the time and resources expended on it thrown away by BOINC.

Well Nitpicker is dead and we now have Nebula at the Atlas cluster, but the principle was sound, give the heavy work to the machines that can deal with it. It means of course generating two types of workunit, credit would need to be apportioned on flops applied etc not on simple time taken. High end m/c 's wouldn't run out of work on Tuesdays either!

All doable by having BOINC manage Computing Resources as a whole, and not having CPU, GPU and "other" being considered different & separate.

---

Grant
Darwin NT

...Which assumes that the science project has the capability, or desire, to produce a whole suite of applications for all known combinations of CPU/GPU/OS.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Detection and blocking of "rogue hosts" - those that are returning a high proportion of "invalid", "error" results, those demanding improbably high numbers of tasks when compared with their rate of return of "valid" results (this would require a mechanism to cope with new and updated hosts).

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Do the limits of download and upload rate settings serve any useful purpose?

I think they do, however I do not use them. Having a 5Mb/s download and 4 computers, if I were one to constantly watch YouTube videos or streaming it would be useful to limit the bandwidth BOINC use to not affect streaming as much.

...Which assumes that the science project has the capability, or desire, to produce a whole suite of applications for all known combinations of CPU/GPU/OS.

Not necessarily. The decision tree would some something like:

"Here is a task. You have applications A, B, C, D, E. Applications B, D and E are capable of running this task, but A and C are not. Pick whichever of B, D, or E you like to run it, whatever hardware they run on."

From the server side, that should be (relatively) easy to do - including the corollary, "Here is a task, but none of your apps can run it, so I'm not going to send it to you."

The difficulty comes for the client juggling multiple local queues, including multiple apps for the same hardware (SoG or CUDA?). I for one don't want to program that, to the satisfaction of every user - the matrix of preferences alone would be horrendous.

But all that is way, way beyond the current scope of these threads (currently on 12 different BOINC projects). Our first goal is to sort out the management structure of BOINC, the organisation. Then to sort out the repository structure of BOINC, the software source code - so that multiple developers can work simultaneously. Then to recruit those multiple (probably volunteer - we have no money for this) developers. Then show those developers the list of ideas which have been harvested from these lists (thank you), and stand well back while they get on with it.

Do the limits of download and upload rate settings serve any useful purpose?

I think they do, however I do not use them. Having a 5Mb/s download and 4 computers, if I were one to constantly watch YouTube videos or streaming it would be useful to limit the bandwidth BOINC use to not affect streaming as much.

And if your laptop moved from place to place, sometimes using a metered connection, sometimes not. As Microsoft does with Windows 10 updates.

Maybe we need a "messages" area for SmartPhones aka Android?

I know we have OS specific message areas for Windows, Mac, Linux and Gpu questions as well as some more generic general questions. I think we may need a smartphone message area.

I have been watching my smartphone painfully munch through its tasks I I want to know where the "app_config.xml" file is :)

Tom

---

A proud member of the OFA (Old Farts Association).

Maybe we need a "messages" area for SmartPhones aka Android?

What and where do you mean by a "messages area", in this context?

What and where do you mean by a "messages area", in this context?

A Q&A forum... though technically Android is a Linux derivative.

---

Maybe we need a "messages" area for SmartPhones aka Android?

I know we have OS specific message areas for Windows, Mac, Linux and Gpu questions as well as some more generic general questions. I think we may need a smartphone message area.

I have been watching my smartphone painfully munch through its tasks I I want to know where the "app_config.xml" file is :)

Tom

When viewing your running Tasks in the Android app, Touch the 3 bars icon before the word Tasks and scroll up the menu that appears. Event Log is the last item.

What and where do you mean by a "messages area", in this context?

A Q&A forum... though technically Android is a Linux derivative.

Ah. The BOINC software would allow Eric to create that - nothing needed in this thread.

Just ask him - I know Eric is an Android enthusiast (in that he wants to provide supported applications for this project).

...Social media in the client is not needed in my eyes; and for example for me more discouraging to connect. No need to Facebook or Twitter to be connected to BOINC in my eyes. Again open that to 3rd parties who might see a benefit, ok.

God no, please. Just No. Please.

---

(2) To open the "credits" can of worms... let the "new, improved, BOINC" take on the credit award process and -NOT- leave it to the individual projects. Whatever the credit basis, whether gigaflops or elapsed time or some other metric, it would at least be uniform across projects and mitigate the (scientifically) meaningless competition for more "credit."

This. To allow meaningful comparisons of testing parameter changes to accurately reflect if said change had a positive or negative effect on output in the real world environment, and not some random figure as it appears it is now. And yes, hopefully it will kill the e-peen competition/arms race between projects as well, that would be a welcome bonus.

Re: BOINC additions:
BOINC needs a "benchmark" capability. Similar to the KWSN-bench-Linux package for Seti that allows running an application with its data file and for comparison of the result with either a known correct result or an alternate application result. Every BOINC project should make available a reference package (app+data+result) to facilitate validation of hardware and software changes. And, of course, as a convenient reference for optimization parameters, hardware comparisons, etc. Surely the project developer has those files(!) - but BOINC doesn't provide any way to use them.

And This. That would be great in addition to the above, to get a decent guesstimate as to how it should most likely perform in the real world, to tweak it before starting to process real work units.

Sadly, I don't have the ability to help with this in the coding sense, I couldn't code myself out of a wet paper bag. I try to contribute in other ways though, and when life settles down a little bit in my world, I would be willing to test some things (if your looking to test on outlier rigs like my own that stretch the envelope a bit), as well as the annual contribution.

---