Yes, technically we shouldn't call them GUPPI as the format should be BLC but we (and I especially am bad about doing this) call them GUPPIs

The issue with that, is they can also have the BLC at the beginning of the file name and instead of GUPPI have MESSER (sp?) or one of the others in the middle so technically we shouldn't call them all GUPPIs.

I apologize to all as I set a bad example of using this term...I got lazy, but breakthrough listen got too much to keep typing, lol...

---

really don't know what guppis are.. :-(

I think you might have had your "tongue in cheek" on the comment ... but in case you don't know the acronyms, the GUPPI tasks, which always have guppi in the task name are all from the Green Bank Telescope which the project added about 3 months ago. They are almost always VLARs or Very Low Angle Range because the telescope is looking at a fixed point in the sky, different from the tasks coming from the Arecibo telescope which always has the sky moving relative to the telescope pointing position. Guppis have proven to be much harder to process as they are more compute intensive. That leads to much longer task completion times on the GPU. Unfortunately, the GUPPI tasks "pay" the same amount of credit as Arecibo tasks. This has led to an stupendous fall in RAC for most dedicated crunchers. This has led to many unhappy Setizens who crunch for credit and not just for the science.

[Edit] What Zalster said in reference to naming conventions.

---

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

A proud member of the OFA (Old Farts Association)

Yes, technically we shouldn't call them GUPPI as the format should be BLC but we (and I especially am bad about doing this) call them GUPPIs

The issue with that, is they can also have the BLC at the beginning of the file name and instead of GUPPI have MESSER (sp?) or one of the others in the middle so technically we shouldn't call them all GUPPIs.

I apologize to all as I set a bad example of using this term...I got lazy, but breakthrough listen got too much to keep typing, lol...

. . It is not just a matter of laziness ... some of us {me for eg} like calling them guppies. The imagery of thousands of tiny fishies swimming out through the internet to host machines is just too easily visualised and much easier than Greenbank Breakthrough Listen Capture.

. . Now we need a good name for Normal AR Arecibo WUs. Does anyone like Naarwus :)

.

really don't know what guppis are.. :-(

I think you might have had your "tongue in cheek" on the comment ... but in case you don't know the acronyms, the GUPPI tasks, which always have guppi in the task name are all from the Green Bank Telescope which the project added about 3 months ago. They are almost always VLARs or Very Low Angle Range because the telescope is looking at a fixed point in the sky, different from the tasks coming from the Arecibo telescope which always has the sky moving relative to the telescope pointing position. Guppis have proven to be much harder to process as they are more compute intensive. That leads to much longer task completion times on the GPU. Unfortunately, the GUPPI tasks "pay" the same amount of credit as Arecibo tasks. This has led to an stupendous fall in RAC for most dedicated crunchers. This has led to many unhappy Setizens who crunch for credit and not just for the science.

[Edit] What Zalster said in reference to naming conventions.

. . But it would be nice if the credit awarded by the crediting system actually bore a consistent and proportional relationship to the work we are doing. Otherwise it serves no purpose I can see ... as a measure of productivity or actual machine output it gets an "F".

. . Gripe over.

. . It is not just a matter of laziness ... some of us {me for eg} like calling them guppies. The imagery of thousands of tiny fishies swimming out through the internet to host machines is just too easily visualised and much easier than Greenbank Breakthrough Listen Capture.
. . Now we need a good name for Normal AR Arecibo WUs. Does anyone like Naarwus :)

lol very nice visual indeed!
Arecibos are on the way out so it seems a bit late to start giving them a nickname
(...coming from the guy who baptized them nonVLARs!!! ;-D )

You might want to start lobbying Breakthough Listen for what to name the tasks for the Aussie telescope data before that starts flowing to us S@h minions! (There's another visual hahaha)

[edit]
I just thought BTL would have been a better mnemonic than BLC.
BTL = Bacon, Tomato & Lettuce
...oops sorry, that's a BLT...my bad

On a side note...actually, a total tangent:
I re-baptized last week any prog that reassigns tasks to a different device queue (CPU or GPU) as a DeviceQueueOptimizer (DQO)
...but then I had one of my favourites: A Dairy Queen Blizzard (DQB)
which got me thinking of using that acronym instead of DQO...
but I have yet to come up with a good word starting with B.
Technically, a DQO is part of a larger potential category that does:
Boinc Client DeviceQueueReAssignment for any Boinc Project that uses CPU & GPU.

So maybe someone feels a bit more inspired than me...cuz BCDQRA doesn't seem to be short enough and a good mnemonic!
{time for a 2nd coffee now that the sky is no longer dark blue}
[/e]

---

[edit]PS: OMG, I just realized the trick could might be useful to NEVER run dry during Tuesday maintenance!
...on power rigs who currently starve, like Al's LotzaCores[/e]

Won't help in the slightest. The 'trick' - getting ghost tasks resent by re-reporting completed tasks - requires the scheduler to re-send all the meta-data (<workunit> and <result>). And it won't allocate any tasks beyond the 'maximum in progress' limit - under normal operation - whether they're resends or fresh allocations.

And the scheduler is the daemon which is disabled during maintenance. If you got the allocation before maintenance started, you can still complete the downloads afterwards, but you can't access the metadata any which way unless the scheduler is active, or you have a backup client_state file from before you ghosted the tasks.

That's one reason for not doing the riskier sorts of local maintenance - like installing new applications - during the Berkeley maintenance.

Thanks Richard.

I have a few Qs about your post's details
...but I'll wait until after WoW
...and after I've read the documentation you refered me to in another post:
https://setiathome.berkeley.edu/forum_thread.php?id=80127&postid=1809722

"Keep Calm and carry Crunch On!"
R :-D

---

[edit]PS: OMG, I just realized the trick could might be useful to NEVER run dry during Tuesday maintenance!
...on power rigs who currently starve, like Al's LotzaCores[/e]

Won't help in the slightest. The 'trick' - getting ghost tasks resent by re-reporting completed tasks - requires the scheduler to re-send all the meta-data (<workunit> and <result>). And it won't allocate any tasks beyond the 'maximum in progress' limit - under normal operation - whether they're resends or fresh allocations.

And the scheduler is the daemon which is disabled during maintenance. If you got the allocation before maintenance started, you can still complete the downloads afterwards, but you can't access the metadata any which way unless the scheduler is active, or you have a backup client_state file from before you ghosted the tasks.

That's one reason for not doing the riskier sorts of local maintenance - like installing new applications - during the Berkeley maintenance.

. .

. . It also relies on you having a significant number of ghosted WUs every week to recover. Not something I would like ..........

.

My logs reports that starting from 6.21 CEST ( UTC+2 ) this morning, we're again in WUs shortage ( Project has no task available )
In a couple of hours my credit production, will be slashed, since all my critters with > 32 CPU have no WU's to crunch in queue and CPU's are incresingly idling.
Anyone knows anything ? The server status page reports the AP and one GBT splitters down...
This WOW is really hard to cmplete smoothly :-( !!

A.

Well...that sucks : about 135 of my CPU/GPU tasks are idle at the moment.

I believe that running servers with multiple core is a disadvantage at this point...I wish I was able to accumulate more wu's to crunch..

A.

@GazzaVR:

I also started getting a WU shortage about the same time as you. On this one PC I usually have 10 days of extra WUs but for the last week or so I have just the WUs which are currently running and not a single WU waiting to be run. Another PC has plenty of WUs. I haven't heard of a WU shortage so I have no idea what's up.

---