Short WU : Good or Evil ?

Why do shorties burn more electricity ? ...power load averages show a 40 watt increase when short WUs are processing on my gpus.

Why do shorties burn more electricity ? ...power load averages show a 40 watt increase when short WUs are processing on my gpus.

OK, I'll venture an opinion:

Evil, on two grounds -
1) There is very little chance of detecting ET with the very limited signal analysis done on these rapid sky surveys.
2) They clog up every part of SETI processing chain (storage, database, communications) to no very good purpose.

Note that I have no opinion on either power consumed or credit awarded ;)

Why do shorties burn more electricity ? ...power load averages show a 40 watt increase when short WUs are processing on my gpus.

For the kitties, that means the opti app is processing them more efficiently and doing more work in a shorter period of time.
I can watch the killawatt meters on a few of my rigs and can tell right away when they are crunching shorties.
Luv 'em, when AP is not clogging up the pipes and the servers can keep up with the increased demand that shorties create.

Speaking of the kitties, didn't you have some photos posted, showing your cooling setup ?..
love to see that again. looking into whipping up a similar system for this next project o'mine.
Are the chilly kitties fed from one compressor or do they each have their own?

credits/time, in comparison to other longer tasks, is quite good when done on the CPU but terrible on the GPU.

And yes they clog up the comms system, especially when AP's are available.

Hi --- my question has to do with an extremely large number of tasks being run in "high priority" --- what prompts SETI to require older tasks needing to be run like this? Just curious, you know?

Jaye Ellen

I think we need to distinguish between two different types of problem.

Shorties are primarily a communications problem: they tend to be easy to get allocated, but slow to download through our over-congested pipe. We've actually been having something of a 'shorty storm' for the last 36 hours, during the time that people have been saying, in general, that the servers are getting back to normal.

What happened last weekend (3-4 November) was completely difficult. Getting work downloaded (after it had been allocated) was no more difficult than normal: the new problem - and it was new, I've not seen it in many years of posting on these boards - was getting notification of work allocations in the first place.

Although I did see one post speculating that a fault on a router handling the scheduler IP address might have opened a black hole in the scheduler reply network path - and that deserves consideration - the 'scheduler reply timeout problem' didn't feel to me like a communications problem. Instead, it felt as if the scheduler wasn't assembling and despatching the reply messages at all. I think that's where the finger pointing at the AP splitters comes from: the splitter processes themselves constipating the server, rather than the data they produce constipating the comms link.

This morning, Brad commented that 'The Lab has Synergy loaded down heavy here of late': I think it would be helpful to at least try the system with a lighter load on whichever server runs the scheduling service for the duration.

I think we need to distinguish between two different types of problem.

Shorties are primarily a communications problem: they tend to be easy to get allocated, but slow to download through our over-congested pipe. We've actually been having something of a 'shorty storm' for the last 36 hours, during the time that people have been saying, in general, that the servers are getting back to normal.

What happened last weekend (3-4 November) was completely difficult. Getting work downloaded (after it had been allocated) was no more difficult than normal: the new problem - and it was new, I've not seen it in many years of posting on these boards - was getting notification of work allocations in the first place.

Although I did see one post speculating that a fault on a router handling the scheduler IP address might have opened a black hole in the scheduler reply network path - and that deserves consideration - the 'scheduler reply timeout problem' didn't feel to me like a communications problem. Instead, it felt as if the scheduler wasn't assembling and despatching the reply messages at all. I think that's where the finger pointing at the AP splitters comes from: the splitter processes themselves constipating the server, rather than the data they produce constipating the comms link.

This morning, Brad commented that 'The Lab has Synergy loaded down heavy here of late': I think it would be helpful to at least try the system with a lighter load on whichever server runs the scheduling service for the duration.

And my belief is that new up/download servers will fix a lotta woes.
There are just too many demands being placed on the hardware in place at the moment.
Ya gotta give them some breathing room.
____________
******

"Ask not, what your kitty can do for you. Ask what you can do for your kitty."

As it is kitten, so shall it be done.

I very much doubt that it is the AP stream that is causing the problem just now - there haven't been any APs split for a couple of days, and I'm still getting a fairly poor response from the servers - quite a high time-out count, downloads hanging around for hours, uploads going into re-try and taking a long time, not to mention an increasing number of tasks awaiting validation.
____________
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?