Upwards and Onwards (May 28 2009)

Message boards : Technical News : Upwards and Onwards (May 28 2009)
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · Next

AuthorMessage
Andy Williams
Volunteer tester
Avatar

Send message
Joined: 11 May 01
Posts: 187
Credit: 112,464,820
RAC: 0
United States
Message 901065 - Posted: 29 May 2009, 17:49:44 UTC

Presently, it really reduces to this: the project default is handing out APs to people that do not want them, when there are not enough for the people that do want them.

Backwards.
--
Classic 82353 WU / 400979 h
ID: 901065 · Report as offensive
DJStarfox

Send message
Joined: 23 May 01
Posts: 1066
Credit: 1,226,053
RAC: 2
United States
Message 901162 - Posted: 29 May 2009, 22:42:09 UTC - in response to Message 900643.  

The active user base going up may be due to the SETI anniversary buzz.

Perhaps you should do a count of users with MB vs AP selected?

select count(ap), count(mb)
from user_preferences
where rac >= 0.1

I'm curious just to see what the numbers are. The ratio between the two counts should give you a guideline for how fast each splitter should run.
ID: 901162 · Report as offensive
Josh C78

Send message
Joined: 29 May 09
Posts: 14
Credit: 626
RAC: 0
United States
Message 901248 - Posted: 30 May 2009, 2:07:07 UTC
Last modified: 30 May 2009, 2:20:12 UTC

Nice thread I actually learned a lot about *Needs.

My concern was my gpu is a bit older, a retail Asus Overclocked Nvidia 8500GT. So i aborted the MB.? And finished my AP, then now work was available so i re-enabled cuda/gpu, and by that time got more ap and 1 MB :)

My thoughts to myself are;
I have good AP/Processing power, and less MB/Gpu power, so it made sense to do only AP (Am i using/understanding these AP/MB terms correctly?*EDIT can someone explain these to me, here or via pm?thanks).

After looking through this thread, it reassured me in my decision of turning MB/gpu back on.

I would like to see some more information on GPU posted to a FAQ. Is there much difference between a low end cuda capable GPU vs higher end? (To me the obviouos answers of processing power again weighed heavily on my thoughts.)

About users seeing the eta to completion (wether it is my settings or not, unsure). I am finishing tasks in less than half (about 1/3rd) the time of the initial eta to completion.

I appreciate feedback :) thanks

My Video Card Details:
ASUS EN8500GT TOP/HTP/256M
GeForce 8500 GT 256MB 128-bit GDDR3 PCI Express x16 HDCP Ready
Core Clock 600MHz
Stream Processors 16
Memory Clock 1400MHz (700MHz DDR3)
DirectX 10 (unfortunately DX10 is not available in xp.. *rant)
OpenGL 2.0
RAMDAC 400MHz

37% faster than generic GeForce 8500GT
Superior Cooling Efficiency - 18°C cooler than reference design boards
NVIDIA PureVideo HD technology
NVIDIA Quantum Technology
[Xp Pro x64 5.2.3790 SP2]
[Amd Phenom II X3 720]
ID: 901248 · Report as offensive
Cosmic_Ocean
Avatar

Send message
Joined: 23 Dec 00
Posts: 3027
Credit: 13,516,867
RAC: 13
United States
Message 901251 - Posted: 30 May 2009, 2:15:23 UTC - in response to Message 900900.  

Mark, have you looked at the server status page recently?

There are 130 'tapes' listed there: Astropulse has 'done' 128 of them, so they're just sitting there, waiting to be split for MB.

That's something like six terabytes of raw data, being kept online simply because the AP and MB split/issue rates are out of balance.

Although raw storage hasn't been such a problem for the project since the Overland Storage donation, that contribution was 'only' ten terabytes: using over half of that just to keep the kitties supplied with their particular flavour of kibble seems just a touch excessive!

Seriously, wouldn't it be better for the project as a whole if both types of work were consistently available, and split at roughly the same speed?


Looks to me that instead of complaining about lack of AP work. The solution would be for AP loving people, to disable AP in their preferences for a while. In that way they would help greatly to reduce the huge amount of MB's available, and also help themselves to get more AP's much faster.

The huge amount of MB WU's seems to indicate that too many participants have instead disabled MB WU's in their preferences, and thereby helped create the problems they now complain about.

Ok I know AP pays better, but hey this is about science in the first place, and "credits" in the second place.

Sten-Arne

