How is Recent Average Credit calculated?

neubaum
neubaum
Joined: 11 Sep 06
Posts: 23
Credit: 61959
RAC: 0

RE: The length of CI does

Message 47533 in response to message 47531

Quote:
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?

Lt. Cmdr. Daze
Lt. Cmdr. Daze
Joined: 19 Apr 06
Posts: 756
Credit: 82361
RAC: 0

RE: RE: The length of CI

Message 47534 in response to message 47533

Quote:
Quote:
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

Somnio ergo sum

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9352143
RAC: 0

RE: RE: RE: The length

Message 47535 in response to message 47534

Quote:
Quote:
Quote:
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

Lt. Cmdr. Daze
Lt. Cmdr. Daze
Joined: 19 Apr 06
Posts: 756
Credit: 82361
RAC: 0

RE: RE: RE: RE: The

Message 47536 in response to message 47535

Quote:
Quote:
Quote:
Quote:
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.

Alinator


Agreed ;)

Bert

Somnio ergo sum

neubaum
neubaum
Joined: 11 Sep 06
Posts: 23
Credit: 61959
RAC: 0

RE: RE: RE: RE: The

Message 47537 in response to message 47535

Quote:
Quote:
Quote:
Quote:
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

neubaum
neubaum
Joined: 11 Sep 06
Posts: 23
Credit: 61959
RAC: 0

RE: RE: RE: RE: Quote

Message 47538 in response to message 47537

Quote:
Quote:
Quote:
Quote:
Quote:
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 :-?

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9352143
RAC: 0

RE: I can think of another

Message 47539 in response to message 47536

Quote:

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. ;-)

Alinator

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9352143
RAC: 0

RE: RE: RE: RE: Quote

Message 47540 in response to message 47538

Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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

neubaum
neubaum
Joined: 11 Sep 06
Posts: 23
Credit: 61959
RAC: 0

RE: RE: RE: RE: Quote

Message 47541 in response to message 47540

Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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

Lt. Cmdr. Daze
Lt. Cmdr. Daze
Joined: 19 Apr 06
Posts: 756
Credit: 82361
RAC: 0

RE: RE: RE: RE: Quote

Message 47542 in response to message 47541

Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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.

Bert

Somnio ergo sum

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.