Neither do I. It's a mystery.

As an aside, I did notice that towards the end of the AP run, that downloads seem to fall back to only 2 at a time even though I have it set to 8 concurrent. The two that downloaded came down at breakneck speed and then the rest would hang and not download. I had to Suspend Network Activity and then restart it to get another two to download, then repeat until all APs were downloaded.

Just another mystery I suppose.

---

I need another walkthrough of the scheduler logic at some point, to confirm the exact mechanism. I do recall though there are links into the wonky time estimates early in the application selection part. (kindof a simulation of what the host would do with tasks, to decide what to send)

Some, maybe most, will see the 'expected' behaviour more or less by chance, while others fall into some funk for no apparent reason. From a control systems theory point of view, there are several 'strange attractors' present in that mechanism.

One of those inducing oscillations in estimates is the use of short term sample averages over arbitrary natural (noisy) input with little (if any) filtering, another the efficiency offsets by using the wrong Boinc Whetstone for the applications concerned, and probably another that the averages used evolve at too high of a frequency for what they're controlling (temporal mismatch)

Simplifying from above, there's a slim chance that other workarounds might be feasible, apart from adjusting the cache. Disabling bench and Fixing the Boinc Whetstone value at a realistic value (Say obtained via sisoft Sandra or similar) in single threaded SSE2 form should remove one contributor to instability in the mechanism. That figure should be around 2.5x Boinc Whetstone. It'd take some time to readjust estimates, but at least probably put CPU estimates into the ballpark to be selected.

