F@H Spy Bonuses?

[new08]

I've been using Spy for ages and find it pretty useful.
I've recently bumped up my CPU to a Duo6600 cpu and evaluating the worth of using one/two cores, over and above the busy -GT240, still doing good work at low wattage and little affected by CPU change.
Both CPUs are doing regular A4 cores @ 600 points a go- but Spy reports bonuses of 2X and 3X on the running cores- but this isn't applied when they upload to servers. The cores are about 6x more productive than previous in time per unit but the doubling of power take is only adding 20% to raw production rate.
Is F@H Spy out on this- or are bonuses applied separately to encourage take up of these units?

[bollix47]

I'm not familiar with "Spy" but don't forget that you have to successfully finish and upload 10 WUs that qualify for bonus before you will start to receive any bonus and you must maintain an 80% success rate.

viewtopic.php?f=58&t=13160

NB: The a4 cores that are qualified for bonus came after the aforementioned link but they do qualify.

Also, you must get and use a passkey for the 10 WUs to qualify.

http://folding.stanford.edu/English/FAQ-passkey

[new08]

Thanks for that Bollix- If that's the case I will carry on with them as it works out about right on power/ppd, if bonus added on. Good for Spy, in that case- just a bit previous
One further query I have is why, when both cores are loaded to with 10% of each other- the bonus is markedly different for similar work units?
Is it a factor of core priorities allowing for user overheads on normal work going onto the lighter loaded core -and thus reducing efficiency?

[bollix47]

There can be quite a difference between WUs when it comes to PPD. There's a recent thread that's looking into that: viewtopic.php?f=16&t=20511

e.g. I currently have a P7600 WU running on two different computers and the difference in PPD is huge. The strange thing is that the faster computer is producing way less PPD than the slower one.

Also, you're running on both CPUs plus your GPU and even though Nvidia GPUs interact very well with your CPU clients there will be times when your GPU might slow down one or both of your CPU clients. I've noticed this moreso when the GPU is running a 353 point WU. I'm guessing that's because the 353 pointers use the CPU more often to feed themselves.

I always use low priority(slightly higher for systray clients) on my clients even though it's suggested to use low for the GPU and idle for the CPU client(s). I found this doesn't affect the GPU and helps the CPU clients.

[new08]

Yeah, that makes sense- I run a whole load of 353s they are my best producers at up to 5,000+ ppd on the GT240.
I've got the code for bonuses- presumably that works back on previous units- I don't think I've done 10, but must be getting close..
I must pay attention to the core priority and usage settings- but like you say when the machine is doing its stuff it's not always easy to see cause and effect
PS: I had a look at that database- but at my production, well out of that pic

[bollix47]

The qualifying for bonus doesn't start until the first unit downloaded using the passkey. i.e. it's not retroactive.

[new08]

OK- My loss - just trying to get the rig right and we've all lost a few bits of work that way!
As a matter of interest- is there any way that a flag could be set to prompt new SMP users to get a passkey? I vaguely remember something from a while back- but easily forgotten!

[bollix47]

Don't forget to enter your passkey in all your client's configurations. I even use it in my GPU configurations so that if they ever do qualify for a bonus they'll be ready from day 1.

[new08]

I edited my earlier post- but also I will do the GPU thing to stay ahead...

[bollix47]

I believe the passkey info is mentioned in the quide(s).

Just to be clear it's 10 units to qualify and the bonus won't start until you complete the 11th WU.

The GPU2 client may never qualify for a bonus as they will probably be phased out eventually but it only takes a few seconds to copy/paste it into the configuration just in case.

[PantherX]

OK- My loss - just trying to get the rig right and we've all lost a few bits of work that way!
As a matter of interest- is there any way that a flag could be set to prompt new SMP users to get a passkey? I vaguely remember something from a while back- but easily forgotten!

For the V7, there is an open ticket (https://fah-web.stanford.edu/projects/F ... ticket/747) which will register the presence/absence of the Passkey and hopefully, it will be effective in these cases.

[new08]

Good move ,Panther. I see the original V7 suggestion has trivial status- but at the risk of getting,perhaps only a third of due points, rather useful- in the interest of fairness.
Surely, this idea could easily be applied to other qualifying clients during set up- or maybe flagged in the work unit acceptance tag when units are uploaded OK ... ?

[PantherX]

Anything that changes with the WU is almost impossible to change since it requires changes to the Server Codes and Clients and possibly a bunch of other stuff. Thus having a passkey confirmation inside the WU isn't possible. However, currently, the WU does contain the passkey if present and is matched against the Server record. If everything matches, you will get bonus points. If not, then you will be assigned base points.

The trivial status is based on the fact that there are other high priority stuff that is needed to be solved for V7. All of these are enhancements which can be added later once the V7 is finalized. We have to follow a certain procedure in order to ensure that we can actually reach the target. If we don't, then we will never be able to deliver the V7 as suggests are always pouring in and there's always room for improvement. Moreover, we have limited developer resources which have to be used wisely. Thus, we concentrate on high priority stuff and those with milestones. Once that is over, we can focus on other enhancements that justify the development resources and impact on donors.

[new08]

Fair enough on the new V7, but I don't see why it should be up to 3rd party utilities to flag optimal usage of clients?
The client is echoed on WU upload [in the log] so could the 'CPU type' running be inferred from the WU-like an A4, as qualifying WU for bonus -or do these run on many 'non qualifying for bonus' clients?
If the calculations can't be done without client retrofits - then at least a comment fed back could highlight disparity to someone changing their setup.
F@H Spy seems to work it out from the log OK!

[bruce]

The goals of FAH are first and foremost maximizing good science. Points are important, too, getting more points for exactly the same scientific throughput is much less important than actually improving that throughput. Most of the higher priority changes that PantherX refers to actually improve the scientific throughput for everyone.

Passkeys are NOT required, though they are recommended. All that information about passkeys is readily available in the FAQs and in the how-toos (and here on the forum) but when people choose not to read the FAQ and time has to be spent encumbering new software with popups reminding them of things that they can learn with a (very) little reading it seems like a poor use of expensive development resources. Can't Stanford assume that Donors who happen to be interested in points take a certain amount of responsibility, themselves?

OK .... I'll get off my soapbox now.

None of the third party utilities actually "flag optimal usage of clients." They have no ability to know whether your passkey is qualified or not. The have to assume either that you'll get a bonus or that you won't get a bonus. You were the one that noticed the discrepancy, not the 3rd party software ... and as a result of noticing that discrepancy, you were the one who asked the right questions ... not some software.