I'm still getting both MB and AP at the ratio expected (30-50:1), so yes, APs will be rarer compared to previously (when a huge AP bubble was allowed to developed until there was like 40+ tapes where AP was completed and MB had to catch up).

AP is still ahead now but it is much closer. Ideally they should be at parity, but still some way to go considering the additional work asked of the latest MB task.

By the way, now MB have a longer deadline compared to AP. I'm just waiting for people to complain about the build up of pending credit again ;-)

---

I'm puzzled by the bad luck of those looking for AP_v505 work. Of 116 tasks my laptop did in July, 7 were AP_v505. I also got another earlier today. Preferences are set to accept anything and I of course have an app_info.xml and optimised apps to do them.

I'm on dial-up, so only enable network activity once or twice a day, and I first take a look at the Cricket graph and the server status to avoid bad periods. The cache on the host is 1.375 days, so requests could generally be fulfilled by ten or fewer MB tasks, typically more like 3 to 5 non-doubled tasks and it'll average less with the new doubled ones.

AFAICT there should be nothing causing my host to get more than its share other than the laws of chance.

                                                                Joe

OK. That's one end of the spectrum. I can't tell you how many tasks I've crunched in July, or what percentage were AP, but my quaddie with 4 overclocked cores and a GTX295 gets through a lot with the optimised apps. I run a 3-day cache and my preferences are set to AP but anything else if no AP available. Unlike Joe, I'm permanently connected but echo his experience of getting my share of v505's when AP's are available. In fact, I've returned 4 of them in the past day and am currently munching on a fifth.

F.

Hi Fred,

Must be the luck of the draw. I have my preferences set the same as you have, but I keep an 8 day cache. I just checked and I have exactly 7 AP's in a total of 2700 tasks. Not a lot, is it :-)

Regards,
John.

With my two Windows boxes (since I haven't seen a r168 for Linux yet), I have only gotten one AP, and that was when I unchecked MB and allowed others, and it still took ~20 work requests to finally get one.

Since then, I've gone back to "allow everything" (all boxes checked) and have not seen a single AP since its release with that method.

Who would have guessed that three months ago, AP was all you got, and now it's nearly impossible to get one?

This doesn't upset me or anything, though I would like to have some more AP than none.

Possibly time to change the feeder cache to 90/10 instead of 97/3? If it was at 50/50, or still 34/33/33 (mb/ap-original/ap_v5) previously, then somewhere far away from that ratio and not quite as constrained as 97/3 should do the trick with an even balance.

Though I do agree with one thing I heard from I think..Josef (?) a few weeks ago. The problem is that presently we are sitting just under 200,000 APs out in the field, and before the crisis there were approximately double that, so until we get close to that point again, they will be hard to come by.

Granted there were a lot of people who were AP-exclusive for the credit payout, but from what I saw with the one single AP_v505 I got and crunched with r168, it pays within about 5% of AK_v8 for MB, so now it doesn't matter which app gets used for crunching, since they both pay the same per second.

---

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

I still cant see why having a bigger cache would get AP's . I mean as long as you can crunch them before the dead line, who cares how big your cache is. My settings are where they are supposed to be and i havent seen a V5.05 yet.

I still think some of you guys are getting them E-mailed to you:)

I'd be curious to know if any of you are running 6.6.36 and getting AP. Thats what im running on the P4.

edit ok I see one change i will make, and run AP but except other work. My Mac cant do AP so that will just get MB. Ill try that.

---

[/quote]

Old James

If you haven't made any "preference" selections, and BOINC requests one second of work, you'll get one work unit, and it could be MB or AP.

The reason AP is a little scarce is that there simply aren't that many. The 97:3 ratio in the feeder is very close to the ratio of MB to AP that can be generated from a tape, and changing the splitter ratio just changes how fast AP goes out when it's available -- but the odds of getting one are still about 1 in 33.

---

I see one reason that making big work requests might increase the chances of getting an AP. The set of 100 slots is assigned in a way that apps with few slots are distributed evenly. Assuming we now have a 96:3 MB:AP_v505 ratio and 1 slot for AP_v5 resends, the pattern would have 32 MB slots followed by 1 AP_v505 slot and two more repeats of the pattern. The AP_v5 slot is almost always empty, so it doesn't matter where it is in the sequence.

