Panic Mode On (84) Server Problems?

Message boards : Number crunching : Panic Mode On (84) Server Problems?
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 15 · 16 · 17 · 18 · 19 · 20 · 21 · Next

AuthorMessage
Cosmic_Ocean
Avatar

Send message
Joined: 23 Dec 00
Posts: 3027
Credit: 13,516,867
RAC: 13
United States
Message 1390020 - Posted: 12 Jul 2013, 8:15:36 UTC

Personally.. I don't care about credits or RAC at all. Zero. I don't even keep up with how much I have of either. In fact, when I crossed 5M a while back, I didn't even know about it until I happened to make a post in one of these panic threads and saw that I was at ~5.2M and I thought "oh... cool, I guess I hit 5M a few weeks ago.. neat."

The only concerns I keep up with is "how many WUs do I have? Do I have any errors or invalid results and if so, does that indicate a problem or is it just random?"

Personally.. I like APs because it means less files even if it is a lot more bytes, but it also means that I can hold a 10-day cache (~60 APs if my DCF is stable) and not be affected by the limits. If I were to allow MBs, a cache limited by the server would probably only be about 3 days..maybe. When the project moved to the co-lo, I burnt through 17 APs and still had a little over 40 ready to be crunched. Only thing I did on my end was just set BOINC to "suspend network communications" until the servers came back online.

I don't use a GPU and I don't have the best CPU either, but I do what I can with what I've got. If you're in this game for the credits or the RAC, then you don't care about the science, and there are other projects that give more credits/FLOP than this one, so why are you here?

My 2 cents.
Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)
ID: 1390020 · Report as offensive
bill

Send message
Joined: 16 Jun 99
Posts: 861
Credit: 29,352,955
RAC: 0
United States
Message 1390024 - Posted: 12 Jul 2013, 8:38:14 UTC - in response to Message 1390002.  
Last modified: 12 Jul 2013, 8:38:39 UTC

Mark,

Do you remember when people were refusing
to do AP work units because they took too
long? Hurr,hurr,hurr. I wonder if they were
gaming the system then?

http://www.youtube.com/watch?v=qi9sLkyhhlE

Appropriate, no?
ID: 1390024 · Report as offensive
Thomas
Volunteer tester

Send message
Joined: 9 Dec 11
Posts: 1499
Credit: 1,345,576
RAC: 0
France
Message 1390025 - Posted: 12 Jul 2013, 8:39:22 UTC - in response to Message 1390020.  

We are all here to advance the SETI@home project and the Science.
And the Science imports me more than the RAC.
But I'm going to speak to you as Founder of team and thus as motivator of troops : the RAC is very important for a lot of members because it's the only means to quantify their participation to the SETI@home project. Many members invest in high-technology equipment to crunching better. And their only reward is the RAC while waiting to discover the signal of one extraterrestrial intelligence. I thus think that it cannot amount to a simple history of "I don't care of the RAC" or "The RAC is very important". Everybody is there to advance the Science and the RAC realizes the investment of each. It's thus normal to be attached to it. It's a whole balance.
ID: 1390025 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1390057 - Posted: 12 Jul 2013, 12:00:07 UTC - in response to Message 1389999.  
Last modified: 12 Jul 2013, 12:11:59 UTC

The solution is to fix the credit system. When this is done, people will stop trying to game the system and things should settle towards a natural equilibrium.

The other solution is to make autocorrelation code faster in the Stock apps, so the Stock apps aren't so inefficient at doing v7 work (especially the GPU apps, especially shorties), NewCredit is basically working as designed.

http://setiathome.berkeley.edu/forum_thread.php?id=72169&postid=1387022

My understanding (please correct me if I am wrong:-)) on day 1 The stock CPU apps for MBV7 are the optimized apps used for V6 plus AVX for even faster Stock MB application...

The stock Sah v7 CPU app primarily differs from the stock Sah v6 CPU app by the addition of code to do the Autocorrelation search. There were also some AVX functions added and it is linked to a newer version of FFTW which also supports AVX. Both stock CPU apps do have considerable optimization, but that is done in a manner allowing the same application to run well on a wide variety of systems.

The relative speed of the stock apps is certainly pertinent to a discussion of CreditNew, because CPU efficiency is higher than GPU efficiency as Dr. Anderson conceives the term. Two quotes from the CreditNew wiki page are pertinent:

