... something around half the shortest deadline, or about two days.

The shortest deadline on SETI is 7 days, so half that would allow ~3.5 days.

We used to have 4-day deadline work with the old linefeed antenna application, but not since the transition to the multibeam recorder and the matching application.

I haven't kept track of deadlines all that much.

It was pretty evident when the short deadlines were in place that shorties had a dramatic effect on the size of the cache.

---

I just had a look at mine. I've got a nominal 10 day cache. Right now I have 104 WU's in line and it's working on 2. That's right at 240 hours total time, or 5 days for a dual core. Ok so that checks ok

I don't see a problem with this as it works on WU's according to their deadline, not the order received. I'll often spot a WU that's suspended as 1 came in with an earlier deadline and it's been bought to the front of the line.

It doesn't really matter how many WU's someone has, as they'll get done in date order just like yours, and they'll get returned about the same time, unless someone has a glitch somewhere.

---

I just had a look at mine. I've got a nominal 10 day cache. Right now I have 104 WU's in line and it's working on 2. That's right at 240 hours total time, or 5 days for a dual core. Ok so that checks ok

I don't see a problem with this as it works on WU's according to their deadline, not the order received. I'll often spot a WU that's suspended as 1 came in with an earlier deadline and it's been bought to the front of the line.

It doesn't really matter how many WU's someone has, as they'll get done in date order just like yours, and they'll get returned about the same time, unless someone has a glitch somewhere.

With a full 10 day cache on a dual core the totals hours should be 480 hours.
On my quad core with a two day cache I have 195 hrs of incomplete work.
And my tasks are always done as FIFO, (first in first out). If they are being done by date then the computer is in priority mode, and will not download any tasks to fill your cache until it cleared the urgent tasks.

With some tasks having a 7 day deadline it is almost impossible to have a cache bigger than 7days.

I just had a look at mine. I've got a nominal 10 day cache. Right now I have 104 WU's in line and it's working on 2. That's right at 240 hours total time, or 5 days for a dual core. Ok so that checks ok

I don't see a problem with this as it works on WU's according to their deadline, not the order received. I'll often spot a WU that's suspended as 1 came in with an earlier deadline and it's been bought to the front of the line.

It doesn't really matter how many WU's someone has, as they'll get done in date order just like yours, and they'll get returned about the same time, unless someone has a glitch somewhere.

With a full 10 day cache on a dual core the totals hours should be 480 hours.
On my quad core with a two day cache I have 195 hrs of incomplete work.
And my tasks are always done as FIFO, (first in first out). If they are being done by date then the computer is in priority mode, and will not download any tasks to fill your cache until it cleared the urgent tasks.

With some tasks having a 7 day deadline it is almost impossible to have a cache bigger than 7days.

Actually, it's not hard at all. Set the Connect interval to less than 3.5 days and Additional work to 6.5 days or more.

...

If this is the case, it's possible that I did something wrong when installing the optimizer. Currently, it's in HD>Library>Application\ Support>BOINC\ Data>Projects>setiathome.berkeley.edu and the owners are set to boinc_master as I was told to. I understand that running the installer would ensure that I've done everything correctly but, considering that at least part of it's running properly...

Would it be best to just re-install Boinc?

If you've put the latest files in the seti folder, the easiest way to set the permissions is to just re-install the BOINC 6.2.18 application - takes only minutes. I looked at your tasks and the data in the task results looks the same as the data in mine, and I know I'm running the optimized apps. So, I'd say you probably are ok just as you are, and you should see your RAC rise pretty quickly.

C

---

Join Team MacNN

I just had a look at mine. I've got a nominal 10 day cache. Right now I have 104 WU's in line and it's working on 2. That's right at 240 hours total time, or 5 days for a dual core. Ok so that checks ok

I don't see a problem with this as it works on WU's according to their deadline, not the order received. I'll often spot a WU that's suspended as 1 came in with an earlier deadline and it's been bought to the front of the line.

It doesn't really matter how many WU's someone has, as they'll get done in date order just like yours, and they'll get returned about the same time, unless someone has a glitch somewhere.

I am not sure this is true, surely it's First In First Out, otherwise why is my quad currently crunching 4 WU's for the 3rd of April when further down the queue are several WU's for the 19th March. Of course with a 1 day cache it is not a problem.

Bernie

---

I just had a look at mine. I've got a nominal 10 day cache. Right now I have 104 WU's in line and it's working on 2. That's right at 240 hours total time, or 5 days for a dual core. Ok so that checks ok

I don't see a problem with this as it works on WU's according to their deadline, not the order received. I'll often spot a WU that's suspended as 1 came in with an earlier deadline and it's been bought to the front of the line.

It doesn't really matter how many WU's someone has, as they'll get done in date order just like yours, and they'll get returned about the same time, unless someone has a glitch somewhere.

I am not sure this is true, surely it's First In First Out, otherwise why is my quad currently crunching 4 WU's for the 3rd of April when further down the queue are several WU's for the 19th March. Of course with a 1 day cache it is not a problem.

Bernie

Correct, it is FIFO unless Boinc perceives a deadline problem - unless you run CUDA on the latest *DEVELOPMENT* versions which seem to have a propensity for deadline order.

F.

---

I just had a look at mine. I've got a nominal 10 day cache. Right now I have 104 WU's in line and it's working on 2. That's right at 240 hours total time, or 5 days for a dual core. Ok so that checks ok

