I got MB a couple weeks ago as well. This was when the AP splitter was down and S@H was forced to send out MB to everyone

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

I think that there are a lot of extra AP in the queue because some error out or have been aborted by users. I haven't received many AP that didn't have at least one compute error or abort. They also take much longer to crunch so MB simply get chewed through faster, especially by CUDA, again leaving more AP in the queue. This all makes it look like there is an excess of AP. I don't mind, AP take longer, but do tend to pay better especially with optimized apps. It will probably take a while before a balance is found.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

but then all this CUDA stuff came out

With the servers set to dish out equal amounts of work the CUDA clients would get all the MB the server has and CPU's the AP.

That makes sense now... Its an unintentional side effect from fixing another problem and releasing cuda.

We didn't notice before due to there was never any AP ready to send (before v5) so MB were abundant.

~Bob

Not trying to come off sounding mean or offensive, but have you read the part about "if I go to an MB-only venue, I can get my daily quota of MBs without fail"? I don't think the scheduler decides "you don't have CUDA, so no MB for you", I just think there's a minor logic flaw that either hasn't been found yet, or hasn't been gotten to (there's been some database crises to tend to lately).

Hopefully the flaw can be discovered and we can go back to the ~25/1 ratio for MB/AP.

---

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

I have a feeling that the code on the server looks something like:

if there is work needed on the host and AP work is available and the user has allowed AP work, send it.
if there is still work needed on the host and SETI work is and the user has allowed SETI work, send it.
if there is still work needed and the host has allowed other applictions than the one he selected, send it.

---

BOINC WIKI

very odd!!!

my amd host is crunching away without any problem and i am getting 6.03, 6.08, ap_5.03 branded wu. id say problem is in older boic versions not on the seti servers.

I have a feeling that the code on the server looks something like:

if there is work needed on the host and AP work is available and the user has allowed AP work, send it.
if there is still work needed on the host and SETI work is and the user has allowed SETI work, send it.
if there is still work needed and the host has allowed other applictions than the one he selected, send it.

