Interestingly the slower you crunch, the higher the 'award' with this strange 'system'.

A few weeks ago, I tried to increase my machines' performance by maximizing the total number of WU they process per day by changing app_config file. All machines are processing more WU per day now but does this mean it didn't do any good in terms of RAC?

---

All machines are processing more WU per day now but does this mean it didn't do any good in terms of RAC?

It does mean that your RAC won't fall as far or as fast as it would have. So it will have helped, a bit.

---

Grant
Darwin NT

It does mean that your RAC won't fall as far or as fast as it would have. So it will have helped, a bit.

RAC fell ~12% (7500) over last 3 weeks as everybody else despite the increased number of WU processed per day and is still going down. When I checked my position on stats page, at least the fastest machine stayed at the same place during this period.
Now I have no idea how I can optimize in terms of maximum RAC.

---

Wow this is a change!

My estimated times for GPU tasks on my main computer changed to 4.5m/MB 5.5m/AP
They should be in the 24m and 43 range.

My logs don't show any abnormal amount of shorties / overflows.

I have no clue why that happened.

Now I have no idea how I can optimize in terms of maximum RAC.

I've never tried to maximise my RAC, that's one of the reasons I've never processed any AP work.
All I try for is to process the most WUs per hour. Ideally that would result in higher RAC, but with Credit New it's any bodies guess what the end result would be.

---

Grant
Darwin NT

RAC down 15% and still going.....

---

Greetings All

As I am in the process of looking for another GPU, I have been perusing the top computers at Seti, and whilst perusing I have managed to come to the following conclusion, if you are the slowest cruncher on a workunit, you will be given the same credit as the fastest cruncher which means less credit, example

Cruncher 1 - 600 sec 85 credits
Cruncher 2 - 1600 sec 85 credits - Wingman

I just ran through more than 100 validated tasks and the above outcome was on all those tasks.

If this has been already explained in this thread I do apologise for saying it again.

Oh well, keep on crunching.
Regards

PS. Does not deter me from crunching, for it is nice to think that we are not alone.

Perhaps we can help ourselves by making our next SETI contributions proportional to our RAC AND msg DA to that effect. Might motivate him to fix it.

---

That has always been the case, since "credit" was introduced with the launch of BOINC. It was exactly the same with the first and second credit systems.

All wingpeople who work on the same task are awarded the same credit for a valid completion - after all, they've all done exactly the same amount of work. The time is unimportant: it doesn't matter whether a task takes 10 minutes on a fast GPU, or 10 hours on a slow CPU - or 10 days om an Android phone.

Fast machines get to the top of the list by completing more tasks, not because of any difference in the amount of credit per task.

Afternoon Richard

Well now that you put it that way, it makes whole lot of sense, I think I was just having moment lol.

Yep thats why the quicker machines are are the top lol.

Thankyou

This keeps constantly annoying - especially, if you try to tweak settings and regardless what you do, it only goes down. X(

Simply sad, that the "powers to be" are so unregenerate about this issue.

---

Aloha, Uli

Simply sad, that the "powers to be" are so unregenerate about this issue.

Since BOINC went from BOINC developed by 3 developers mainly to BOINC as a Governance, we the users are "the powers that be". As the commits on Github show, a lot of the bugfixes are written by third party developers these days.

So if this is so bad and you don't want to wait for David to budge, get a buddy developer to add his code to Github with a possible fix for this and ask if it's merged, or at least that some project tests it.

Sorry, but I've sat through this thread reading all the reproach people have about the credit system and how David doesn't want to change anything, but then apparently neither does anyone here or else someone would've gone that track already.

---

Sorry, but I've sat through this thread reading all the reproach people have about the credit system and how David doesn't want to change anything, but then apparently neither does anyone here or else someone would've gone that track already.

I think alot of that animosity comes from the lack of acknowledgement that what users see is real, apparently isn't being worked on (An understandable and natural consequence of the transferral/change/budget-cuts, and low priority placed on Credit, ignoring that it's tied into critical estimates)

From one of those developers' (doing nothing) perspectives, I know exactly where the design flaws in CreditNew lie, and they are non-trivial. This is more than a simple code patch.

IMO, what has to happen is for things to break, and that's what you're witnessing.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Probably, if a significant portion of the cruncher base is formed by credit seekers, many will leave and crunching will decrease (this time crunched WUs, not credit).

A fewer many of die-hards will stay in these whereabouts, but many will leave (or will not come), right now that we have hips of new work.

Perhaps it is already happening and probably this is what would move the Higher Powers to do something.

Has anybody already made any estimates about crunching rate (not credit) in these last (dis)creditnew years?

Cheers! :-)

Has anybody already made any estimates about crunching rate (not credit) in these last (dis)creditnew years?

