I like the UI very much and decided to try it after the update to handle bigadv, but there seems to be an issue with bonus calculations. It works for a while and then the bonus multiplier gets out of whack. For example, a system with avg time per step of 23:40 shows up as 66721 ppd and 4.3167 multiplier, when earlier in the same WU it was correctly saying around 42000 ppd.

I'm trying to figure out why sometimes it calculates the bonus and other times not for the A3 units. The WU is at about 56%, Credit: 476, Bonus factor: 1.0000 . In the Parameter / Value area on the lower left for the selected folder (fah client) it shows:

Yet wherever fahspy is getting the Bonus from shows 1.0000 . Even when I click the "Update WU Database" for the latest information. Then sometimes later on, it seems like fahspy starts calculating the bonus again.

It would also be cool if the two decimal digits of the Credit column could be suppressed, in all cases or as an option. I find the ".00" make the credit value harder to read at a glance, especially since I'm unaware of any WUs that have a non-integer credit value. "783.00" versus "783" For that matter, it would be nice if Stanford tweaked the psummary to suppress the ".00" on Credit.

I've also noticed the font can be hard to read at times. I'm not sure why that's so, since it looks like the font used by windows. I don't know if it's scaled from it's optimum resolution, the contrast or what, but some way to enhance the readability. Possibly an option to select the font and size, though that might mess up the layout and spacing. Anyway, whatever you think. It's a great tool anyway!

Thanks again for FahSpy!!!

Last edited by ElectricVehicle on Thu Feb 04, 2010 9:32 am, edited 1 time in total.

Hmm.. I just checked again with the WU at 77%, and now FahSpy is calculating the bonus (Credit: 2281) , note the Bonus factor: 4.8053 . Does FahSpy not calculate the bonus until the WU passes a certain completion percentage?

All monitor programs must make certain assumptions based on the data they have at the time. This depends on what frame history it can see when you run the program. The bonus factor is a direct result of the instability to accurately gather enough data to know when the WU will be completed.

Notice that the first one shows PPD (points per day): 850 based on the frames that it used in the calculation and the second one shows PPD (points per day): 4250. If you continued to process at first estimated rate, you would not get a bonus. At the second estimate, you would.

Bonus calculation is depended from the download time and preferred deadline. If you progress doesn’t complete before preferred time, you do not get a bonus. FahSpy highlights such work units by maroon color.

All monitor programs must make certain assumptions based on the data they have at the time. This depends on what frame history it can see when you run the program. The bonus factor is a direct result of the instability to accurately gather enough data to know when the WU will be completed.

Notice that the first one shows PPD (points per day): 850 based on the frames that it used in the calculation and the second one shows PPD (points per day): 4250. If you continued to process at first estimated rate, you would not get a bonus. At the second estimate, you would.

I haven't start / stopped any of the WU's. All of the Wu's have had a continuous log file and have completed in 15 hours or less, all are eligible, and receiving bonuses from Stanford. The PPD differences are all due to the bonus not being properly recognized. In all cases the "Avg time per step" has been between about 7:30 minutes to 8:30 minutes, I know for sure never more than 10:00 minutes.

The Issued datetime is AFTER the predicted completion datetime! It appears that the time to complete the WU is being added to the hours and minutes correctly, but the overflow from the hours isn't incrementing the day from 4 Feb to 5 Feb. This unit should complete around 5 Feb 06:33:05, as I've seen on many previous units. So it's possible this mistake in the date calculation is also affecting the bonus calculation. Yup, if you notice, my first post showing no bonus was at "by ElectricVehicle » Wed Feb 03, 2010 10:34 pm" for a WU that is crossing the midnight boundary to the next day, and the bonus isn't being calculated correctly. Then the next post "by ElectricVehicle » Thu Feb 04, 2010 2:30 am" is after midnight, and the bonus calculation is correct!

So it looks like for bonus WU's that are executing across the midnight boundary from one day to the next won't have the bonus calculated correctly until the day on which they are going to complete due to the mistake in not incrementing the day when the hours overflow.

I'd noticed the issue in not incrementing the day before, but it didn't bother me and I didn't connect it to the incorrect bonus calculation until just now. Ps. thanks for enabling copy / paste of the client grid and parameter value areas of FahSpy. The copy / paste makes it MUCH easier to share or record information and to accurately report issues / bugs!

So Angel999 or Behc - is this a bug and is this the cause?

Last edited by ElectricVehicle on Fri Feb 05, 2010 7:28 am, edited 3 times in total.

bingo-dog wrote:I like the UI very much and decided to try it after the update to handle bigadv, but there seems to be an issue with bonus calculations. It works for a while and then the bonus multiplier gets out of whack. For example, a system with avg time per step of 23:40 shows up as 66721 ppd and 4.3167 multiplier, when earlier in the same WU it was correctly saying around 42000 ppd.

Check the bonus calculations you're seeing and see if they are related to the change of the day. I'm guessing you'll see the correct calculation on the day the WU completes, but prior to that day, the calculation will be funny.

It must be the mistake in incrementing the day. The calcualtions continued to be incorrect until the first update after midnight and the bonus calculation changed to the correct values for the bonus eligible SMP A3 WU:Credit 2169.05PPD (points per day) 3825

Ps. The forum times are off by one hour (1:10am). It's currently 12:10am in California (also shown in the heading as "Stanford time: February 05, 2010 00:17:29" Time is passing as I'm updating this post...). Looks like DST didn't get turned off for the forum times now that DST is over.

ElectricVehicle wrote:Check the bonus calculations you're seeing and see if they are related to the change of the day. I'm guessing you'll see the correct calculation on the day the WU completes, but prior to that day, the calculation will be funny.

I see similar but opposite behavior. Early on in the WU progress, the calculations are correct. Later, closer to completion, the multiplier and credit go crazy.

Do you have the opportunity to observe your clients at midnight local time to see if the calculation craziness is due to the day change or if it might be caused by something else? I.e. are we chasing the same bug here or two different bugs?

On my laptop, the gpu client showed a predicted time of yesterday when it was downloaded and ran continuously today in approximately four hours.

The smp client had shown a predicted time of yesterday also. That was downloaded early this morning and is now finished.

On my desktop pc, I've just downloaded an smp tonight. FAHSpy predicts it will finish this morning, not tomorrow morning. Thus, there is only the 1.0000 bonus factor after completing 10 steps. I'll keep an eye on this one as midnight comes and goes.

ElectricVehicle wrote:Do you have the opportunity to observe your clients at midnight local time to see if the calculation craziness is due to the day change or if it might be caused by something else? I.e. are we chasing the same bug here or two different bugs?

It was working normally this morning, and now well before midnight it's broken. PPD for one client is now estimated at 205479 (over 3x what it should be), and for the other client is about 1.5x what it should be. Neither client has not been interrupted during the duration of these particular WUs. The time per frame values are correct, issued times are correct, predicted times are correct, so there is a math error somewhere else in the calculations. Bonus factor, credit, PPH and PPD are wrong.