I don't believe it has much to do with people preferring one application over another. The real reason is that there are approximately 200,000 MBs that can be made out of one tape, and significantly less than that for AP out of the same tape. The feeder queue (what supplies the scheduler with tasks when your client asks for work) has been keeping the queue at 50/50, so less MBs were handed out than optimal. The feeder queue needs to be balanced to approximately the same ratio of MB:AP WUs that can be made from a single tape.

Once the B3_P1 issue is behind us, and the data recorder down at Arecibo comes back online, things should start running fairly smoothly, and if you prefer only AP, there shouldn't be any meaningful work shortages.

Also perhaps instead of setting all 4 AP splitters to work on one tape, it could be split up like MB is?
Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)
ID: 901251 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 901365 - Posted: 30 May 2009, 5:28:06 UTC - in response to Message 901251.  

...
Ok I know AP pays better, but hey this is about science in the first place, and "credits" in the second place.

Sten-Arne

I don't believe it has much to do with people preferring one application over another.
...


No? I think there are lot of people out there which crunch AP ONLY because of the 'better' Cr/h.

Look to the top_host_list.. if CPU only PCs (or with 'small/less' GPUs).. AP hunter.. ;-)

I guess since AP better Cr/h than MB, much people out there disabled MB in their preferences.

O.K., it have nothing to do with less AP work than MB creation ratio.. but it's a fact.. :-)

If I would be also a AP hunter.. I guess I will have soon ~ 32,000 - 34,000 RAC only with MB.. if my GPUs would be CPUs.. this would mean ~ 70,000 RAC with AP..
But I don't crunch AP because I can't and I don't want..

ID: 901365 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 901372 - Posted: 30 May 2009, 5:37:01 UTC
Last modified: 30 May 2009, 5:37:56 UTC


@ Josh C78

Have a look in the NC forum..
http://setiathome.berkeley.edu/forum_forum.php?id=10
There we can talk about crunching speed and so on..

Small answer.. yes.. GTX2xx would give the highest crunching performance.

OCed GTX260 Core216 ~ 8,000 RAC.
Stock maybe ~ 7,000 RAC.
A 98xx would have the half RAC.

So, more shader cores and more shader speed.. more power.

ID: 901372 · Report as offensive
Profile -= Vyper =-
Volunteer tester
Avatar

Send message
Joined: 5 Sep 99
Posts: 1652
Credit: 1,065,191,981
RAC: 2,537
Sweden
Message 902402 - Posted: 1 Jun 2009, 8:14:01 UTC
Last modified: 1 Jun 2009, 8:19:02 UTC

For some months ago i thought of the same thing as you are writing now.

That new users which want to try out Seti@home gets an AP wu with perhaps their laptop 2ghz core2 and thinks cool, i got a realtively fast machine, i can contribute and then finds out that it would take more than 24 hours to process one and aborts and uninstall seti..

I agree with the people that says that new users should have AP unticked as default because the original app simply takes so long that there is a risk that people gets "bored" of not getting a credit ticker that moves up.. The psycological factor is to high there, and if they manage to get an AP result ready and sends it in they would perhaps also notice that credit doesn't get higher at all perhaps for a week and also gets fed of it because their credit wasn't given "in time"..

Many people which are novice doesn't know how this things work, they don't care plunging into forums diging out what and why isn't my credit increasing though i let my computer work for more than a day 24/7..

MB work has a realtively short turnaround (from when you deliver and get awarded) .. Lets start with letting people get their credit ticker roling and when they dig further into our forums they'll discover AP (hey why don't let the server be responsible of knowing when new users first login to the website by displaying a greeting message and then simple guidance of contributing in Astropulse but letting them know that due to the longer WU's it also takes longer until their WU gets validated. And perhaps telling of optimised clients but inform that it requires some dedication and skills.)


Well to summarize it.. AP = off for new users .. Let them discover it thorughout the webserver or forums or their options first and let them tick it for themselves.
Then we'll see more people that wishes to stay with s@h instead of leaving because of not knowing the technology enough behind it.

My 2 cents ppl..

Kind regards Vyper

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group
ID: 902402 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
United Kingdom
Message 902461 - Posted: 1 Jun 2009, 11:55:31 UTC - in response to Message 902402.  

....
That new users which want to try out Seti@home gets an AP wu with perhaps their laptop 2ghz core2 and thinks cool, i got a realtively fast machine, i can contribute and then finds out that it would take more than 24 hours to process one and aborts and uninstall seti....