For the GPU side, setting app info <flops> values might see similar stability or functional improvement. Again would have to walk through again, but this may override a swathe of dodgy estimate code used for the purposes of app selection (among other things). You could base that figure either on the high side of APR from the application details page, or just use 5-10% of the theoretical peak flops (it'll be non critical), and some lower figure for multiple instances.

That won't really fix the way the Boinc servers do things, but at least be some sortof workaround for hosts that refuse to play well with Boinc's wonky estimates.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The first pre-requisite for receiving new tasks is that your computer is actively requesting tasks.

If you are actively processing work for the project, and completing tasks, then BOINC will keep requesting work. But if you're inactive for any reason, work requests will become fewer and further apart.

Not wishing to sound somewhat strange but how does your comment relate to the above comments (i just can't see the link, sorry about that) ...

---

The first pre-requisite for receiving new tasks is that your computer is actively requesting tasks.

If you are actively processing work for the project, and completing tasks, then BOINC will keep requesting work. But if you're inactive for any reason, work requests will become fewer and further apart.

Not wishing to sound somewhat strange but how does your comment relate to the above comments (i just can't see the link, sorry about that) ...

I do notice, even though I'm using an older build of BOINC, that even if I am processing tasks, and requesting work, consecutive scheduler replies that do not assign any new tasks cause the requests to get further and further apart.

I thought there was supposed to be at least one scheduler contact every 24 hours, as well (I know for sure I read that here on the forums more than once over the years), but over the past few weeks of no APs, I was going 2-3 days without any scheduler contact until I manually clicked the update button.

And I know about the "project back-off" counter, in the case of failed transfers and the like, but when 6.10.58 decides to not even bother talking to the scheduler for 2-3 days, there is nothing under the 'status' column on the projects tab, nor in the message log indicating that it is going to wait 48+ hours because the last 25 contacts yielded no new work.


In that particular situation, if you are really doing set-and-forget and BOINC gets into that hidden 48-hour back-off, then I would imagine it would be difficult to get any tasks at all. And I should also note that once I hit the update button, it makes a contact, waits 303 seconds, makes another contact, the status column counts down to zero, and then there is nothing in the status column, and anywhere from 5 seconds to 5 minutes is when the next scheduler attempt is made, without indicating that there is any kind of back-off being enforced.

I'm sure that was fixed in newer builds, but that's what I think Richard meant by the first quote. (side-note.. my single-core machine running 6.2.19 doesn't have the phantom back-off phenomenon... it clearly says how long it is waiting before communicating again, and when it reaches zero, communication happens right away, and the increasing back-off maxes out at 3:59:59. That being said, it will communicate once every ~24 hours (it isn't down to the second, usually +/- 2-3 hours, but there is at least one contact per calendar day (unless it goes from like.. 2350 Monday to 0015 Wednesday)).)


What I mentioned in my observations is that if you have nothing in your cache at all, and you request a very large amount of work, you tend to not get anything at all, unless tasks are abundant on the server (either a pile of RTS, or creation rate is greater than 1.000/sec). Once you get some tasks on board, they start flowing in a bit smoother, but once you get a few empty-net scoops in a row, the requests start becoming less frequent.


The thing I think a small group of people are trying to figure out is: why does the server tend to not give you any work when you have an empty cache and you're requesting a large amount of work? And/Or.. why does one device seem to get all that it wants, whilst the other starves?


Anyway, that's probably enough rambling for now. I may not have solutions or answers, but maybe I can ask the right questions to dislodge a solution or answer out of someone else.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Not wishing to sound somewhat strange but how does your comment relate to the above comments (i just can't see the link, sorry about that) ...

Many people over the years have made comments like "BOINC isn't sending me any [project] jobs" - it might be SETI, it might be other projects. I'm simply drawing the distinction between "server sending" - as if it was an action initiated by the server - and "client requesting" - an action initiated locally.

One reason for drawing the distinction is that the local action can be checked in the local Event Log, and I'd suggest that's the first place to look. When I see posts like Speedy's "I have not received any for a long time", my mind wonders "but did you actually ask for any during the time period when AP work was available?".

On a related note, since writing my comment, I've answered a question at the BOINC message boards, from someone who thought the SETI project was down because he hadn't received any work for over a week. From the other information he'd provided, it was clear that he had clicked the 'No new tasks' button...

I have a feeling that the scheduler looks at ... you are requesting 10 days, but your app history says 2 days, so you are thrown into the "i'll get to you latter bucket" I'm dealing with the people that have reasonable requests.

I seem to have better luck with a 1.5 or 2 day setting.

Which makes me think, Did I get greedy with a big cache that I missed the last AP feeding? IDK if I boosted my cache for that, I forget :(

---

Wow, 2 AP WUs... Can't recall how long it's been since the last ones, months and months, definitely.

---

And OMG.....
Just before I have to run off to work, I see another '15 dataset loaded and splitting off fresh APs!!!
Dang, wish I could sit here and watch them come in.
The kitties already snagged about 22 of them.

Meowza!

---

"Time is simply the mechanism that keeps everything from happening all at once."

Dang, You must have some rabbit's feet hanging around there somewhere Mark,

I'm squeezing out a few. Just had 1 CPU AP finish in 4 seconds :( Stderr says 100% blanked.

Get them while you can....

Get them while you can....

I'm trying but with no luck so far. Staying positive.
Positivity paid off as I am currently downloading to tasks, and sure a few more will come in

---

Got 74 AP's so far. Still incoming.

197 here and climbing almost like how things were b4 the big crash

Just got home from a 12 hour shift.
Whilst I was away, the kitties grabbed up 876 of them AP beasties.
On 9 rigs.

Good work, kitties.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I'm curious if anyone knows this answer ...
Does AP processing of 50 GB of data take less lime than MB?

It's just, AP and MB tasks can never equal out, or is it just too many people refusing to crunch MB and do AP only?

---

If you mean the splitting into work units then the answer is very firmly "YES". The AP splitters only have to chug through the data and every xMb produce a new work unit. The MB splitters have to chug though so far, produce a work unit, compress it, then scroll back a bit in the source file and do it all over again.

If you are talking about the processing we do then the answer is, well, not so easy. Are we talking about sending the tasks generated only to GPU hosts, what is the angle range of the tasks (are they "shorties", normals, "longies", or VLARS,..., ..., ... ) do the tasks contain a significant amount of dross? And no doubt a few more considerations (such as optimised vs. stock applications) and the answer is... I think the general consensus is that the APs generated from a given tape will take slightly less time than then MB, but not a lot... (I stand to be proven wrong)

---

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

I'm curious if anyone knows this answer ...
Does AP processing of 50 GB of data take less lime than MB?

It's just, AP and MB tasks can never equal out, or is it just too many people refusing to crunch MB and do AP only?

The MB tasks created are around 377KB where an AP is around 8MB. So AP tasks are roughly 21 times lager. As far as processing times my i5-4670Ks do MB tasks in ~1 hr and AP tasks in ~3.5 hours. So AP processing does happen, on the same given hardware, much quicker.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Yea I guess your right, there is no where near 20 times processing time for AP files.

And for MB overlaps, (I forget the overlap time) but that could count for 5-10% more processing required.

---

It's nice to have both my CPU's full of AP's again.

Cheers.

Geeze, they're adding AP files to the splitters as if there were no tomorrow :-)

Maybe they are taking a 4 day weekend for the holiday. I only get a 3 day weekend from my work.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

The project continues to split APs, totally amazing. This is the best I can recall since APv6 went away last Nov.

---