GPUs typically have a higher (10-100X) peak FLOPS than CPUs. However, application efficiency is typically lower (very roughly, 10% for GPUs, 50% for CPUs).

If an application has both CPU and GPU versions, the version normalization mechanism figures out which version is most efficient and uses that to reduce the credit granted to less-efficient versions.

The v6 and v7 CPU apps are about the same speed when doing v6 tasks, with a small advantage to the v7 version on hosts with AVX capability. The added time of Autocorrelations on CPU is somewhat less than a 10% increase averaged over all angle ranges. On GPU the impact of Autocorrelations is much greater, which translates into a serious loss of efficiency as Dr. Anderson conceives it.


http://setiathome.berkeley.edu/forum_thread.php?id=72169&postid=1387059

For my two cents in that context, I'm pleased to see Dr A's theories matching reality, since algorithmically both the CPU & GPU autocorelations are order O(nlogn) , however my baseline/reference 'get it working' GPU autcorrelation implementation uses the 4nfft approach, so becomes 4x(nlogn). It's then pretty easy to see how 10% becomes 40%. A tasty Type 2 DCT kernel with attention to max bandwidth and cache locality should improve that handily, once all the dust has settled and other fires extinguished.


Claggy
ID: 1390057 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
Message 1390065 - Posted: 12 Jul 2013, 12:18:18 UTC - in response to Message 1390057.  
Last modified: 12 Jul 2013, 12:26:29 UTC

... NewCredit is basically working as designed.

In other words... The random number generator is working fine...

There are any other rational explanation to understand why, in the same host, a faster to crunch WU (less processing time) receive more credit than a slower (more processing time)?
ID: 1390065 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1390069 - Posted: 12 Jul 2013, 12:37:52 UTC - in response to Message 1390065.  

... NewCredit is basically working as designed.

In other words... The random number generator is working fine...

There are any other rational explanation to understand why, in the same host, a faster to crunch WU (less processing time) receive more credit than a slower (more processing time)?

depends on the app versions involved:

since credit is granted based on the most efficient app version


Claggy
ID: 1390069 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
Message 1390070 - Posted: 12 Jul 2013, 12:40:53 UTC - in response to Message 1390069.  
Last modified: 12 Jul 2013, 12:43:46 UTC

... NewCredit is basically working as designed.

In other words... The random number generator is working fine...

There are any other rational explanation to understand why, in the same host, a faster to crunch WU (less processing time) receive more credit than a slower (more processing time)?

depends on the app versions involved:

since credit is granted based on the most efficient app version


Claggy

The same app, i only use cuda50... and processed by the same GPU... the host have 2x690... but don´t loose your time, i stop trying to understand how realy creditnew works a long time ago... I just keep crunching...
ID: 1390070 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1390072 - Posted: 12 Jul 2013, 12:52:52 UTC - in response to Message 1390070.  
Last modified: 12 Jul 2013, 12:54:00 UTC

The same app, i only use cuda50... and processed by the same GPU... the host have 2x690

But your wingmen won't be using the same app every time, if all your wingmen used the Stock CPU app then you'll get consistent credit since that will be the most efficient app_version involved, but some of them use one of the GPU apps, then it's a pissing contest between you and your wingman to decide the who has the most efficient app_version (for that single Wu) and since the GPU apps are less efficient than the CPU apps, so less credit.

Claggy
ID: 1390072 · Report as offensive
Ulrich Metzner
Volunteer tester
Avatar

Send message
Joined: 3 Jul 02
Posts: 1256
Credit: 13,565,513
RAC: 13
Germany
Message 1390074 - Posted: 12 Jul 2013, 13:02:15 UTC - in response to Message 1390072.  

(...) and since the GPU apps are less efficient than the CPU apps, so less credit.
So the slower stock app is more "efficient" than the faster app regarding the same result?
Well, this completely defies *my* former understanding of efficiency as such.
I think, i don't have to understand this - like many others as well...

*meshakinghead*
Aloha, Uli

ID: 1390074 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1390077 - Posted: 12 Jul 2013, 13:06:42 UTC - in response to Message 1390074.  
Last modified: 12 Jul 2013, 13:07:59 UTC

(...) and since the GPU apps are less efficient than the CPU apps, so less credit.
So the slower stock app is more "efficient" than the faster app regarding the same result?
Well, this completely defies *my* former understanding of efficiency as such.
I think, i don't have to understand this - like many others as well...