If a host makes a request which would take more than twenty MB tasks to fulfill, the Scheduler process will probably need to look through something approaching forty slots, since once it picks up one of the initial replication tasks for a WU the host isn't eligible to get the other. The two initial replication MB tasks have sequential resultIDs and will quite commonly occupy two adjacent slots. So if a request spans around 38 slots before the 20 limit is reached, it will include at least one, and sometimes two, of the AP_v505 slots.

Of course the AP_v505 task must not yet have been assigned to another host, so that analysis breaks down half a second or less after each Feeder run, but you might get lucky and most of the requests during that first half second were from hosts not eligible for AP work; then the big request might well get two APs and miss out on the third only because it's the other half of an initial replication pair.

                                                              Joe

Josef, this algorithm seems a bit obscure. Is there some history or rationale you can provide about it or how it evolved?

For example, was it selected using trial and error, or was it established as somehow mathematically 'optimal'?

Or is it peculiar to the server scheme seti is using?

(BTW, I think I understand at least superficially the 96:3 splitting ratio.)

Josef, this algorithm seems a bit obscure. Is there some history or rationale you can provide about it or how it evolved?

For example, was it selected using trial and error, or was it established as somehow mathematically 'optimal'?

Or is it peculiar to the server scheme seti is using?

(BTW, I think I understand at least superficially the 96:3 splitting ratio.)

Since AP gets only 3 slots in every 100, it seems eminently logical to spread them out as much as possible to reduce the probability of one host-request grabbing them all. As has been demonstrated, it does not prevent one host-request getting 2 out of the 3 if it is allocated the maximum of 20 tasks. Perhaps the maximum number of tasks sent in response to a single request should be reduced to (say) 16 to help spread the AP's round a bit more?

F.

---

Hi, AP Splitters are Not Running.
Or there isn't any AP (Broadband)5.03 & 5.05 WU left?

---

Hi, AP Splitters are Not Running.
Or there isn't any AP (Broadband)5.03 & 5.05 WU left?

All up and running again.

F.

---

Granted there were a lot of people who were AP-exclusive for the credit payout, but from what I saw with the one single AP_v505 I got and crunched with r168, it pays within about 5% of AK_v8 for MB, so now it doesn't matter which app gets used for crunching, since they both pay the same per second.

Actually comparing the results sitting on my E6300 (the old school core 2 duo one, not one of those fast Pentium E6300), 7 MBs are 5% faster per credit than the 3APs, 3 worse and the other 2 in the same range.

Credits/hour are no longer justification enough to go AP exclusive or even AP preference (may be different for other CPU marchitecture, but should somewhere close to parity if not at parity). With the new MB deadlines being longer than AP, almost everything is pointing that MB is to go for my case

---

Josef, this algorithm seems a bit obscure. Is there some history or rationale you can provide about it or how it evolved?

For example, was it selected using trial and error, or was it established as somehow mathematically 'optimal'?

Or is it peculiar to the server scheme seti is using?

(BTW, I think I understand at least superficially the 96:3 splitting ratio.)

BOINC provides a variety of possible command line options for the Feeder. When Astropulse was first released here, they continued using the basic mechanism which just fills slots with whatever is next in the combined "Results ready to send" queue. Later they switched to using the -allapps option with no app weightings specified. Still later they added the 97:3 weightings when there was only MB and AP_v5. When AP_v505 was added I assume it got 3 and one was taken from MB so AP_v5 would have one for reissues. The actual desired ratio is near 40:1, so AP is still progressing through the input data faster, but it's close enough not to cause major problems. If needed they can change the number of slots to allow a better ratio setting, e.g. 124 slots would allow a 120:3:1 ratio.

The -allapps Feeder option was originally added to BOINC in September 2005, the app weightings in July 2006. Neither of those changes was accompanied by change notes to reveal why.

                                                                 Joe

Granted there were a lot of people who were AP-exclusive for the credit payout, but from what I saw with the one single AP_v505 I got and crunched with r168, it pays within about 5% of AK_v8 for MB, so now it doesn't matter which app gets used for crunching, since they both pay the same per second.