Don't forget that the first AP task that user will get will be with the stock app (so ~80 hours for that machine), but it will be estimated by BOINC at DCF=1.0, rather than the DCF=~0.4 typical for stock AP.

So the estimate in BOINC Manager will say something like 200 hours, deadline 30 days - that's a big committment. Makes your point even more strongly.
ID: 902461 · Report as offensive
Profile FalconFly
Avatar

Send message
Joined: 5 Oct 99
Posts: 394
Credit: 18,053,892
RAC: 0
Germany
Message 902599 - Posted: 1 Jun 2009, 21:18:57 UTC - in response to Message 902461.  
Last modified: 1 Jun 2009, 21:19:26 UTC

Do I understand correctly that they do have a NTPCKR machine already available ?
(I didn't see the mentioned Webcast and it's still posted as required hardware in the Hardware/Case Donation Thread)
ID: 902599 · Report as offensive
Profile ML1
Volunteer moderator
Volunteer tester

Send message
Joined: 25 Nov 01
Posts: 20084
Credit: 7,508,002
RAC: 20
United Kingdom
Message 902843 - Posted: 2 Jun 2009, 9:15:35 UTC - in response to Message 902599.  

Do I understand correctly that they do have a NTPCKR machine already available ? ...

Ahhh... But more of a question is whether the db can take the extra load...

Happy fast crunchin',
Martin

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
ID: 902843 · Report as offensive
Profile FalconFly
Avatar

Send message
Joined: 5 Oct 99
Posts: 394
Credit: 18,053,892
RAC: 0
Germany
Message 902848 - Posted: 2 Jun 2009, 9:59:57 UTC - in response to Message 902843.  

Do I understand correctly that they do have a NTPCKR machine already available ? ...

Ahhh... But more of a question is whether the db can take the extra load...

Happy fast crunchin',
Martin


Does "Ahhh..." mean "Yes" ?
ID: 902848 · Report as offensive
Profile Virtual Boss*
Volunteer tester
Avatar

Send message
Joined: 4 May 08
Posts: 417
Credit: 6,440,287
RAC: 0
Australia
Message 902859 - Posted: 2 Jun 2009, 10:57:21 UTC - in response to Message 902848.  

Does "Ahhh..." mean "Yes" ?


IMHO . . . Yes and No

Yes: There is apparently a NTPCKR running for testing, but whether it is running on it's proper hardware is unknown.

No: The public access page to NTPKR is offline.
ID: 902859 · Report as offensive
Profile FalconFly
Avatar

Send message
Joined: 5 Oct 99
Posts: 394
Credit: 18,053,892
RAC: 0
Germany
Message 902964 - Posted: 2 Jun 2009, 22:22:50 UTC - in response to Message 902859.  

I see from the latest Technical News that intel donated six machines, my best guess is that one will serve as NTPCKR.
ID: 902964 · Report as offensive
Nicolas
Avatar

Send message
Joined: 30 Mar 05
Posts: 161
Credit: 12,985
RAC: 0
Argentina
Message 905860 - Posted: 10 Jun 2009, 17:58:31 UTC - in response to Message 901162.  

Perhaps you should do a count of users with MB vs AP selected?

select count(ap), count(mb)
from user_preferences
where rac >= 0.1

I'm curious just to see what the numbers are. The ratio between the two counts should give you a guideline for how fast each splitter should run.

Due to non-normalized database layout (user preferences are in a XML blob), it's not that easy to know what users selected what apps.

Contribute to the Wiki!
ID: 905860 · Report as offensive
Nicolas
Avatar

Send message
Joined: 30 Mar 05
Posts: 161
Credit: 12,985
RAC: 0
Argentina
Message 905864 - Posted: 10 Jun 2009, 18:00:33 UTC - in response to Message 902461.  

Don't forget that the first AP task that user will get will be with the stock app (so ~80 hours for that machine), but it will be estimated by BOINC at DCF=1.0, rather than the DCF=~0.4 typical for stock AP.

If stock apps don't have DCF=~1, it means the run time estimate is WRONG, and the admins should fix it.


Contribute to the Wiki!
ID: 905864 · Report as offensive
Profile KWSN THE Holy Hand Grenade!
Volunteer tester
Avatar

Send message
Joined: 20 Dec 05
Posts: 3187
Credit: 57,163,290
RAC: 0
United States
Message 905882 - Posted: 10 Jun 2009, 18:40:57 UTC - in response to Message 905864.  