For here, you can guesstimate total crunched only goes up by Moore's Law (transferred to GPU from CPU in recent years, as CPU more or less stalled)

You can roughly approximate how much credit has dropped for the same #operations by getting a raw cobblestones for a given task, by APR*cobblestone_scale*elapsed_time_seconds, which will approximate what credit would be pre-creditnew downscaling.

cobblestone_scale is 200/86400e9

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Interestingly the slower you crunch, the higher the 'award' with this strange 'system'. I can easily recognize this, cause i have two different GPUs, the GT 640 being nearly three times faster than the GT 430. On similar WUs the GT 430 always get more credit, only topped by the CPU (Core2Quad), which again earns more credit for a similar WU. I think "borked" is way too friendly for this behavior...

Absolutely true it appears. In this example, I have 2 machines, a Genuine Intel(R) Atom(TM) CPU 330 @ 1.60GHz [Family 6 Model 28 Stepping 2] (4 processors) and a Genuine Intel(R) Pentium(R) 4 CPU 3.80GHz [Family 15 Model 4 Stepping 10] (2 processors) and have recently been keeping an eye on them, and wondering what might be going on. They are both configured to only run GPU tasks, as the Atom would pretty much choke on anything CPU, it really wouldn't be worth it.

As the P4 3.8 proc is unfortunately fairly pitiful as well, I decided to set that up as a GPU only cruncher too. Now to be honest, the Atom just sits upstairs happily crunching away with no one bothering it at all, and the P4 is used by my daughter for web based games and such, maybe 1 hour each day of the week and on one of those days for a total of probably 2-3 hours, where crunching is suspended because it really effects the usability of the system if it is enabled.

So because of that, it's not an _exact_ apples to apples comparison, but pretty dang close I'd say, and the difference in RAC (or should I say lack of significant difference) is pretty surprising. And actually, the Atom is (and has been for a while) running higher (6,304 ) than the P4 (5,765), and it only has a GTX260 in it, whereas the P4 has a GTX950, which is 5 generations newer then the 260, and both the 260 and the 950 are pretty much the lower end of their respective spectrums when they were new.

Just thought I'd toss that out there as an interesting comparison.

This comparison may be obscured a bit, because first the hyperthreaded p4 will likely be underfeeding the 950. That'd be partly due to hyperthreading sharing resources with everything else the system needs to do, partly because the 950 would be natively 64 bit while the OS is 32 bit on the host, and depending on what tasks you're running, because the GPU has 2GiB VRAM, you could run into paging issues with presumably the Max RAM installed.

In the Atom + 260's case, I believe the 260 will be being fed more than adequately, having more cores, likely no system RAM pressure (2 Gig offset partially only by the 895MiB VRAM)

If it were me, and physical/driver/power/thermal considerations allowed, I would swap those GPUs. (Mostly would depend if they made an XP driver for the 950 I suppose) [Would probably have to consider more RAM in the Atom machine though, depending what the OS+driver does having 2GiB VRAM to map into the physical space, and how many tasks you'd want to run at a time on it]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

If it were me, and physical/driver/power/thermal considerations allowed, I would swap those GPUs. (Mostly would depend if they made an XP driver for the 950 I suppose)

As far as I know, there are no official drivers for a 950 on XP.
I am, however, running a pair of 980s on XP with a hacked driver I found some time ago.

Meow.

---

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

Crap! I forgot about that, it is a Dell ZXP from 2005/6 that was my dad's before he passed earlier this year, and was given to my daughter to use because it was Grandpa's (even though due to his illness it really hadn't been regularly used in probably 3-4+ years). So, I upgraded the proc to the fastest/bestest that I found it would take, tried to put in 8 gig of memory (Nope. Only recognizes 1 gig DIMMs, not 2 gig, so you get only 4. Thanks Dell!) and put in a new HD.

I really wanted to get it going for her as a surprise gift right after his funeral, so though I had a Dell copy of Win 7 SP1 x64 on the way, it didn't arrive till too late, so I installed a copy I had laying around of x86 32 bit non-Dell Win 7 instead.

Worked fine, she got it and was pretty happy, though it can be a little laggy in some of her online games, though it is special because it's Grandpa's. I had planned to wipe the drive and re-install Windows using the Dell DVD so I would stop getting the You must Validate your copy nagware, because Dell DVD's don't require a product key on Dell hardware, plus the 64 bit advantage (even though it only has 4 gig of RAM) but kind of back-burnered it due to all the other computer related tasks I have going on right now.

So, all this being said, would installing the 64 bit version of Windows possibly clear up some of the issues?

---

Hey - I just noticed that I have NO GBT WUs on my GPUs now. Is this because all the current GBT WUs are VLARs, or did somebody at SETI make a surreptitious change to keep them off the GPUs for RAC purposes?

Crunchers want to know!!!!

---