Actually comparing the results sitting on my E6300 (the old school core 2 duo one, not one of those fast Pentium E6300), 7 MBs are 5% faster per credit than the 3APs, 3 worse and the other 2 in the same range.

Credits/hour are no longer justification enough to go AP exclusive or even AP preference (may be different for other CPU marchitecture, but should somewhere close to parity if not at parity). With the new MB deadlines being longer than AP, almost everything is pointing that MB is to go for my case

I was going by what I observed on my one particular machine. We have seen credit/sec or credit/hour differences in the past using the same applications on different processors. It all depends on the CPU and how efficiently it does certain tasks.

On an Opteron 2222SE at least, using SSE3, both AP_v505 and MB pay out right at ~0.007 credits/sec. Previously with r112, I was near 0.011 credits/sec. [side note]I caught myself again..was off by a factor of 10 for the credits/sec numbers..keep forgetting that extra zero[/side note]

---

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

I'm puzzled by the bad luck of those looking for AP_v505 work. Of 116 tasks my laptop did in July, 7 were AP_v505. I also got another earlier today. Preferences are set to accept anything and I of course have an app_info.xml and optimised apps to do them.

I'm on dial-up, so only enable network activity once or twice a day, and I first take a look at the Cricket graph and the server status to avoid bad periods. The cache on the host is 1.375 days, so requests could generally be fulfilled by ten or fewer MB tasks, typically more like 3 to 5 non-doubled tasks and it'll average less with the new doubled ones.

AFAICT there should be nothing causing my host to get more than its share other than the laws of chance.

                                                                Joe

OK. That's one end of the spectrum. I can't tell you how many tasks I've crunched in July, or what percentage were AP, but my quaddie with 4 overclocked cores and a GTX295 gets through a lot with the optimised apps. I run a 3-day cache and my preferences are set to AP but anything else if no AP available. Unlike Joe, I'm permanently connected but echo his experience of getting my share of v505's when AP's are available. In fact, I've returned 4 of them in the past day and am currently munching on a fifth.

F.

Hi Fred,

Must be the luck of the draw. I have my preferences set the same as you have, but I keep an 8 day cache. I just checked and I have exactly 7 AP's in a total of 2700 tasks. Not a lot, is it :-)

Regards,
John.

I'm with you on that John. I haven't gotten an AP for 2 weeks, I did get about a dozen last time I did get AP tasks but those were the first in over a month. My cruncher can dispose of WUs is fairly short order too so that isn't the issue. I also have an 8 day cache. Oh well, we can only hope for more AP WUs down the road...

Hi Fred,

Must be the luck of the draw. I have my preferences set the same as you have, but I keep an 8 day cache. I just checked and I have exactly 7 AP's in a total of 2700 tasks. Not a lot, is it :-)

Regards,
John.

I'm with you on that John. I haven't gotten an AP for 2 weeks, I did get about a dozen last time I did get AP tasks but those were the first in over a month. My cruncher can dispose of WUs is fairly short order too so that isn't the issue. I also have an 8 day cache. Oh well, we can only hope for more AP WUs down the road...

Heigh-ho. Yesterday I ran down my cache to zero so I could detach / re-attach to release a load of phantom WU's. At the same time I've swapped out my vid card for a non-CUDA capable one so I could RMA the GTX295 as it developed a memory problem on GPU2 after 7 months of crunching :( I have so far snagged 1 AP in the first 310 tasks downloaded. Seems about the right order of magnitude.

F.

---

Aah memories.
Remember the wailing and gnashing of teeth when AP was first released? Remember the usual suspects complaining about how long they took to crunch, threatening to leave the project, demanding they be shortened etc. etc.

And then the Lunatics came to the rescue with the optimised AP apps and now exactly the opposite applies, the complaints are now all about how there aren't enough AP units available.

You humans are such strange creatures :-)

You humans are such strange creatures :-)

Hear here!

---

Lets hope the credit/hour parity between v505 and MB holds.

At the rate MB is increasing, and AP decreasing, very soon AP will be the neglected stepsister again.

---

Both the AP & MB assimilators appear to be clogged up.

---

Grant
Darwin NT

The Assimilators still appear to be not assimilating.
The queue grows larger.

---

Grant
Darwin NT