I don't see a problem with this as it works on WU's according to their deadline, not the order received. I'll often spot a WU that's suspended as 1 came in with an earlier deadline and it's been bought to the front of the line.

It doesn't really matter how many WU's someone has, as they'll get done in date order just like yours, and they'll get returned about the same time, unless someone has a glitch somewhere.

I am not sure this is true, surely it's First In First Out, otherwise why is my quad currently crunching 4 WU's for the 3rd of April when further down the queue are several WU's for the 19th March. Of course with a 1 day cache it is not a problem.

Bernie

Correct, it is FIFO unless Boinc perceives a deadline problem - unless you run CUDA on the latest *DEVELOPMENT* versions which seem to have a propensity for deadline order.

F.

So what he is seeing is Boinc moving a WU to the front of the queue, because it is likely to miss it's date if not done first. With a 1 day cache I never see this happen. All my tasks are FIFO. Which comes back to the original point large caches are more likely to have problems, and in my opinion are selfish.

Bernie.

---

...

If this is the case, it's possible that I did something wrong when installing the optimizer. Currently, it's in HD>Library>Application\ Support>BOINC\ Data>Projects>setiathome.berkeley.edu and the owners are set to boinc_master as I was told to. I understand that running the installer would ensure that I've done everything correctly but, considering that at least part of it's running properly...

Would it be best to just re-install Boinc?

If you've put the latest files in the seti folder, the easiest way to set the permissions is to just re-install the BOINC 6.2.18 application - takes only minutes. I looked at your tasks and the data in the task results looks the same as the data in mine, and I know I'm running the optimized apps. So, I'd say you probably are ok just as you are, and you should see your RAC rise pretty quickly.

C

Thanks :)

Oh, one question, It seems like, since getting the optimizer, that I'm only getting astropulse tasks. Is this standard or should I still be getting both?

---

Oh, one question, It seems like, since getting the optimizer, that I'm only getting astropulse tasks. Is this standard or should I still be getting both?

Only if your app_info.xml file includes entries for both. That's the first thing to check.

F.

---

Oh, one question, It seems like, since getting the optimizer, that I'm only getting astropulse tasks. Is this standard or should I still be getting both?

Only if your app_info.xml file includes entries for both. That's the first thing to check.

F.

I'm not sure what to look for, exactly...

The app_info.xml file starts with the seti_enhanced app version 603

After that is the astropulse app version 500.

Then the astropulse_v5 version 503.

~C

---

Oh, one question, It seems like, since getting the optimizer, that I'm only getting astropulse tasks. Is this standard or should I still be getting both?

Only if your app_info.xml file includes entries for both. That's the first thing to check.

F.

I'm not sure what to look for, exactly...

The app_info.xml file starts with the seti_enhanced app version 603

After that is the astropulse app version 500.

Then the astropulse_v5 version 503.

~C

That's exactly what to look for, and you've answered Fred's question prefectly. At least with a Mac we don't have to worry about CUDA ... yet ...

You should be capable of dealing with both (all three) types of task. After that, it's the luck of the draw which one you get allocated by the server. Just at the moment, as others have commented, the server seems to be drawing straight Astropulses.

You could test it, if you wanted to see a bit of variety, by temporarily forbidding AP tasks in the preferences in your account on this website (you can't do that through BOINC Manager). Such a change woudln't affect any tasks you have already downloaded, but it will influence any future work the server sends you.

You should be capable of dealing with both (all three) types of task. After that, it's the luck of the draw which one you get allocated by the server. Just at the moment, as others have commented, the server seems to be drawing straight Astropulses.

Just for perspective, I've had AP enabled on 4 machines for about 2 weeks now (before that, MB only) and have all work enabled and set up in app_info files. In that time period, 2 of the 4 have gotten one request of work filled with MB WUs each. One of the 2 got 12 tasks, the other got 18, I believe. The other 2 have only gotten AP, and for all 4, it's been only AP 5.03 (as far as I've noticed). Before enabling AP, I didn't notice any issues getting MB work, so based on that, I would say the system is set up to strongly favor the allocation of AP and would seem to only send out MB (in the case where all work is allowed) if there is a momentary lack of AP. Just my un-scientific observation...

-Dave

---

Oh, one question, It seems like, since getting the optimizer, that I'm only getting astropulse tasks. Is this standard or should I still be getting both?

Only if your app_info.xml file includes entries for both. That's the first thing to check.

F.

I'm not sure what to look for, exactly...

The app_info.xml file starts with the seti_enhanced app version 603

After that is the astropulse app version 500.

Then the astropulse_v5 version 503.

~C

That's exactly what to look for, and you've answered Fred's question prefectly. At least with a Mac we don't have to worry about CUDA ... yet ...

You should be capable of dealing with both (all three) types of task. After that, it's the luck of the draw which one you get allocated by the server. Just at the moment, as others have commented, the server seems to be drawing straight Astropulses.

You could test it, if you wanted to see a bit of variety, by temporarily forbidding AP tasks in the preferences in your account on this website (you can't do that through BOINC Manager). Such a change woudln't affect any tasks you have already downloaded, but it will influence any future work the server sends you.

Yes, Laptop C2D getting straight Astropulse_v5's,
and the Desktop C2D (with development build of Boinc) is just getting Astropulse_v5 with it's CPU requests, (if it'll actually ask for CPU work),
and GPU requests get lots of Multibeam (Obviously)

Claggy