I'm glad to hear that the credit issue will be sorted out with S5. I put AkosF's apps in last week and didn't really think much of the credit issue until I saw just how substantial the reduction in crunch time was. When I claimed 12 and got 60 I on a WU I realized something was up. I'm just blown away by the improvements to the code, btw and I'm now dedicating more resources to the project to take advantage of the efficiency.
Re: Calibration, is trux staying current? I'm using Crunch3r's modified benchmark code to compensate for now, since he seems to be on the same version. The benchmark won't affect the other projects, as my Einstein machines only run SETI Enhanced and CPDN on the side, neither of which cares about benchmarks.
Anyhow, sorry if any of my lowball claims affected anyone.
Re: Calibration, is trux staying current? I'm using Crunch3r's modified benchmark code to compensate for now, since he seems to be on the same version. The benchmark won't affect the other projects, as my Einstein machines only run SETI Enhanced and CPDN on the side, neither of which cares about benchmarks.
Trux said quite some time back not to expect further releases for a while, and that has been true.
On the other hand, lots of us run tx36 (his last non-withdrawn "production" version, I believe). This is modern enough to pass through the current SETI enhanced scheme. I suggest enabling calibration for Einstein only. That would mean your SETI CPU times will be reported as-is, otherwise they'll get adjusted. I can't address and CPDN compatibility issues, but if they are ignoring benchmarks it is a good start. Even with calibration turned off, tx36 benchmarks are not matched to the standard client. But it sounds like for all three cases you mention that won't be an issue.
BTW, now you don't need 3 results to make granted credit "fair" any longer, will this also mean can decrease min_quorum to 2 and get a further 50% speed-up, or is the results so variable that still needs 3 to make sure validated scientific results?
The problem with a quorum of two is the lack of "redundency". With only two results the chances of them differing is significant and you are unable to tell which is "correct" (that is not to say right). With a quorum of three, the third result acts as a cross check for the other two.
Please remember that study completion times are not as important as study verification. We HAVE to make sure we can verify and validate any results published.
The problem with a quorum of two is the lack of "redundency". With only two results the chances of them differing is significant and you are unable to tell which is "correct" (that is not to say right). With a quorum of three, the third result acts as a cross check for the other two.
Please remember that study completion times are not as important as study verification. We HAVE to make sure we can verify and validate any results published.
If the 2 results isn't similar enough a 3rd. copy will be sent-out...
So, the questions would rather be, how often is the 3rd. copy needed, if example 50% of the time always sending-out 3 copies doesn't put any large extra load, but if it's only 1% or something it's mostly wasted...
Also, if the 2 results is exactly the same, is a 3rd. needed to further make sure the science is correct?
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
If the 2 results isn't similar enough a 3rd. copy will be sent-out...
So, the questions would rather be, how often is the 3rd. copy needed, if example 50% of the time always sending-out 3 copies doesn't put any large extra load, but if it's only 1% or something it's mostly wasted...
Also, if the 2 results is exactly the same, is a 3rd. needed to further make sure the science is correct?
The 3rd copy increases the safety of the science.
example: The application of SZTAKI project generates a very simple result file. That usually consists 100 times the 'Negative' word, other results are very curiosity. Some people made a simple code that always send back 'Negative' results (very fast), so they results are usually validated. If it's a thousand to one that two false results meet that means about 0,1% of the wus are unprocessed at quorum of 2, but only 0,0001% at quorum of 3, etc...
The problem with a quorum of two is the lack of "redundency". With only two results the chances of them differing is significant and you are unable to tell which is "correct" (that is not to say right). With a quorum of three, the third result acts as a cross check for the other two.
The old mariner's saying:
"When going to sea,
take one clock or three..."
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
The problem with a quorum of two is the lack of "redundency". With only two results the chances of them differing is significant and you are unable to tell which is "correct" (that is not to say right). With a quorum of three, the third result acts as a cross check for the other two.
The old mariner's saying:
"When going to sea,
take one clock or three..."
Cheers, Mike.
A chair with three legs dosn´t jiggle
:-)
Chris
*Die Signatur befindet sich aus technischen Gründen auf der Rückseite dieses Beitrages!*
I just looked at your results page for that mean machine of your's. I have 1 question. Why do you need a cache of 1020 work units?
I know it's fast but give me a break.
Regards
Franz
Hi Franz, please have a look at Top computers. All of them have many results for a few reasons. First: fast machines have to wait for the pending results of other computers, this inflates the result-list. Next, if you have a fast machine you like to have some workunits in advance, specially when the server has a timeout und you're running out of work. And sometimes it happens that you get so much fastrunnig small workunits (@my machine they are done within less than 12 minutes, two of them because Dualcore), I need every day at least more than 70 of the long work units, I'd like to have a cache of minimum four days and the oldest pending workunit is older than two weeks. If you look at my resultlist you will find 1000 results.
Sorry about my bad English, hope blöd brot will have time to answer you either, I know that his English is much better than mine.
I'm glad to hear that the
)
I'm glad to hear that the credit issue will be sorted out with S5. I put AkosF's apps in last week and didn't really think much of the credit issue until I saw just how substantial the reduction in crunch time was. When I claimed 12 and got 60 I on a WU I realized something was up. I'm just blown away by the improvements to the code, btw and I'm now dedicating more resources to the project to take advantage of the efficiency.
Re: Calibration, is trux staying current? I'm using Crunch3r's modified benchmark code to compensate for now, since he seems to be on the same version. The benchmark won't affect the other projects, as my Einstein machines only run SETI Enhanced and CPDN on the side, neither of which cares about benchmarks.
Anyhow, sorry if any of my lowball claims affected anyone.
RE: Re: Calibration, is
)
Trux said quite some time back not to expect further releases for a while, and that has been true.
On the other hand, lots of us run tx36 (his last non-withdrawn "production" version, I believe). This is modern enough to pass through the current SETI enhanced scheme. I suggest enabling calibration for Einstein only. That would mean your SETI CPU times will be reported as-is, otherwise they'll get adjusted. I can't address and CPDN compatibility issues, but if they are ignoring benchmarks it is a good start. Even with calibration turned off, tx36 benchmarks are not matched to the standard client. But it sounds like for all three cases you mention that won't be an issue.
And thanks for thinking of your quorum partners.
Well, we have some delightful
)
Well, we have some delightful news from Bruce, and many thanks to him!
So S5 is coming soon, and to a computer near you! How exciting!
Optimisations across the platforms! Even more exciting!
Fixed or 'prepaid' credit! This will evaporate many current concerns, but what will we talk about now....? :-)
Splendid.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: BTW, now you don't
)
The problem with a quorum of two is the lack of "redundency". With only two results the chances of them differing is significant and you are unable to tell which is "correct" (that is not to say right). With a quorum of three, the third result acts as a cross check for the other two.
Please remember that study completion times are not as important as study verification. We HAVE to make sure we can verify and validate any results published.
RE: The problem with a
)
If the 2 results isn't similar enough a 3rd. copy will be sent-out...
So, the questions would rather be, how often is the 3rd. copy needed, if example 50% of the time always sending-out 3 copies doesn't put any large extra load, but if it's only 1% or something it's mostly wasted...
Also, if the 2 results is exactly the same, is a 3rd. needed to further make sure the science is correct?
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
RE: If the 2 results isn't
)
The 3rd copy increases the safety of the science.
example: The application of SZTAKI project generates a very simple result file. That usually consists 100 times the 'Negative' word, other results are very curiosity. Some people made a simple code that always send back 'Negative' results (very fast), so they results are usually validated. If it's a thousand to one that two false results meet that means about 0,1% of the wus are unprocessed at quorum of 2, but only 0,0001% at quorum of 3, etc...
RE: The problem with a
)
The old mariner's saying:
"When going to sea,
take one clock or three..."
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: The problem with
)
A chair with three legs dosn´t jiggle
:-)
Chris
*Die Signatur befindet sich aus technischen Gründen auf der Rückseite dieses Beitrages!*
Hi bl?rot: I just looked
)
Hi bl?rot:
I just looked at your results page for that mean machine of your's. I have 1 question. Why do you need a cache of 1020 work units?
I know it's fast but give me a break.
Regards
Franz
RE: Hi bl?rot: I just
)
Hi Franz, please have a look at Top computers. All of them have many results for a few reasons. First: fast machines have to wait for the pending results of other computers, this inflates the result-list. Next, if you have a fast machine you like to have some workunits in advance, specially when the server has a timeout und you're running out of work. And sometimes it happens that you get so much fastrunnig small workunits (@my machine they are done within less than 12 minutes, two of them because Dualcore), I need every day at least more than 70 of the long work units, I'd like to have a cache of minimum four days and the oldest pending workunit is older than two weeks. If you look at my resultlist you will find 1000 results.
Sorry about my bad English, hope blöd brot will have time to answer you either, I know that his English is much better than mine.
hth faeshn
And Franz, you should join a Team, have a look at Special: Off-Topic