Yeah, somebody (can't remember who out of richard, ozz, or josef) explained the way the logic works for the selected apps in the venue.

It was something along the lines of checking the feeder queue for the selected apps, and if either one responds with a non-zero ready-to-send, that app gets sent. Then if you have 'allow for other apps' selected, all three queues (mb, ap, ap_v5) are queried if the initial query was not satisfied.

So at some point, having MB selected on a non-CUDA rig gets ignored.

---

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

I have a feeling that the code on the server looks something like:

if there is work needed on the host and AP work is available and the user has allowed AP work, send it.
if there is still work needed on the host and SETI work is and the user has allowed SETI work, send it.
if there is still work needed and the host has allowed other applictions than the one he selected, send it.

Yeah, somebody (can't remember who out of richard, ozz, or josef) explained the way the logic works for the selected apps in the venue.

It was something along the lines of checking the feeder queue for the selected apps, and if either one responds with a non-zero ready-to-send, that app gets sent. Then if you have 'allow for other apps' selected, all three queues (mb, ap, ap_v5) are queried if the initial query was not satisfied.

So at some point, having MB selected on a non-CUDA rig gets ignored.

Only if AP is available and you have AP selected. I bet that if you select MB and allow others, you get MB.

It might be better if which app were selected first were random.

---

BOINC WIKI

I have a feeling that the code on the server looks something like:

if there is work needed on the host and AP work is available and the user has allowed AP work, send it.
if there is still work needed on the host and SETI work is and the user has allowed SETI work, send it.
if there is still work needed and the host has allowed other applictions than the one he selected, send it.

Yeah, somebody (can't remember who out of richard, ozz, or josef) explained the way the logic works for the selected apps in the venue.

It was something along the lines of checking the feeder queue for the selected apps, and if either one responds with a non-zero ready-to-send, that app gets sent. Then if you have 'allow for other apps' selected, all three queues (mb, ap, ap_v5) are queried if the initial query was not satisfied.

So at some point, having MB selected on a non-CUDA rig gets ignored.

Only if AP is available and you have AP selected. I bet that if you select MB and allow others, you get MB.

It might be better if which app were selected first were random.

Using the -allapps mode (as I believe this project is still doing), the shared memory between the Feeder and the Scheduler is organized so the kinds of work are interleaved. The Scheduler goes through that in order, so the effect is supposed to produce a mix of work if the host preferences allow.

There are 100 slots in that shared memory, if the project hasn't specified weightings for the 3 different kinds of work there are probably 34 slots for S@H Enhanced, 33 for Astropulse, and 33 for Astropulse v5. When the Feeder succeeds in filling the slots (leaving some empty when there are none of the correct type in the DB within reach of its enumeration) it goes to sleep for 2 seconds. My guess is that describes how it's working, so during that 2 seconds the 34 Enhanced WUs are assigned within a fraction of a second, there probably were no or at most 1 AP WU, and for the rest of that 2 second interval only AP_v5 work is available.

The other possibility is that some of that Feeder code isn't doing what the comments say it is designed to do. There's too much database-related code in there for me to really analyze it in sufficient detail to know.

                                                                  Joe

I had to do some digging, but found my previous post in another thread about what happens when I do NNT for a few days and change to MB-only venue: Message ID: 878468

Alright, well with everything working again, I have been able to finally prove something that I've been saying as an unfounded rumor. turns out I was right.

Venue with MB, AP, AP_v5, allow for others, no GPU: nothing but ap_v5 WUs
Venue with MB only, no GPU: plenty of MBs to be had.

2009-03-22 22:14:42|SETI@home|Sending scheduler request: To fetch work. Requesting 1094534 seconds of work, reporting 16 completed tasks
2009-03-22 22:14:47|SETI@home|Scheduler request succeeded: got 8 new tasks
2009-03-22 22:15:03|SETI@home|Sending scheduler request: To fetch work. Requesting 1037461 seconds of work, reporting 0 completed tasks
2009-03-22 22:15:08|SETI@home|Scheduler request succeeded: got 19 new tasks
2009-03-22 22:15:24|SETI@home|Sending scheduler request: To fetch work. Requesting 901757 seconds of work, reporting 0 completed tasks
2009-03-22 22:15:29|SETI@home|Scheduler request succeeded: got 15 new tasks
2009-03-22 22:15:44|SETI@home|Sending scheduler request: To fetch work. Requesting 794627 seconds of work, reporting 0 completed tasks
2009-03-22 22:15:49|SETI@home|Scheduler request succeeded: got 17 new tasks
2009-03-22 22:16:00|SETI@home|Sending scheduler request: To fetch work. Requesting 673232 seconds of work, reporting 0 completed tasks
2009-03-22 22:16:05|SETI@home|Scheduler request succeeded: got 2 new tasks
2009-03-22 22:16:21|SETI@home|Sending scheduler request: To fetch work. Requesting 658994 seconds of work, reporting 0 completed tasks
2009-03-22 22:16:26|SETI@home|Scheduler request succeeded: got 15 new tasks
2009-03-22 22:16:42|SETI@home|Sending scheduler request: To fetch work. Requesting 551662 seconds of work, reporting 0 completed tasks
2009-03-22 22:16:48|SETI@home|Scheduler request succeeded: got 18 new tasks
2009-03-22 22:17:04|SETI@home|Sending scheduler request: To fetch work. Requesting 422650 seconds of work, reporting 0 completed tasks
2009-03-22 22:17:09|SETI@home|Scheduler request succeeded: got 8 new tasks
2009-03-22 22:17:26|SETI@home|Sending scheduler request: To fetch work. Requesting 365525 seconds of work, reporting 0 completed tasks
2009-03-22 22:17:31|SETI@home|Scheduler request succeeded: got 8 new tasks
2009-03-22 22:17:46|SETI@home|Sending scheduler request: To fetch work. Requesting 308477 seconds of work, reporting 0 completed tasks
2009-03-22 22:17:52|SETI@home|Scheduler request succeeded: got 16 new tasks
2009-03-22 22:18:07|SETI@home|Sending scheduler request: To fetch work. Requesting 194249 seconds of work, reporting 0 completed tasks
2009-03-22 22:18:13|SETI@home|Scheduler request succeeded: got 18 new tasks
2009-03-22 22:18:29|SETI@home|Sending scheduler request: To fetch work. Requesting 65725 seconds of work, reporting 0 completed tasks
2009-03-22 22:18:35|SETI@home|Scheduler request succeeded: got 10 new tasks
2009-03-22 22:18:51|SETI@home|Sending scheduler request: To fetch work. Requesting 2846 seconds of work, reporting 0 completed tasks
2009-03-22 22:18:57|SETI@home|Scheduler request succeeded: got 1 new tasks
2009-03-22 22:19:08|SETI@home|Sending scheduler request: To fetch work. Requesting 1251 seconds of work, reporting 0 completed tasks
2009-03-22 22:19:14|SETI@home|Scheduler request succeeded: got 0 new tasks
2009-03-22 22:19:14|SETI@home|Message from server: No work sent
2009-03-22 22:19:14|SETI@home|Message from server: No work is available for SETI@home Enhanced
2009-03-22 22:20:14|SETI@home|Sending scheduler request: To fetch work. Requesting 1368 seconds of work, reporting 0 completed tasks
2009-03-22 22:20:19|SETI@home|Scheduler request succeeded: got 1 new tasks

True that second-to-last request is misleading. It has already been proven that the scheduler can only assign what it has left from the last feeder query, so it appears I had pretty decent timing for the requests on all of them except that one.

I'm calling this case closed. :p

---

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