The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again). By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
I can think of another reason. For an increased CI, the number of WUs to be reported is larger. Statistics say that for an increased number of samples, its average becomes closer to the real average (i.e. for an infinite number of samples). Simply stated: the larger the number of reported WUs, the smaller is the standard deviation. That would explain smaller fluctuations with a longer CI. I did not run tests like yours, but I cannot imagine there's a difference in RAC for two different CI when a fixed number of WUs are reported. After all: independent of CI, a computer will report a certain number of WUs in a certain period.
Quote:
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
Alinator
If I'm following you correctly
Quote:
solely dependant on not running out of work
should mean that, all local conditions thought of as beeing constant, diminishing your CI would have BOINC to knock more often on your door for uploading and downloading and that sounds like raising the effectiveness to me. As concern's this pending business I think of it as a line of my crunched and uploaded wus at BOINCs sevrer (?), i e my account, waiting to be evaluated and then credited for. Could a growing line of wus pending due to some bottleneck at the server lower the RAC in any way? If the speed of evaluating and crediting single units as such is inversely proportional to how many wus there are pending it should be the case but it sounds odd to me or perhaps am I wrong here. It should be a matter of "not running out of work" here too I guess, ideally a bucket-brigade never to halt.
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
Alinator
If I'm following you correctly
Quote:
solely dependant on not running out of work
should mean that, all local conditions thought of as beeing constant, diminishing your CI would have BOINC to knock more often on your door for uploading and downloading and that sounds like raising the effectiveness to me. As concern's this pending business I think of it as a line of my crunched and uploaded wus at BOINCs sevrer (?), i e my account, waiting to be evaluated and then credited for. Could a growing line of wus pending due to some bottleneck at the server lower the RAC in any way? If the speed of evaluating and crediting single units as such is inversely proportional to how many wus there are pending it should be the case but it sounds odd to me or perhaps am I wrong here. It should be a matter of "not running out of work" here too I guess, ideally a bucket-brigade never to halt.
neubaum
An afterthougth. If BOINC is monitoring the host, benchmmarks and preferences, and try to adapt to changes there by some fixed aimed-at-optimizing formulae, you have a nonlinear "situation" don't you? And you'd expect a "chaotic" behavior once in a while. This is just a hunch from somebody not educated in maths above college level but a devote reader of popular litterature on this subject. So, in that case, it is not only a matter of the complexity in terms of amount of variables involved, but also in terms of a non-linearity of the BOINC-host system. Happy to have comments on this. — My RAC is still climbing after my returning from former CI=0.25 to the "original" CI=0.05, that I think was the default, or was it 0.5? I'm keeping a log of changes of preferences now that I didn't at the time crucial for the observations above. I'll stick to 0.05 for a wile and then lower it still and see what happens.
neubaum :-?
I can think of another reason. For an increased CI, the number of WUs to be reported is larger. Statistics say that for an increased number of samples, its average becomes closer to the real average (i.e. for an infinite number of samples). Simply stated: the larger the number of reported WUs, the smaller is the standard deviation. That would explain smaller fluctuations with a longer CI. I did not run tests like yours, but I cannot imagine there's a difference in RAC for two different CI when a fixed number of WUs are reported. After all: independent of CI, a computer will report a certain number of WUs in a certain period.
Bert
Agreed, and strictly speaking from your own hosts point of view, it's irrelevent whether it reports 100 granted credits every 10 hours or 1000 granted credits every 100 hours. It still works out to the same RAC even with the exponential decay. The only difference I have found is the "offset" in time between the report and the granting event when I run the short CI due to having to wait for other hosts. IOW, the short CI tends to make the project reported RAC value jump around it's steady state value more, as determined from my long term data.
I suppose I should have differentiated before between what the project reports for RAC (inherantly short term, since it's only concerned with what happened in the time interval between credit events) and the averages you get from local long term tracking of your output. ;-)
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
Alinator
If I'm following you correctly
Quote:
solely dependant on not running out of work
should mean that, all local conditions thought of as beeing constant, diminishing your CI would have BOINC to knock more often on your door for uploading and downloading and that sounds like raising the effectiveness to me. As concern's this pending business I think of it as a line of my crunched and uploaded wus at BOINCs sevrer (?), i e my account, waiting to be evaluated and then credited for. Could a growing line of wus pending due to some bottleneck at the server lower the RAC in any way? If the speed of evaluating and crediting single units as such is inversely proportional to how many wus there are pending it should be the case but it sounds odd to me or perhaps am I wrong here. It should be a matter of "not running out of work" here too I guess, ideally a bucket-brigade never to halt.
neubaum
An afterthougth. If BOINC is monitoring the host, benchmmarks and preferences, and try to adapt to changes there by some fixed aimed-at-optimizing formulae, you have a nonlinear "situation" don't you? And you'd expect a "chaotic" behavior once in a while. This is just a hunch from somebody not educated in maths above college level but a devote reader of popular litterature on this subject. So, in that case, it is not only a matter of the complexity in terms of amount of variables involved, but also in terms of a non-linearity of the BOINC-host system. Happy to have comments on this. — My RAC is still climbing after my returning from former CI=0.25 to the "original" CI=0.05, that I think was the default, or was it 0.5? I'm keeping a log of changes of preferences now that I didn't at the time crucial for the observations above. I'll stick to 0.05 for a wile and then lower it still and see what happens.
neubaum :-?
It's not that the short CI will make the "steady state value" of RAC go up or down. That should stay the same if you don't run out of work or change the resource share, just that it tends to move more around that value as reported by the project.
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
Alinator
If I'm following you correctly
Quote:
solely dependant on not running out of work
should mean that, all local conditions thought of as beeing constant, diminishing your CI would have BOINC to knock more often on your door for uploading and downloading and that sounds like raising the effectiveness to me. As concern's this pending business I think of it as a line of my crunched and uploaded wus at BOINCs sevrer (?), i e my account, waiting to be evaluated and then credited for. Could a growing line of wus pending due to some bottleneck at the server lower the RAC in any way? If the speed of evaluating and crediting single units as such is inversely proportional to how many wus there are pending it should be the case but it sounds odd to me or perhaps am I wrong here. It should be a matter of "not running out of work" here too I guess, ideally a bucket-brigade never to halt.
neubaum
An afterthougth. If BOINC is monitoring the host, benchmmarks and preferences, and try to adapt to changes there by some fixed aimed-at-optimizing formulae, you have a nonlinear "situation" don't you? And you'd expect a "chaotic" behavior once in a while. This is just a hunch from somebody not educated in maths above college level but a devote reader of popular litterature on this subject. So, in that case, it is not only a matter of the complexity in terms of amount of variables involved, but also in terms of a non-linearity of the BOINC-host system. Happy to have comments on this. — My RAC is still climbing after my returning from former CI=0.25 to the "original" CI=0.05, that I think was the default, or was it 0.5? I'm keeping a log of changes of preferences now that I didn't at the time crucial for the observations above. I'll stick to 0.05 for a wile and then lower it still and see what happens.
neubaum :-?
It's not that the short CI will make the "steady state value" of RAC go up or down. That should stay the same if you don't run out of work or change the resource share, just that it tends to move more around that value as reported by the project.
Alinator
Well, this seems to go beyond my level. Anyhow, I beleive I could raise my opportunity not getting out of work by speeding up the interchange between me (the host) and BOINC, and thereby lowering the CI to an optimal level matching my (local) resources and the preferences as noted by BOINC. — I'm not aiming for top RAC. I am just curious about how it works and strives for perferction.
The length of CI does not depend on stability on RAC
Don't you mean the other way around? Otherwise I guess I'm lost (again).
You're right; to err is human ;) Sorry about the confusion!
Quote:
By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
Alinator
If I'm following you correctly
Quote:
solely dependant on not running out of work
should mean that, all local conditions thought of as beeing constant, diminishing your CI would have BOINC to knock more often on your door for uploading and downloading and that sounds like raising the effectiveness to me. As concern's this pending business I think of it as a line of my crunched and uploaded wus at BOINCs sevrer (?), i e my account, waiting to be evaluated and then credited for. Could a growing line of wus pending due to some bottleneck at the server lower the RAC in any way? If the speed of evaluating and crediting single units as such is inversely proportional to how many wus there are pending it should be the case but it sounds odd to me or perhaps am I wrong here. It should be a matter of "not running out of work" here too I guess, ideally a bucket-brigade never to halt.
neubaum
An afterthougth. If BOINC is monitoring the host, benchmmarks and preferences, and try to adapt to changes there by some fixed aimed-at-optimizing formulae, you have a nonlinear "situation" don't you? And you'd expect a "chaotic" behavior once in a while. This is just a hunch from somebody not educated in maths above college level but a devote reader of popular litterature on this subject. So, in that case, it is not only a matter of the complexity in terms of amount of variables involved, but also in terms of a non-linearity of the BOINC-host system. Happy to have comments on this. — My RAC is still climbing after my returning from former CI=0.25 to the "original" CI=0.05, that I think was the default, or was it 0.5? I'm keeping a log of changes of preferences now that I didn't at the time crucial for the observations above. I'll stick to 0.05 for a wile and then lower it still and see what happens.
neubaum :-?
It's not that the short CI will make the "steady state value" of RAC go up or down. That should stay the same if you don't run out of work or change the resource share, just that it tends to move more around that value as reported by the project.
Alinator
Well, this seems to go beyond my level. Anyhow, I beleive I could raise my opportunity not getting out of work by speeding up the interchange between me (the host) and BOINC, and thereby lowering the CI to an optimal level matching my (local) resources and the preferences as noted by BOINC. — I'm not aiming for top RAC. I am just curious about how it works and strives for perferction.
neubaum
In that case, use a higher CI. Not for RAC, but just for lowering the risk of running out of work. RAC itself is not important anyway, the number of reported WUs is. That's what the project is about, and that's what you get credited for. RAC is merely a monitoring tool for a first check to see something's wrong with your computer (although some think otherwise).
It's just like driving a car. You want to reach your destination (number of reported WUs). But if your car slows (RAC goes down), it gives a clue something is wrong. Not necessarily, as you could be standing for a stop sign, for example. It's simply impossible to keep the same speed (RAC) at all times.
RE: The length of CI does
)
Don't you mean the other way around? Otherwise I guess I'm lost (again). By the way — stability is nice of course, but what about the level. You should try raising it as much as possible or ..? Even if the RAC is dependent on a lot of things beyound your contol the higher the better as it mirrors how much is produced within some given timespan?
RE: RE: The length of CI
)
You're right; to err is human ;) Sorry about the confusion!
Raising RAC is always good, because it's a measure of performance (but not the best measure though because it's depending on too many factors as you already mentioned). The best way to check performance is to recrunch a WU several times, and apply statistics on the crunch time. The faster, the better. Of course, you can check similar WUs (with same credit) to estimate an average performance. But then differences in two WUs can accomodate for a difference in crunching times.
On the other hand, a low RAC does not necessarily mean bad performance due to the external factors beyond control.
Therefore, you can check RAC as a first sight of performance. If it's too low for your feeling, check the actual crunching times of past WUs, and the pending credits.
Happy crunching,
Bert
Somnio ergo sum
RE: RE: RE: The length
)
Generally, I agree here that one needs to take RAC with a grain of salt when it comes to measuring the absolute output performance of a given host, which is solely dependant on not running out of work, or other local problems (like a lot of other background load, other computationally intensive work, etc.).
However, the statisical stability of it is dependant to a degree on the CI. I have been logging and tracking the performance of my hosts for well over a year, and have found the standard deviation and the variance of RAC for all of them is the smallest when I set a CI which minimizes the number of pendings I have in my account. Keep in mind, we're not talking about an order of magnitude difference here, but a measureable one none the less. The reason is simple, mine are the ones determining when the credit gets granted (here at EAH) or are reporting after validation has happened (over at SAH for example).
Bottom line is RAC is a good indicator of problems which might require your attention, or at least a checkup on what's going on with your hosts and/or the projects your attached to. On the other hand, if your hosts have been working through the WU's in their normal fashion, then there is no real reason to get too worked up if RAC varies up or down somewhat.
Alinator
RE: RE: RE: RE: The
)
I can think of another reason. For an increased CI, the number of WUs to be reported is larger. Statistics say that for an increased number of samples, its average becomes closer to the real average (i.e. for an infinite number of samples). Simply stated: the larger the number of reported WUs, the smaller is the standard deviation. That would explain smaller fluctuations with a longer CI. I did not run tests like yours, but I cannot imagine there's a difference in RAC for two different CI when a fixed number of WUs are reported. After all: independent of CI, a computer will report a certain number of WUs in a certain period.
Agreed ;)
Bert
Somnio ergo sum
RE: RE: RE: RE: The
)
If I'm following you correctly
should mean that, all local conditions thought of as beeing constant, diminishing your CI would have BOINC to knock more often on your door for uploading and downloading and that sounds like raising the effectiveness to me. As concern's this pending business I think of it as a line of my crunched and uploaded wus at BOINCs sevrer (?), i e my account, waiting to be evaluated and then credited for. Could a growing line of wus pending due to some bottleneck at the server lower the RAC in any way? If the speed of evaluating and crediting single units as such is inversely proportional to how many wus there are pending it should be the case but it sounds odd to me or perhaps am I wrong here. It should be a matter of "not running out of work" here too I guess, ideally a bucket-brigade never to halt.
neubaum
RE: RE: RE: RE: Quote
)
An afterthougth. If BOINC is monitoring the host, benchmmarks and preferences, and try to adapt to changes there by some fixed aimed-at-optimizing formulae, you have a nonlinear "situation" don't you? And you'd expect a "chaotic" behavior once in a while. This is just a hunch from somebody not educated in maths above college level but a devote reader of popular litterature on this subject. So, in that case, it is not only a matter of the complexity in terms of amount of variables involved, but also in terms of a non-linearity of the BOINC-host system. Happy to have comments on this. — My RAC is still climbing after my returning from former CI=0.25 to the "original" CI=0.05, that I think was the default, or was it 0.5? I'm keeping a log of changes of preferences now that I didn't at the time crucial for the observations above. I'll stick to 0.05 for a wile and then lower it still and see what happens.
neubaum :-?
RE: I can think of another
)
Agreed, and strictly speaking from your own hosts point of view, it's irrelevent whether it reports 100 granted credits every 10 hours or 1000 granted credits every 100 hours. It still works out to the same RAC even with the exponential decay. The only difference I have found is the "offset" in time between the report and the granting event when I run the short CI due to having to wait for other hosts. IOW, the short CI tends to make the project reported RAC value jump around it's steady state value more, as determined from my long term data.
I suppose I should have differentiated before between what the project reports for RAC (inherantly short term, since it's only concerned with what happened in the time interval between credit events) and the averages you get from local long term tracking of your output. ;-)
Alinator
RE: RE: RE: RE: Quote
)
It's not that the short CI will make the "steady state value" of RAC go up or down. That should stay the same if you don't run out of work or change the resource share, just that it tends to move more around that value as reported by the project.
Alinator
RE: RE: RE: RE: Quote
)
Well, this seems to go beyond my level. Anyhow, I beleive I could raise my opportunity not getting out of work by speeding up the interchange between me (the host) and BOINC, and thereby lowering the CI to an optimal level matching my (local) resources and the preferences as noted by BOINC. — I'm not aiming for top RAC. I am just curious about how it works and strives for perferction.
neubaum
RE: RE: RE: RE: Quote
)
In that case, use a higher CI. Not for RAC, but just for lowering the risk of running out of work. RAC itself is not important anyway, the number of reported WUs is. That's what the project is about, and that's what you get credited for. RAC is merely a monitoring tool for a first check to see something's wrong with your computer (although some think otherwise).
It's just like driving a car. You want to reach your destination (number of reported WUs). But if your car slows (RAC goes down), it gives a clue something is wrong. Not necessarily, as you could be standing for a stop sign, for example. It's simply impossible to keep the same speed (RAC) at all times.
Bert
Somnio ergo sum