running out of work...and on a non-maintenance day...

And what work there is, is almost all Arecibo. Very little GBT at all.

Won't be much of a WOW event if they can't get any work.

---

Grant
Darwin NT

I just went through my logs here and I havn't had any issues getting work since our extended outrage ended and I also have plenty of GBT onboard so it must be that quirky problem you fellows have been battling this year.

Cheers.

I just went through my logs here and I havn't had any issues getting work since our extended outrage ended and I also have plenty of GBT onboard so it must be that quirky problem you fellows have been battling this year.

Cheers.

Yes same here, my machines are not in the same league as some here but every time I see complaints about not getting work my old machines are usually full as they are now.

Just watched my 970 finish two tasks and get two more

Seems like there is problem with work being sent out...

. . LOL, when is there not?

Stephen

:)

running out of work...and on a non-maintenance day...

And what work there is, is almost all Arecibo. Very little GBT at all.

Won't be much of a WOW event if they can't get any work.

. . If it cheers you up, 66% of the tasks I have are GBT work.

Stephen

:(

I have tried the flipping of applications and TBar method of hitting update 3 times rapidly just as the computer requests work and nothing has persuaded the scheduler to send me work.

I just tried TBars' repeated requests, then picked up 49, and then 12 WUs on the following requests.
Seem ridiculous, but it's worked every time I've tried it so far.


EDIT-
And the even weirder thing is that once you get that initial dump of outstanding work, the Scheduler will then continue to send replacement work as you return it. At least until the next time it gets stupid.

---

Grant
Darwin NT

. . If it cheers you up, 66% of the tasks I have are GBT work.

Stephen

:(

Since I don't reschedule, it makes no difference to me. I just want work, lol... Was down to 12 work units before it finally decided to give me some more...

Yeah, if it keeps this up, the WOW isn't going to be very much fun...

---

I have tried the flipping of applications and TBar method of hitting update 3 times rapidly just as the computer requests work and nothing has persuaded the scheduler to send me work.

I just tried TBars' repeated requests, then picked up 49, and then 12 WUs on the following requests.
Seem ridiculous, but it's worked every time I've tried it so far.


EDIT-
And the even weirder thing is that once you get that initial dump of outstanding work, the Scheduler will then continue to send replacement work as you return it. At least until the next time it gets stupid.

I think there is a timing issue with TBar's method. You have to hit the sequence just right. I managed to get it work on my 5th or 6th try and started getting work. The Linux machine is back to a full cache.

Now the two Windows 7 machines are down in work with no tasks available. Was away for an hour and will have to try TBar's technique on those machines.

---

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

A proud member of the OFA (Old Farts Association)

I think there is a timing issue with TBar's method. You have to hit the sequence just right.

Definitely.

---

Grant
Darwin NT

I think there is a timing issue with TBar's method. You have to hit the sequence just right.

Definitely.

What I have found is there needs to be 2 'empty' reports where no tasks are sent back. If you have tasks to report, it takes 3 updates. And wait for updates to complete before the next one.
EDIT: And sometimes flipping prefs, and double reporting doesn't work, but a restart resets things - grrr!

What I have found is there needs to be 2 'empty' reports where no tasks are sent back.

Possibly.
I just do as Tbar posted.
Update, then as soon as it says "Scheduler request in progress", Update again, then once the request is finished, Update again.
So far, so good.

And to add to the usual Scheduler woes, I notice my Pendings are gradually going through the roof. Usually around 750, now up over 1,000.

---

Grant
Darwin NT

And to add to the usual Scheduler woes, I notice my Pendings are gradually going through the roof. Usually around 750, now up over 1,000.

Very likely due to "bunkering" for the WOW event.

I think there is a timing issue with TBar's method. You have to hit the sequence just right.

Definitely.

What I have found is there needs to be 2 'empty' reports where no tasks are sent back. If you have tasks to report, it takes 3 updates. And wait for updates to complete before the next one.
EDIT: And sometimes flipping prefs, and double reporting doesn't work, but a restart resets things - grrr!

I think there is some truth to this observation now that I think about it. It helps to have those "empty" reports where nothing is sent back.

---

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

A proud member of the OFA (Old Farts Association)

I wish I had some advice for everybody here, but alas I do not.
I don't wish to jinx myself, but I have never had any problem getting work except when RTS was empty and nobody was getting much work.

I am using an old tried and true version of Boinc. I can't imagine that the work requests from the old Boinc are different than from a recent version, or that the scheduler would treat them any differently.
I am using XP on 4 rigs, and 7 on my daily driver. No difference there.
I am using the most recent version of the Lunatics installer.

I dunno. Maybe the scheduler just says 'Make way, it's the kittyman calling'...............LOL.

Meow meow meow.

---

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

I, too, have tried to avoid "jinxing" myself by commenting on this issue, as I've never had a problem keeping the work buffers full (or close to it) except when the feeder was clogged with Arecibo VLARs. However, yesterday my #1 cruncher actually ran out of GPU work late in the afternoon. Fortunately, it reached that point about 5 minutes before its scheduled weekday afternoon shutdown (avoiding peak period electric rates). When it came back up 5 hours later, it filled the buffer in 2 requests, 176 tasks in the first and 127 in the second. I tend to believe that Arecibo VLARs were the primary culprit again yesterday, but then that probably wouldn't explain the responses that said the limit of tasks in progress had been reached when, in fact, the work buffer was steadily shrinking to zero.

Since refraining from comment ultimately didn't avoid the jinx, I'll go ahead and mention the following, for what it's worth. I haven't touched my settings in a long, long time, probably a couple years. My application preferences are "Yes, Yes, No" and my work buffer is 1.8 days plus 0.2 days. Also, assuming that the project shares might somehow play into the scheduler's decision-making, I have no active backup projects that might possibly muddy the waters.

That's about it, for whatever bit of insight it might provide.

Since refraining from comment ultimately didn't avoid the jinx, I'll go ahead and mention the following, for what it's worth. I haven't touched my settings in a long, long time, probably a couple years. My application preferences are "Yes, Yes, No" and my work buffer is 1.8 days plus 0.2 days. Also, assuming that the project shares might somehow play into the scheduler's decision-making, I have no active backup projects that might possibly muddy the waters.

That's about it, for whatever bit of insight it might provide.

What I wonder based on your comments and kittyman's is that you both have no backup projects muddying the waters as you say with shared resources to other projects. I have always had my resources split between SETI, Einstein and MilkyWay. I would need to look at all the others profiles that have this issue to see if it is a common factor.

---

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

A proud member of the OFA (Old Farts Association)

I wish I had some advice for everybody here, but alas I do not.
I don't wish to jinx myself, but I have never had any problem getting work except when RTS was empty and nobody was getting much work.

I am using an old tried and true version of Boinc. I can't imagine that the work requests from the old Boinc are different than from a recent version, or that the scheduler would treat them any differently.
I am using XP on 4 rigs, and 7 on my daily driver. No difference there.
I am using the most recent version of the Lunatics installer.

I dunno. Maybe the scheduler just says 'Make way, it's the kittyman calling'...............LOL.

Meow meow meow.

Pretty early on things like BOINC and OS versions were discussed to try and pinpoint their issue.
Nothing has really made sense as to why only a few users are having issues.
The only thing I can think of at this point is that there is some weirdness along their route connecting to Berkley.

---

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

Pretty early on things like BOINC and OS versions were discussed to try and pinpoint their issue.
Nothing has really made sense as to why only a few users are having issues.
The only thing I can think of at this point is that there is some weirdness along their route connecting to Berkley.

You allude to connectivity issues being the problem. But if you don't connect to Berkeley, then you obviously couldn't get the responses we receive that you have reached a limit of tasks in progress or that there are no tasks to send.

---

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

A proud member of the OFA (Old Farts Association)

That is true for me.
I have backup projects loaded if Seti were to go down for an extended period of time.
However, none is active. For now, if Seti runs dry, the rigs just take a rest.

Meow.

---

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

Pretty early on things like BOINC and OS versions were discussed to try and pinpoint their issue.
Nothing has really made sense as to why only a few users are having issues.
The only thing I can think of at this point is that there is some weirdness along their route connecting to Berkley.

You allude to connectivity issues being the problem. But if you don't connect to Berkeley, then you obviously couldn't get the responses we receive that you have reached a limit of tasks in progress or that there are no tasks to send.

Connectivity issues can be a lot more complicated than simply connection vs no connection.
If the data is malformed or truncated you can still get a response, but it likely won't be what is expected.
Not receiving a "Not sending work - last request too recent:" response after performing several updates would indicate something is being lost.

---

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