> The variations in benchmarks are rather odd, but I won't comment further
> because they don't seem big enough to account for the requested credits
> problem. I am more inclined to suspect that there is a factor-of-two (2 CPUs)
> problem somewhere in the BOINC claimed credits calculation.
>
Aha, on the host itself if you run the benchmarks, you will see regular numbers that boinc normally reports...but...
have you looked at the website listing for "your computers" and the host in question?.
Thats where my code reports these new "project specific benchmarks".
In your case your "AMD K7-XP, Athlon XP 2200+ MP, 1799Mhz, (Palomino-662-0)" machine sends a benchmark report to the servers of:
Measured floating point speed: 1536.98 million ops/sec
Measured integer speed: 1536.98 million ops/sec
This causes the server for the WU of 26,038.23 seconds issue a "claimed credit" of 46.32.
Now, 46.32 is probably way too low, I will grant you...but. The server gets this number (and my code generates its benchmark) based on the server claim that each WU only contains 20x10^12 FP Operations.
However, if you installed this boinc client on multiple machines, and each of them got this WU...they would all claim 46 +/-3 credits for it.
Back when einstein was in alpha phase, and their WUs were shorter for debugging purposes, they still claimed 20x10^12 for WUs that took 2 hours or so.
To allow claims to be more in the 70 range, I would have to (and probably will) put a special case "if" statement...like "if project = einstein and estimated FP ops is 20x10^12, then est_FPops is really more like 31x10^12".
Also, if your machine did run into a short WU of say 50% normal time to crunch...the project benchmark only changes slowly, so that WU would send nearly identical benchmark info along with the report of 1/2 normal seconds...and credit claimed would be about 1/2 normal.
What are granted claims averaging for Einstein, say...calculated over 100 validated WUs?
Change:
If WU downloaded from einstein, on host change est_fpops to 31e12.
If WU time being calculated and estimate between 19 and 21e12, and proj=einstein, make it be 31e12.
Server will still believe est_ops to be 20e12, and calculate fpops with now larger benchmarks (same time, larger est_fpops).
Quirk: If you have run my code on your host before, your project benchmark will be low and will adjust itself to the correct # over the course of approx 7 WUs.
If you want to skip this period, edit "client_state.xml" file and change
prj_secs_total
prj_fpops_done
prj_fpops
values to zero for the einstein project section.
[Ben, before I respond, I noticed that you posted two rather detailed responses to me. I did not expect my griping to attract that much attention, but I hope maybe even BOINC can be improved in some way by detailed discussion.]
ben wrote,
> Aha, on the host itself if you run the benchmarks, you will see regular
> numbers that boinc normally reports...but...
> have you looked at the website listing for "your computers" and the host in
> question?.
Yep, I did look there too, & I reported those website numbers in the last line of my table. "1536" for both the float & int benchmarks. I noticed that difference, but i did not understand it. I still don't understand the details, but I get your point that there is some standard modification in the float & int benchmarks to adapt them to this or that project.
After reconsidering, though, I now think all the win reports of the int benchmarks given by BOINC & reported in my table are too low by about a factor of two or more. The int benchmarks on this computer should be roughly 3000 (based on comparison with similar single-CPU computers). I don't know what causes this in BOINC.
> This causes the server for the WU of 26,038.2 seconds issue a "claimed
> credit" of 46.32.
> Now, 46.32 is probably way too low,
Yep.
>I will grant you...but. The server gets
> this number (and my code generates its benchmark) based on the server
> claim that each WU only contains 20x10^12 FP Operations.
>
> However, if you installed this boinc client on multiple machines, and each of
> them got this WU...they would all claim 46 +/-3 credits for it.
Sorry, but I just can't believe this last claim. I've looked at a great many WUs processed by the computers I run & by others who process the same WUs, & I see no evidence of any significant variation in the amount of computing power required to process them since I arrived at E@H. I think you might have brought this point up also in your second response to me, so I'll set it aside for the moment & hope to come back to it again.
> To allow claims to be more in the 70 range, I would have to (and probably
> will) put a special case "if" statement...like "if project = einstein and
> estimated FP ops is 20x10^12, then est_FPops is really more like 31x10^12".
You might be right that E@H is badly estimating the amount of computing power required for their units. If so, it should certainly be corrected. But I don't have any information about that. What I perceive is, rather, inconsistency among various computers all processing the same unit. I have information about that because I can read (& anyone who chooses can read) the variation in claimed credits when several computers process the same unit (as always happens).
> What are granted claims averaging for Einstein, say...calculated over 100
> validated WUs?
I don't have that average. I agree that the inconsistencies in claimed credits are reduced by the system for granted credits. But if there are some "outcast" computers that are assigned too low a claimed credit by BOINC, then they will end up with fewer granted credits too.
Here is the very tedious argument (by example):
Suppose 20% of all computers are outcasts & are assigned claimed credits of 50.
The other 80% are incasts assigned claimed credits of 100.
If I own an incast computer & I am sent a WU, then I know there is 100% probability that one computer for that WU will be an incast & there is an 80% probablity that each of the other two will be incasts too. There is then a probability of (1.00*0.80*0.80) = 64% that there will be ZERO outcasts processing that WU, in which case I am CERTAIN of getting the full 100 credits.
But if I own an outcast computer & I am sent a WU, then I know with 100% probability that I will NEVER process a WU in which all three processors will be
incasts, so I will never reach that complete certainty of 100 credits that the incast will reach with 64% of his units. My very presence as an outast shifts the odds against me.
While I agree any changes to the client can't guarantee that the claimed credit will be the value granted (as others are using the official boinc client)
...I can state that the code changes I have made to my version of the client will "claim" nearly identical credits for identically difficult WUs, regardless of what machine they are run on (with my client).
My code simply takes a running average of the completion times for the most recent 7 WUs for a project. (running average = updates as it goes along).
It then computes how many "project specific" FP ops are being crunched per second.
= [estimated_FP_OPS_from_server_downloaded_with_WU] / [num secs per WU].
It omits really short time WUs to the average...which would really inflate the supposed FP_OPS speed (31e12 ops in 300 seconds vs 31e12 ops in 24,000 seconds)
This is the project specific benchmark. Try it out with any reported CPU time of any of your hosts.
Then use that value in the claimed credit equation.
=(FP_bench+INT_bench)/1000 * 100/(2*secsPerDay)
(Note: both benchmarks are reported on your host info web page as MegaFlops, so I use that value in the formula above, but in truth they are stored in simple FPOPS_per_sec)
> While I agree any changes to the client can't guarantee that the claimed
> credit will be the value granted (as others are using the official boinc
> client
> ...I can state that the code changes I have made to my version of the client
> will "claim" nearly identical credits for identically difficult WUs,
> regardless of what machine they are run on (with my client).
Very good if your programming changes produce claims internally consistent among all those computers using them. Next step is to make those internally consistent claims hit at about average for all other computers that are using the standard BOINCs. That seems fair. A simple fudge factor should be sufficient.
> My code simply takes a running average of the completion times for the most
> recent 7 WUs for a project. (running average = updates as it goes along).
>
> It then computes how many "project specific" FP ops are being crunched per
> second.
> = [estimated_FP_OPS_from_server_downloaded_with_WU] / [num secs per WU].
>
> It omits really short time WUs to the average...which would really inflate the
> supposed FP_OPS speed (31e12 ops in 300 seconds vs 31e12 ops in 24,000
> seconds)
Good, the completion times for actual WUs sound like solid data to serve as a basis for comparing various computers all running E@H. It also sounds as if it should work for hyperthreading computers, whereas running Whetstones or Dhrystones sounds dubious with HTs because they might compete between threads for the CPU resources in a different way from the project's coding.
Using FP_OPS per WU does not sound reliable AMONG VARIOUS PROJECTS, because different projects might have quite a different mix of floats vs. ints.
But you seem to be moving toward adopting a different fudge factor for each project. That sounds OK as an ad hoc correction for the differing mix of floats vs ints among different projects. Hopefully the mix of floats & ints will be reasonably stable within each project.
> This is the project specific benchmark. Try it out with any reported CPU time
> of any of your hosts.
>
> Then use that value in the claimed credit equation.
> =(FP_bench+INT_bench)/1000 * 100/(2*secsPerDay)
I would like to try it myself. It starts with "estimated_FP_OPS_from_server_downloaded_with_WU". How do I get this number?
Thanks for these details on the technique you are developing. All interesting.
>I would like to try it myself. It starts with
>"estimated_FP_OPS_from_server_downloaded_with_WU". How do I get this number?
For all projects currently, it is a fixed number. No project is required to have it be a fixed number..but all currently choose to.
Seti = 27.9e12
Einstein = 20e12
LHC = ??
Predictor = ??
------------------
>But you seem to be moving toward adopting a different fudge factor for each project.
I would call it rather a "project benchmark", which uses actual WUs computing to deterimine the value...rather than computing a Whetstone WU, etc.
> I would call it rather a "project benchmark", which uses actual WUs computing
> to deterimine the value...rather than computing a Whetstone WU, etc.
You are certainly entitled to name your own parameters.
> >I would like to try it myself. It starts with
> >"estimated_FP_OPS_from_server_downloaded_with_WU". How do I get this
> number?
>
> For all projects currently, it is a fixed number. No project is
> required to have it be a fixed number..but all currently choose to.
>
> Seti = 27.9e12
> Einstein = 20e12
> LHC = ??
> Predictor = ??
> ------------------
Sorry, I did try it myself, but did not quite get it.
My MP computer processes a unit in about 26,000 sec.
Then for E@H your
project_specific_benchmark = 20E12/26000=7.69E8 for my MP computer. If converted to MFLOPS, this is about a factor of 2 off from the numbers that your version of BOINC reports to the website.
Then your equation, using C's left_to_right grouping rule, is
as compared to about 46 reported by your version of BOINC.
If I change your project_specific_benchmark from FLOPS to MFLOPS, then I get a number 1 million times smaller, which still does not work. Seems off by a factor of 2 and some factors of ten. [The factor of 2 seems like a good idea to me. I hope there is some way you can hang on to it. :) ]
Sorry my bad. Just checked a machine with Einstein running on it...opened the client_state.xml file and looked for est_fpops for a einstein WU.
40000000000000.000000
So it was 40e12 not 20e12.
so your [prj_fpops] = 40e12/26000 = 1.5385e9 -- On web page this would be reported as 1,538 MFlops.
Next claimed credit - We use the website reported value (MFlops) in the formula...
claimed_credits_per_sec=(((2*1538)/1000)*100)/(2*24*3600) = 1.7801e-3.
This part I left out..sorry bout that (My bad again)
claimed_credit = seconds_for_wu * claimed_credits_per_sec;
claimed_credit = 26000 * 1.7801e-3 = 46.2824
----
Now lets try it for your Intel P4 3.0Ghz Hyperthread machine.
Average WU time = 41100.
prj_fpops = 40e12/41000 = 9.732e8 (a little more than 1/2 the above project benchmark)
claimed_credits_per_sec=(((2*973)/1000)*100)/(2*24*3600)=1.126e-3
claimed_credit = 41100 * 1.126e-3 = 46.2850
----
This version of boinc_gui.exeFile checks if project is "einstein" and est_FPOPS are 40e12...if yes then it changes it to 62e12.
> This version of href="https://einsteinathome.org/%3Ca%20href%3D"http://www.freewebs.com/gladry/boinc_gui.exeFile">http://www.freewebs.com/gladry/boinc_gui.exeFile">boinc_gui.exeFile[/url]
> checks if project is "einstein" and est_FPOPS are 40e12...if yes then it
> changes it to 62e12.
Thanks. I have now started up this new executable on my MP computer addtron-ga
It is a very "touchy" gui. I cannot open it because if I merely place the mouse pointer over the icon, it shuts itself down & disappears. But I think it runs if I don't touch it, so I will let it run for a while to see if it posts any results on the web site.
Thanks also for your revisions here. I will take a look at them.
Several messages ago you asked me a question:
>What are granted claims averaging for Einstein, say...calculated over 100 >validated WUs?
I have now tried to calculate some averages. My first average was for a single-CPU Athlon computer named "ecollege". There are a total of 33 validated results for this computer presently on the web site. It has actually run many more, but they vanish from the web site after a few weeks. I have averaged all 33 validated results still on the web as I write.
The second average is for the Athlon-MP during the period it has been running your version of BOINC. There are a total of 8 such validated results on the web as I write this.
Ecollege claims about 40 points more than addtron-ga, and BOINC is influenced by those larger claims to grant it about 20 more credits than addtron-ga (although all WUs are nearly the same).
Note also that the granted credits for ecollege are only about 1/2 point less than the claimed credits. I think that means that ecollege is claiming only very slightly more than the average of the other computers that worked on the same WUs. So ecollege appears to be fairly typical in its claims.
But addtron-ga is granted about 20 more points than it claimed. That is because the average of the other computers that worked on the same WUs claimed far more points than it did.
I'm talking to myself here. An hour ago, I posted the following table of requested ("claimed") & granted credits for two computers.
>
> Here are the averages.
>
> Computer_____claimed_______granted
> ecollege______86.27_________85.73
> addtron_ga____46.27_________66.73
Since ben seems to be using average data in his version of BOINC, I decided to try one more computer. These are results for an Intel P4 doing hyperthreading. This computer made claims that are very high & quite stable during this period. There are 33 validated results still on the website. The averages are:
> The variations in
)
> The variations in benchmarks are rather odd, but I won't comment further
> because they don't seem big enough to account for the requested credits
> problem. I am more inclined to suspect that there is a factor-of-two (2 CPUs)
> problem somewhere in the BOINC claimed credits calculation.
>
Aha, on the host itself if you run the benchmarks, you will see regular numbers that boinc normally reports...but...
have you looked at the website listing for "your computers" and the host in question?.
Thats where my code reports these new "project specific benchmarks".
In your case your "AMD K7-XP, Athlon XP 2200+ MP, 1799Mhz, (Palomino-662-0)" machine sends a benchmark report to the servers of:
Measured floating point speed: 1536.98 million ops/sec
Measured integer speed: 1536.98 million ops/sec
This causes the server for the WU of 26,038.23 seconds issue a "claimed credit" of 46.32.
Now, 46.32 is probably way too low, I will grant you...but. The server gets this number (and my code generates its benchmark) based on the server claim that each WU only contains 20x10^12 FP Operations.
However, if you installed this boinc client on multiple machines, and each of them got this WU...they would all claim 46 +/-3 credits for it.
Back when einstein was in alpha phase, and their WUs were shorter for debugging purposes, they still claimed 20x10^12 for WUs that took 2 hours or so.
To allow claims to be more in the 70 range, I would have to (and probably will) put a special case "if" statement...like "if project = einstein and estimated FP ops is 20x10^12, then est_FPops is really more like 31x10^12".
Also, if your machine did run into a short WU of say 50% normal time to crunch...the project benchmark only changes slowly, so that WU would send nearly identical benchmark info along with the report of 1/2 normal seconds...and credit claimed would be about 1/2 normal.
What are granted claims averaging for Einstein, say...calculated over 100 validated WUs?
New version
)
New version posted.
Change:
If WU downloaded from einstein, on host change est_fpops to 31e12.
If WU time being calculated and estimate between 19 and 21e12, and proj=einstein, make it be 31e12.
Server will still believe est_ops to be 20e12, and calculate fpops with now larger benchmarks (same time, larger est_fpops).
Quirk: If you have run my code on your host before, your project benchmark will be low and will adjust itself to the correct # over the course of approx 7 WUs.
If you want to skip this period, edit "client_state.xml" file and change
prj_secs_total
prj_fpops_done
prj_fpops
values to zero for the einstein project section.
[Ben, before I respond, I
)
[Ben, before I respond, I noticed that you posted two rather detailed responses to me. I did not expect my griping to attract that much attention, but I hope maybe even BOINC can be improved in some way by detailed discussion.]
ben wrote,
> Aha, on the host itself if you run the benchmarks, you will see regular
> numbers that boinc normally reports...but...
> have you looked at the website listing for "your computers" and the host in
> question?.
Yep, I did look there too, & I reported those website numbers in the last line of my table. "1536" for both the float & int benchmarks. I noticed that difference, but i did not understand it. I still don't understand the details, but I get your point that there is some standard modification in the float & int benchmarks to adapt them to this or that project.
After reconsidering, though, I now think all the win reports of the int benchmarks given by BOINC & reported in my table are too low by about a factor of two or more. The int benchmarks on this computer should be roughly 3000 (based on comparison with similar single-CPU computers). I don't know what causes this in BOINC.
> This causes the server for the WU of 26,038.2 seconds issue a "claimed
> credit" of 46.32.
> Now, 46.32 is probably way too low,
Yep.
>I will grant you...but. The server gets
> this number (and my code generates its benchmark) based on the server
> claim that each WU only contains 20x10^12 FP Operations.
>
> However, if you installed this boinc client on multiple machines, and each of
> them got this WU...they would all claim 46 +/-3 credits for it.
Sorry, but I just can't believe this last claim. I've looked at a great many WUs processed by the computers I run & by others who process the same WUs, & I see no evidence of any significant variation in the amount of computing power required to process them since I arrived at E@H. I think you might have brought this point up also in your second response to me, so I'll set it aside for the moment & hope to come back to it again.
> To allow claims to be more in the 70 range, I would have to (and probably
> will) put a special case "if" statement...like "if project = einstein and
> estimated FP ops is 20x10^12, then est_FPops is really more like 31x10^12".
You might be right that E@H is badly estimating the amount of computing power required for their units. If so, it should certainly be corrected. But I don't have any information about that. What I perceive is, rather, inconsistency among various computers all processing the same unit. I have information about that because I can read (& anyone who chooses can read) the variation in claimed credits when several computers process the same unit (as always happens).
> What are granted claims averaging for Einstein, say...calculated over 100
> validated WUs?
I don't have that average. I agree that the inconsistencies in claimed credits are reduced by the system for granted credits. But if there are some "outcast" computers that are assigned too low a claimed credit by BOINC, then they will end up with fewer granted credits too.
Here is the very tedious argument (by example):
Suppose 20% of all computers are outcasts & are assigned claimed credits of 50.
The other 80% are incasts assigned claimed credits of 100.
If I own an incast computer & I am sent a WU, then I know there is 100% probability that one computer for that WU will be an incast & there is an 80% probablity that each of the other two will be incasts too. There is then a probability of (1.00*0.80*0.80) = 64% that there will be ZERO outcasts processing that WU, in which case I am CERTAIN of getting the full 100 credits.
But if I own an outcast computer & I am sent a WU, then I know with 100% probability that I will NEVER process a WU in which all three processors will be
incasts, so I will never reach that complete certainty of 100 credits that the incast will reach with 64% of his units. My very presence as an outast shifts the odds against me.
ADDMP
ADDMP, While I agree any
)
ADDMP,
While I agree any changes to the client can't guarantee that the claimed credit will be the value granted (as others are using the official boinc client)
...I can state that the code changes I have made to my version of the client will "claim" nearly identical credits for identically difficult WUs, regardless of what machine they are run on (with my client).
My code simply takes a running average of the completion times for the most recent 7 WUs for a project. (running average = updates as it goes along).
It then computes how many "project specific" FP ops are being crunched per second.
= [estimated_FP_OPS_from_server_downloaded_with_WU] / [num secs per WU].
It omits really short time WUs to the average...which would really inflate the supposed FP_OPS speed (31e12 ops in 300 seconds vs 31e12 ops in 24,000 seconds)
This is the project specific benchmark. Try it out with any reported CPU time of any of your hosts.
Then use that value in the claimed credit equation.
=(FP_bench+INT_bench)/1000 * 100/(2*secsPerDay)
(Note: both benchmarks are reported on your host info web page as MegaFlops, so I use that value in the formula above, but in truth they are stored in simple FPOPS_per_sec)
ben wrote, > While I agree
)
ben wrote,
> While I agree any changes to the client can't guarantee that the claimed
> credit will be the value granted (as others are using the official boinc
> client
> ...I can state that the code changes I have made to my version of the client
> will "claim" nearly identical credits for identically difficult WUs,
> regardless of what machine they are run on (with my client).
Very good if your programming changes produce claims internally consistent among all those computers using them. Next step is to make those internally consistent claims hit at about average for all other computers that are using the standard BOINCs. That seems fair. A simple fudge factor should be sufficient.
> My code simply takes a running average of the completion times for the most
> recent 7 WUs for a project. (running average = updates as it goes along).
>
> It then computes how many "project specific" FP ops are being crunched per
> second.
> = [estimated_FP_OPS_from_server_downloaded_with_WU] / [num secs per WU].
>
> It omits really short time WUs to the average...which would really inflate the
> supposed FP_OPS speed (31e12 ops in 300 seconds vs 31e12 ops in 24,000
> seconds)
Good, the completion times for actual WUs sound like solid data to serve as a basis for comparing various computers all running E@H. It also sounds as if it should work for hyperthreading computers, whereas running Whetstones or Dhrystones sounds dubious with HTs because they might compete between threads for the CPU resources in a different way from the project's coding.
Using FP_OPS per WU does not sound reliable AMONG VARIOUS PROJECTS, because different projects might have quite a different mix of floats vs. ints.
But you seem to be moving toward adopting a different fudge factor for each project. That sounds OK as an ad hoc correction for the differing mix of floats vs ints among different projects. Hopefully the mix of floats & ints will be reasonably stable within each project.
> This is the project specific benchmark. Try it out with any reported CPU time
> of any of your hosts.
>
> Then use that value in the claimed credit equation.
> =(FP_bench+INT_bench)/1000 * 100/(2*secsPerDay)
I would like to try it myself. It starts with "estimated_FP_OPS_from_server_downloaded_with_WU". How do I get this number?
Thanks for these details on the technique you are developing. All interesting.
ADDMP
>I would like to try it
)
>I would like to try it myself. It starts with
>"estimated_FP_OPS_from_server_downloaded_with_WU". How do I get this number?
For all projects currently, it is a fixed number. No project is required to have it be a fixed number..but all currently choose to.
Seti = 27.9e12
Einstein = 20e12
LHC = ??
Predictor = ??
------------------
>But you seem to be moving toward adopting a different fudge factor for each project.
I would call it rather a "project benchmark", which uses actual WUs computing to deterimine the value...rather than computing a Whetstone WU, etc.
Ben wrote, > I would call
)
Ben wrote,
> I would call it rather a "project benchmark", which uses actual WUs computing
> to deterimine the value...rather than computing a Whetstone WU, etc.
You are certainly entitled to name your own parameters.
> >I would like to try it myself. It starts with
> >"estimated_FP_OPS_from_server_downloaded_with_WU". How do I get this
> number?
>
> For all projects currently, it is a fixed number. No project is
> required to have it be a fixed number..but all currently choose to.
>
> Seti = 27.9e12
> Einstein = 20e12
> LHC = ??
> Predictor = ??
> ------------------
Sorry, I did try it myself, but did not quite get it.
My MP computer processes a unit in about 26,000 sec.
Then for E@H your
project_specific_benchmark = 20E12/26000=7.69E8 for my MP computer. If converted to MFLOPS, this is about a factor of 2 off from the numbers that your version of BOINC reports to the website.
Then your equation, using C's left_to_right grouping rule, is
claimed_credits=(((FP_bench+INT_bench)/1000)*100)/(2*secsPerDay)
I now replace both FP_bench and INT_bench by the project_specific_benchmark above & get
claimed_credits=(((2*7.69E8)/1000)*100)/(2*24*3600)=890 credits.
as compared to about 46 reported by your version of BOINC.
If I change your project_specific_benchmark from FLOPS to MFLOPS, then I get a number 1 million times smaller, which still does not work. Seems off by a factor of 2 and some factors of ten. [The factor of 2 seems like a good idea to me. I hope there is some way you can hang on to it. :) ]
ADDMP
Addmp, Sorry my bad. Just
)
Addmp,
Sorry my bad. Just checked a machine with Einstein running on it...opened the client_state.xml file and looked for est_fpops for a einstein WU.
40000000000000.000000
So it was 40e12 not 20e12.
so your [prj_fpops] = 40e12/26000 = 1.5385e9 -- On web page this would be reported as 1,538 MFlops.
Next claimed credit - We use the website reported value (MFlops) in the formula...
claimed_credits_per_sec=(((2*1538)/1000)*100)/(2*24*3600) = 1.7801e-3.
This part I left out..sorry bout that (My bad again)
claimed_credit = seconds_for_wu * claimed_credits_per_sec;
claimed_credit = 26000 * 1.7801e-3 = 46.2824
----
Now lets try it for your Intel P4 3.0Ghz Hyperthread machine.
Average WU time = 41100.
prj_fpops = 40e12/41000 = 9.732e8 (a little more than 1/2 the above project benchmark)
claimed_credits_per_sec=(((2*973)/1000)*100)/(2*24*3600)=1.126e-3
claimed_credit = 41100 * 1.126e-3 = 46.2850
----
This version of boinc_gui.exeFile checks if project is "einstein" and est_FPOPS are 40e12...if yes then it changes it to 62e12.
P.S.: Predictor@home uses 20e12 est_fpops.
ben wrote, > This version
)
ben wrote,
> This version of href="https://einsteinathome.org/%3Ca%20href%3D"http://www.freewebs.com/gladry/boinc_gui.exeFile">http://www.freewebs.com/gladry/boinc_gui.exeFile">boinc_gui.exeFile[/url]
> checks if project is "einstein" and est_FPOPS are 40e12...if yes then it
> changes it to 62e12.
Thanks. I have now started up this new executable on my MP computer addtron-ga
It is a very "touchy" gui. I cannot open it because if I merely place the mouse pointer over the icon, it shuts itself down & disappears. But I think it runs if I don't touch it, so I will let it run for a while to see if it posts any results on the web site.
Thanks also for your revisions here. I will take a look at them.
Several messages ago you asked me a question:
>What are granted claims averaging for Einstein, say...calculated over 100 >validated WUs?
I have now tried to calculate some averages. My first average was for a single-CPU Athlon computer named "ecollege". There are a total of 33 validated results for this computer presently on the web site. It has actually run many more, but they vanish from the web site after a few weeks. I have averaged all 33 validated results still on the web as I write.
The second average is for the Athlon-MP during the period it has been running your version of BOINC. There are a total of 8 such validated results on the web as I write this.
Here are the averages.
Computer_____claimed_______granted
ecollege______86.27_________85.73
addtron_ga____46.27_________66.73
Ecollege claims about 40 points more than addtron-ga, and BOINC is influenced by those larger claims to grant it about 20 more credits than addtron-ga (although all WUs are nearly the same).
Note also that the granted credits for ecollege are only about 1/2 point less than the claimed credits. I think that means that ecollege is claiming only very slightly more than the average of the other computers that worked on the same WUs. So ecollege appears to be fairly typical in its claims.
But addtron-ga is granted about 20 more points than it claimed. That is because the average of the other computers that worked on the same WUs claimed far more points than it did.
ADDMP
I'm talking to myself here.
)
I'm talking to myself here. An hour ago, I posted the following table of requested ("claimed") & granted credits for two computers.
>
> Here are the averages.
>
> Computer_____claimed_______granted
> ecollege______86.27_________85.73
> addtron_ga____46.27_________66.73
Since ben seems to be using average data in his version of BOINC, I decided to try one more computer. These are results for an Intel P4 doing hyperthreading. This computer made claims that are very high & quite stable during this period. There are 33 validated results still on the website. The averages are:
Computer______claimed_________granted
yeongw2k______103.08__________85.59__
Since these high claims must have dragged up the average granted credits, this data makes a number of 85 look too high to be typical.
It's difficult to get a representative average by looking at the credits of only a few computers. The processes are not really random.
ADDMP