Don't forget that the first AP task that user will get will be with the stock app (so ~80 hours for that machine), but it will be estimated by BOINC at DCF=1.0, rather than the DCF=~0.4 typical for stock AP.

If stock apps don't have DCF=~1, it means the run time estimate is WRONG, and the admins should fix it.


To be fair, I don't think that DCF has changed since the start of BOINC, when HT P4's were the cutting edge of state-of-the-art.

.

Hello, from Albany, CA!...
ID: 905882 · Report as offensive
1mp0£173
Volunteer tester

Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 906011 - Posted: 10 Jun 2009, 23:58:20 UTC - in response to Message 905864.  

Don't forget that the first AP task that user will get will be with the stock app (so ~80 hours for that machine), but it will be estimated by BOINC at DCF=1.0, rather than the DCF=~0.4 typical for stock AP.

If stock apps don't have DCF=~1, it means the run time estimate is WRONG, and the admins should fix it.

Actually, while I agree that DCF should be around 1.0, there is an advantage:

A brand-new computer defaults to 1.0, which means the first work requests will be small, and grow as DCF converges on the right number.
ID: 906011 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 18996
Credit: 40,757,560
RAC: 67
United Kingdom
Message 906042 - Posted: 11 Jun 2009, 2:01:25 UTC - in response to Message 906011.  

Don't forget that the first AP task that user will get will be with the stock app (so ~80 hours for that machine), but it will be estimated by BOINC at DCF=1.0, rather than the DCF=~0.4 typical for stock AP.

If stock apps don't have DCF=~1, it means the run time estimate is WRONG, and the admins should fix it.

Actually, while I agree that DCF should be around 1.0, there is an advantage:

A brand-new computer defaults to 1.0, which means the first work requests will be small, and grow as DCF converges on the right number.

Agreed, but with some concern about AP tasks.
A new host would see the AP tasks at about 2.5 times the actual time. As the tasks are long to start with this could lead the owner who only wants to do a limited number of hours to assume it is more time than they wish to contribute within the deadline limit.
ID: 906042 · Report as offensive
1mp0£173
Volunteer tester

Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 906055 - Posted: 11 Jun 2009, 2:45:52 UTC - in response to Message 906042.  
Last modified: 11 Jun 2009, 2:46:30 UTC


Agreed, but with some concern about AP tasks.
A new host would see the AP tasks at about 2.5 times the actual time. As the tasks are long to start with this could lead the owner who only wants to do a limited number of hours to assume it is more time than they wish to contribute within the deadline limit.

I don't have a solution to that, and I can't argue it either.

I don't do CPDN because they take so damned long to run.

Sometimes I think BOINC is just too informative.
ID: 906055 · Report as offensive
Profile AlphaLaser
Volunteer tester

Send message
Joined: 6 Jul 03
Posts: 262
Credit: 4,430,487
RAC: 0
United States
Message 906083 - Posted: 11 Jun 2009, 4:48:12 UTC - in response to Message 906042.  
Last modified: 11 Jun 2009, 4:53:56 UTC

Don't forget that the first AP task that user will get will be with the stock app (so ~80 hours for that machine), but it will be estimated by BOINC at DCF=1.0, rather than the DCF=~0.4 typical for stock AP.

If stock apps don't have DCF=~1, it means the run time estimate is WRONG, and the admins should fix it.

Actually, while I agree that DCF should be around 1.0, there is an advantage:

A brand-new computer defaults to 1.0, which means the first work requests will be small, and grow as DCF converges on the right number.

Agreed, but with some concern about AP tasks.
A new host would see the AP tasks at about 2.5 times the actual time. As the tasks are long to start with this could lead the owner who only wants to do a limited number of hours to assume it is more time than they wish to contribute within the deadline limit.


I have to agree with Nicolas. Most new users aren't gonna know about the existence of DCF among other things and it is reasonable for them to expect for the initial estimates to be nearly correct from the get-go. For SETI the runtimes are generally predictable ahead of time and in the worse case your tasks end sooner rather than later (-9 overflows and such). Keeping in mind this is a "first impressions" moment, users ought to get intuitive feedback from the client with minimal surprises. Using the DCF to deal with overfetch from new and "untrusted" users sounds like a kludge when we should be thinking about maybe using some other dedicated mechanisms for handling it.
ID: 906083 · Report as offensive
Previous · 1 · 2 · 3 · Next

Message boards : Technical News : Upwards and Onwards (May 28 2009)


 
©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.