Another early outrage start and quick recovery even with all them big w/u's. :-)

Cheers.

Another early outrage start and quick recovery even with all them big w/u's. :-)

Took a couple of hours for the splitters to really get going- the ready-to-send buffer actually ran dry for a while till the splitters switched up a few gears.

---

Grant
Darwin NT

Anyone else suffering from an ever growing "pendings" list.
A few weeks ago it was ~3000, now at ~6.5k (tasks actually in hand is still ~1300. - Don't take the "tasks in hand figure as valid as I'm suffering a massive pile of ghosts just now - own fault I upset my front-end firewall and didn't notice for a few hours :-(

---

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

Anyone else suffering from an ever growing "pendings" list.
A few weeks ago it was ~3000, now at ~6.5k (tasks actually in hand is still ~1300. - Don't take the "tasks in hand figure as valid as I'm suffering a massive pile of ghosts just now - own fault I upset my front-end firewall and didn't notice for a few hours :-(

Dunno what's going on there.
My pendings have stayed pretty even, give or take, with 7 rigs running. But no major jump.
State: All (7342) · In progress (2548) · Validation pending (2568) · Validation inconclusive (99) · Valid (2112)

---

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

Anyone else suffering from an ever growing "pendings" list.
A few weeks ago it was ~3000, now at ~6.5k (tasks actually in hand is still ~1300. - Don't take the "tasks in hand figure as valid as I'm suffering a massive pile of ghosts just now - own fault I upset my front-end firewall and didn't notice for a few hours :-(

If you have 'ghosts', then your wingmates have pendings - and vice-versa. As you do, so will you be done to!

The WoW event ended. Some users may have shut down their rigs without emptying the cache.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Anyone else suffering from an ever growing "pendings" list.
A few weeks ago it was ~3000, now at ~6.5k (tasks actually in hand is still ~1300. - Don't take the "tasks in hand figure as valid as I'm suffering a massive pile of ghosts just now - own fault I upset my front-end firewall and didn't notice for a few hours :-(

If you have 'ghosts', then your wingmates have pendings - and vice-versa. As you do, so will you be done to!

. . There is a relatively simple, if tedious, way to recover your ghosted tasks. The really tedious part is that you only get 20 at a time and if there are lots them then you have to repeat it over and over. But it will clear up the numbers for everybody involved.

. . The actual process is in a file on another rig so I cannot repeat it at the moment.

Stephen

.

The WoW event ended. Some users may have shut down their rigs without emptying the cache.

. . That is true, and a very annoying and unnecessary thing to do. Good etiquette is to empty a machine's cache before shutting it down. Off course this is not possible in the event of hardware failure but how often is that the case?

Stephen

:(

I too thought it was fall-out from WOW, but on a computer with ~1700 pendings only about 250 date back that far, with the majority being from the last 7 days.

---

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

My oldest pendings go back to the last week of July which I hope will clear out this week if the wingmen report on time. And don't forget the validation servers had a hiccup on Aug 8-9 and missed all validations on those days. Have to wait for the original deadlines to pass to clear the validators on the second pass.

---

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

A proud member of the OFA (Old Farts Association)

There is a relatively simple, if tedious, way to recover your ghosted tasks. The really tedious part is that you only get 20 at a time and if there are lots them then you have to repeat it over and over. But it will clear up the numbers for everybody involved.

. . The actual process is in a file on another rig so I cannot repeat it at the moment.

Stephen

.

This is what I do to recover ghosts WUs, text is copied from someone else, dont remember who...

As an alternative to the "ghost" recovery process that I had previously posted quite a while back (involving client_state backup and restore, etc.), I have another one to offer that I think is simpler and can be entirely controlled within BOINC Manager. It just requires a fast finger on your mouse button, since the key here is to interrupt a scheduler request before it completes. I just used this quite successfully over the weekend to recover 127 "ghosts" that I had created on Friday when I started trying to run the "Special" app on Linux. I just went back to that machine occasionally when I had a few minutes and ran it when I knew I had room in the queue for at least 20 tasks to be recovered, so 7 times in all. I figured that, since it was my fault for creating the "ghosts", the least I could do was try to recover them as a courtesy to my wingmen.

1) Set "No New Tasks"

2) Make sure you have enough room in your work buffer to accommodate your "ghosts" (up to a maximum of 20 per request). If you're not one of those who typically have a queue which reaches the task limits, simply increasing the size of your work buffer should be sufficient. Otherwise, you'll have to wait until you've reported enough completed tasks to free up the necessary space in your queue.

3) Wait for, or initiate (using Update), a scheduler request that reports at least one completed task.

4) As soon as you see the scheduler request commence, interrupt it by IMMEDIATELY clicking "Suspend network activity". I find it easiest to first open the "Activity" menu drop-down and, while keeping my mouse pointer poised over "Suspend network activity", keep a close eye on the Event Log awaiting the start of the scheduler request. Then, as soon as the scheduler request commences, just CLICK.

If successful, the Event Log will show lines like this, and stop:
-------------------------------------------------
Sending scheduler request: To fetch work.
Reporting 1 completed tasks
Requesting new tasks for CPU and NVIDIA GPU
Not requesting tasks: "no new tasks" requested via Manager
Suspending network activity - user request
-------------------------------------------------

If you get a "Scheduler request completed" line before the "Suspending network activity" line, you weren't quick enough. For me, at least, that hasn't been a problem.

5) To be on the safe side, at this point, I usually Exit BOINC completely, shutting down all running tasks, wait a minute or so, then restart BOINC. Note that network activity should still be suspended when BOINC resumes. You should also still see your task(s) "Ready to report".