*meshakinghead*
For their high peak FLOPs, they aren't as fast as they should be:

GPUs typically have a higher (10-100X) peak FLOPS than CPUs. However, application efficiency is typically lower (very roughly, 10% for GPUs, 50% for CPUs).


Claggy
ID: 1390077 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51478
Credit: 1,018,363,574
RAC: 1,004
United States
Message 1390081 - Posted: 12 Jul 2013, 13:10:49 UTC

LOL...
I long ago quit trying to understand CreditNew.
I just crunch 'em up and spit 'em out and whatever everybody's favorite random number generator spits out is what I getz.
"Time is simply the mechanism that keeps everything from happening all at once."

ID: 1390081 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
Message 1390082 - Posted: 12 Jul 2013, 13:17:39 UTC - in response to Message 1390072.  
Last modified: 12 Jul 2013, 13:50:07 UTC

The same app, i only use cuda50... and processed by the same GPU... the host have 2x690

But your wingmen won't be using the same app every time, if all your wingmen used the Stock CPU app then you'll get consistent credit since that will be the most efficient app_version involved, but some of them use one of the GPU apps, then it's a pissing contest between you and your wingman to decide the who has the most efficient app_version (for that single Wu) and since the GPU apps are less efficient than the CPU apps, so less credit.

Claggy

Sorry i don´t agree with you, that´s not exactly what i see in the logs (validated WU) but no matter it´s a waste of time go deep on that question.

In other hand, I could understand your explanation, but still makes no sense for me, a WU is a WU whatever app´s/host crunch it, is the "human" way to think. If i receive a task to crunch, and i could do the same task in less time than my wingmate, my app/host/GPu is "more efficient" (do the task in less time). So why i receive less credit? just because my wingmate takes days to process the same task, it´s not fair. The work done is the same, slower or faster makes no sense.

The credit of a WU could not depend on what host/app´s it was processed, if you have a faster host/app´s is good for you & the science, you could do more WU per day.

A simple analogy, a pound of anything have the same weith, nomather if it is a pound of iron (a small amount) or cotton (a large amount) and the instrument you use to measure... think on that... that´s why creditnew fails if you look by "humman eyes"... but as we are talking about "ET´s"... forget all... Go for a beer and keep crunching...

@Ulrich Metzner... I totaly agree with you... that bug´s my mind too, maybe we all need back to the ET mad science school to understad why a faster host is less efficience than a slower host if they produce the same resoult...

@Mark... You are right, Keep the kitties happy by crunching anything they could send. It´s a waste of time to try to understand the way creditnew random number generator works. And congrats again for the SETI #1 place. The kitties flag shinning at the top of the hill.
ID: 1390082 · Report as offensive
Rolf

Send message
Joined: 16 Jun 09
Posts: 114
Credit: 7,817,146
RAC: 0
Switzerland
Message 1390166 - Posted: 12 Jul 2013, 16:16:08 UTC - in response to Message 1389999.  

The solution is to fix the credit system. When this is done, people will stop trying to game the system and things should settle towards a natural equilibrium.

The only solution is to fix the credit system.
ID: 1390166 · Report as offensive
Sleepy
Volunteer tester
Avatar

Send message
Joined: 21 May 99
Posts: 219
Credit: 98,947,784
RAC: 28,360
Italy
Message 1390180 - Posted: 12 Jul 2013, 16:52:02 UTC

Let's put it this way:

You go to the grocer's and you wait 5 minutes before the other customers buy their things. You ask for 100g of ham. They ask you 2$. You pay 2$

Then you go to another grocer's.
Here you do not have to wait. You ask 100g of the very same ham. They ask you 2$. But you say that since in this place it was faster, you only give them half. You hand on 1$ and (try to) go away.

What do you think is going to happen before you step out the second shop?

But for CreditNew paying 1$ would perfectly be OK.

100g of ham is 100g of ham.

Happy crunching!

Sleepy
ID: 1390180 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51478
Credit: 1,018,363,574
RAC: 1,004
United States
Message 1390182 - Posted: 12 Jul 2013, 16:54:54 UTC - in response to Message 1390180.  
Last modified: 12 Jul 2013, 16:55:16 UTC

Let's put it this way:

