Observations on FGRBP1 1.17 for Windows

Holmis
Joined: 4 Jan 05
Posts: 1118
Credit: 1055935564
RAC: 0

Betreger wrote:IMO if the new

Betreger wrote:
IMO if the new work is 5X longer the credits should be 5X

Well, only if the original credit was accurate. I think we got to much credit for the shorter tasks and I view it as a bonus for testing a new application.
My take on the amount of credit for a task is that it should not matter what GPU app/science run your choose here as they should all pay about equal amount of credits per unit time. Same goes for a comparison among the CPU apps/science runs.

Betreger
Betreger
Joined: 25 Feb 05
Posts: 987
Credit: 1421634737
RAC: 798250

Holmis wrote: I think we got

Holmis wrote:
I think we got to much credit for the shorter tasks and I view it as a bonus for testing a new application.

When the great BRP6g Cuda 55 aps were running I was averaging over 90k RAC, when they went away the BRP4g took over I lost about 20k. The way it is now the same GPU will get well under 30k. My only solace is all the other Windoz machines are suffering equally. 

I hope this is a work in progress and the Windoz users can eventually get throughput similar to the Linux users. 

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7023574931
RAC: 1810514

Over on the Technical News

Over on the Technical News thread, there was a report a few hours ago of a current generation result receiving credit of 1,365 instead of the 3,465 awarded for the first day.

Now my short-queue host has also received 1,365 for the six most recently returned units.  So I suspect this is the new standard rate (until the next revision).  I thought 700 was very, very skimpy, and 3,465 lavishing generous.  I think 1,365 is somewhat skimpy, personally.

 

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109393203407
RAC: 35849381

archae86 wrote:I thought 700

archae86 wrote:
I thought 700 was very, very skimpy, and 3,465 lavishing generous.  I think 1,365 is somewhat skimpy, personally.

I agree with your assessment.  693 has been the standard award for many iterations of the CPU only version of the various FGRP runs from FGRP1 to FGRP4 to FGRPB1.  I could easily be wrong but my understanding was that each successive run was processing tasks with the same amount of 'science content'.  If so, the award of a constant 693 seems quite appropriate.

The bit I am unsure of is whether or not the GPU app has been processing tasks still with the same science content.  It seemed likely because the award continued to be 693 when the beta test was on and each quorum was split between a CPU task and a GPU task.  I read the announcement that the science content was being increased by a factor of 5x and I wasn't really surprised when the award was 700 because there have been examples in the past where the crunch load/crunch time has changed and the credit is adjusted somewhat later.  I took 700 to be an interim adjustment until a more appropriate value could be worked out.

In the past there have also been examples of apps with improved efficiency able to crunch the same scientific payload in a shorter time.  In these cases, the credit award was maintained even when the crunch time was quite a bit shorter.  So if the current situation really is a 5x increase in content but only a ~3.5x increase in crunch time due to some sort of efficiency improvement, I wouldn't have a problem with the seemingly overgenerous 5x693=3465 credit award.  No doubt Christian will make a comment at some point.  I suspect that maybe 1365 is some sort of unintended consequence creeping in when some other task generation parameter was being adjusted.

 

Cheers,
Gary.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

I guess Christmas would not

I guess Christmas would not be complete without a CreditNew debate. Tongue Out

Der Mann mit der Ledertasche
Der Mann mit de...
Joined: 12 Dec 05
Posts: 151
Credit: 302594178
RAC: 0

...what a seasonable

...what a seasonable gift from the Project Team for Christmas; more CPU Power, more GPU Memory, more Runtime, less Credit. No need to begin a new Discuss. It is like it is.

BR

Merry Christmas and a happy new Year.

Der Mann mit der Ledertasche

Greetings from the North

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109393203407
RAC: 35849381

AgentB wrote:... a CreditNew

AgentB wrote:
... a CreditNew debate. Tongue Out

Thankfully CreditNew doesn't apply here or else there probably would be a 'debate'.  I should confess that I know pretty much zero about CreditNew other than to say I did read a lot of incendiary commentary on the topic, somewhere, quite some time ago, which I promptly forgot about as I was  scooting off into the far distance at quite a rate of knots Surprised Smile.

I'm very happy with our current system where the Devs decide on fixed credit and there is an opportunity for well-mannered political lobbying that may (or may not) be taken notice of.  I think it's quite OK for people to put forward reasonable, politely presented points of view but would be inclined to take action if somebody started abusing that.

 

Cheers,
Gary.

Betreger
Betreger
Joined: 25 Feb 05
Posts: 987
Credit: 1421634737
RAC: 798250

My thoughts on this app have

My thoughts on this app have evolved over time. 

1: my GTX660 was cranking out apx 80k of throughput running BRP6 cuda55 now it is struggling to to 12 of these devils a day running 2 at a time.

2: it uses a CPU per work unit which detracts from my contribution to my other project.

3: 5 times the credit is not the answer, that would reward the Linux hosts with an ungodly unreasonable amount of credit.

4: the solution should be a better written app for Windows so the Windows hosts get throughput simular  to the Linux hosts.

5: I shall continue on because I believe in this project, as my RAC continues to drop from 90k to who knows what. 

Jim1348
Jim1348
Joined: 19 Jan 06
Posts: 463
Credit: 257957147
RAC: 0

Betreger wrote:3: 5 times the

Betreger wrote:

3: 5 times the credit is not the answer, that would reward the Linux hosts with an ungodly unreasonable amount of credit.

4: the solution should be a better written app for Windows so the Windows hosts get throughput simular  to the Linux hosts.

 

They should do what is best for the science, which is to maximize the output of each host as much as possible.  Then the technology decides how much credit is given (equal pay for equal work is what most projects use, and which makes the most sense to me).  A forced equality for political-correctness is one distortion of the data that I like to avoid.  It creates the wrong incentives for maximizing the output by providing the wrong rewards.

Betreger
Betreger
Joined: 25 Feb 05
Posts: 987
Credit: 1421634737
RAC: 798250

I agree, The Windoz hosts are

I agree, The Windoz hosts are not producing the throughput the Linux hosts are. A better app needs to be written for Windoz. 

I am certain the project developers are aware and working on that, but I have no evidence of that. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.