6) "Allow New Tasks"

7) Resume network activity (always, or based on preferences, whichever is normal for you). If a scheduler request isn't triggered automatically, click "Update". The Event Log should now show something such as:
-------------------------------------------------
Sending scheduler request: To fetch work.
Reporting 1 completed tasks
Requesting new tasks for CPU and NVIDIA GPU
Scheduler request completed: got 4 new tasks
Resent lost task blc4_2bit_guppi_57432_24865_PSR_J1136+1551_0002.22874.831.18.27.49.vlar_1
Resent lost task blc4_2bit_guppi_57432_24865_PSR_J1136+1551_0002.22874.831.18.27.189.vlar_0
Resent lost task blc4_2bit_guppi_57432_25217_HIP57328_0003.22901.831.18.27.241.vlar_0
Resent lost task 01au09aa.11976.21340.7.34.21_1
-------------------------------------------------

followed by the usual task download messages.

NOTE: Since 20 "ghosts" seem to be the maximum that can be retrieved in one request, those with more than 20 "ghosts" will need to repeat the process multiple times, at least 5 minutes apart.

NOTE 2: If any of the "ghost" tasks are Arecibo VLARs, the scheduler may try to send them to an NVIDIA GPU (if you have one), which will fail, marking the task as "Abandoned". At least it's no longer a ghost.

blc04_2bit_blc04_guppi_57898_16542_DIAG_KIC8462852_0017 52.39 GB has been sitting at (108) for a number of days but it does not seem to be slowing splitter progress

---

blc04_2bit_blc04_guppi_57898_16542_DIAG_KIC8462852_0017 52.39 GB has been sitting at (108) for a number of days but it does not seem to be slowing splitter progress

Same for all the other blc_04 data.
Once the blc_05 data was loaded the splitters moved to those files, the only blc_04 WUs i've received since the blc_05 files were loaded have been re-sends.

---

Grant
Darwin NT

blc04_2bit_blc04_guppi_57898_16542_DIAG_KIC8462852_0017 52.39 GB has been sitting at (108) for a number of days but it does not seem to be slowing splitter progress

Same for all the other blc_04 data.
Once the blc_05 data was loaded the splitters moved to those files, the only blc_04 WUs i've received since the blc_05 files were loaded have been re-sends.

That is a factor that I hadn't even considered thanks Grant. At least with only BLC 04 resends going out it will help clean the database up a little bit by removing outstanding results

---

I'm assuming we are in a Arecibo VLAR storm from the splitters since all machines are receiving the "no work is available" message for the past couple of hours.

---

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

A proud member of the OFA (Old Farts Association)

I'm assuming we are in a Arecibo VLAR storm from the splitters since all machines are receiving the "no work is available" message for the past couple of hours.

. . Have you done the "kick the servers in the pants" thing yet??

. . I find I have to do that regularly and it gets work pretty consistently even when the previous response has been "no work available".

Stephen

??

I just had a look at the logs on my rigs and everything has been very fine here Keith.

Cheers.

No, I haven't. Been watching Nascar and football. It is not usual for ALL machines to need the "kick in the pants" at the same time.

---

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

A proud member of the OFA (Old Farts Association)

Well, that was a chore. Unusual that all machines were synched up with network communication schedules. Had to sequentially go through the "kick in the pants" routine. Still ended up with two machines synched up which doesn't help with hitting the buffer at the same time for the limited 100 tasks available.

---

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

A proud member of the OFA (Old Farts Association)

Still way down on the Linux machine. I got all of 3 task after the kick routine. Down about 200 now.

---

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

A proud member of the OFA (Old Farts Association)