You go to the grocer's and you wait 5 minutes before the other customers buy their things. You ask for 100g of ham. They ask you 2$. You pay 2$

Then you go to another grocer's.
Here you do not have to wait. You ask 100g of the very same ham. They ask you 2$. But you say that since in this place it was faster, you only give them half. You hand on 1$ and (try to) go away.

What do you think is going to happen before you step out the second shop?

But for CreditNew paying 1$ would perfectly be OK.

100g of ham is 100g of ham.

Happy crunching!

Sleepy

Let's put it THIS way....

Since I cannot buy kibble with my Seti creds, the kitties are just fine with whatever the going rate is these days.
"Time is simply the mechanism that keeps everything from happening all at once."

ID: 1390182 · Report as offensive
bill

Send message
Joined: 16 Jun 99
Posts: 861
Credit: 29,352,955
RAC: 0
United States
Message 1390232 - Posted: 12 Jul 2013, 20:08:56 UTC - in response to Message 1390166.  

The solution is to fix the credit system. When this is done, people will stop trying to game the system and things should settle towards a natural equilibrium.

The only solution is to fix the credit system.


The only person who could change creditnew doesn't
seem to consider it broken. Nobody here has
changed his mind.
ID: 1390232 · Report as offensive
Rolf

Send message
Joined: 16 Jun 09
Posts: 114
Credit: 7,817,146
RAC: 0
Switzerland
Message 1390240 - Posted: 12 Jul 2013, 20:49:31 UTC - in response to Message 1390232.  

The solution is to fix the credit system. When this is done, people will stop trying to game the system and things should settle towards a natural equilibrium.

The only solution is to fix the credit system.


The only person who could change creditnew doesn't
seem to consider it broken. Nobody here has
changed his mind.

But I'm sure he knows people are complaining about.
ID: 1390240 · Report as offensive
bill

Send message
Joined: 16 Jun 99
Posts: 861
Credit: 29,352,955
RAC: 0
United States
Message 1390258 - Posted: 12 Jul 2013, 21:29:41 UTC - in response to Message 1390240.  

The solution is to fix the credit system. When this is done, people will stop trying to game the system and things should settle towards a natural equilibrium.

The only solution is to fix the credit system.


The only person who could change creditnew doesn't
seem to consider it broken. Nobody here has
changed his mind.

But I'm sure he knows people are complaining about.


Yes he does. I told him so myself.

But unless someone can show him an error in his code
nothing will change. Merely complaining in the forum will
achieve nothing. I doubt he ever reads this forum.
ID: 1390258 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13854
Credit: 208,696,464
RAC: 304
Australia
Message 1390263 - Posted: 12 Jul 2013, 21:49:38 UTC - in response to Message 1390258.  

But unless someone can show him an error in his code nothing will change.

There isn't an error with the code- it's working as designed. The error is with the design- applying a theoretical concept of efficiency that results in real world devices that are more efficient being penalised by real world devices that are less efficicent.
ie a device that produces more work in a shorter period of time is considered (by the theory) to be less effcient than a device that takes longer to do the same work.
In the real world the slower device is considered less efficient. In the theoretical world based on the potential of the devices, it's not.

Grant
Darwin NT
ID: 1390263 · Report as offensive
bill

Send message
Joined: 16 Jun 99
Posts: 861
Credit: 29,352,955
RAC: 0
United States
Message 1390288 - Posted: 12 Jul 2013, 23:25:56 UTC - in response to Message 1390263.  

But unless someone can show him an error in his code nothing will change.

There isn't an error with the code- it's working as designed. The error is with the design- applying a theoretical concept of efficiency that results in real world devices that are more efficient being penalised by real world devices that are less efficicent.
ie a device that produces more work in a shorter period of time is considered (by the theory) to be less effcient than a device that takes longer to do the same work.
In the real world the slower device is considered less efficient. In the theoretical world based on the potential of the devices, it's not.


We're not in the real world. We're in the world of academia.
From the lab side there is nothing wrong.

Now if some one wants to come up with $100.00 USD an hour
to pay the coder in question to come up with a Creditnew
that pleases the complainers something might get done.
Until such time...
ID: 1390288 · Report as offensive
Previous · 1 . . . 15 · 16 · 17 · 18 · 19 · 20 · 21 · Next

Message boards : Number crunching : Panic Mode On (84) Server Problems?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.