and I'd like to amplify that with an example: text entry devices.
It might seem that a phone keypad is simpler than a computer keyboard. The phone has fewer keys on it so it must be simpler, eh?
But then try typing in your code using a phone keypad. Suddenly, having the right number of controls for the task in hand, one key for each letter, seems a lot simpler than having to multi-key every letter.
But think again.
We don't actually have one key for every character on a computer keyboard. We have a shift key so that one letter key can do for both 'g' and 'G'. A keyboard where these were on separate keys would be harder to use, because the current design exploits the relationship between the characters.
Simplicity turns out to be quite subtle. It means having an appropriate number of controls for the job in hand, not too many and not too few. It means that it has to be a judgment call in each case, but simplicity is still never a pre-judgment that more options means more complex.
Further testing has uncovered another issue that might be important.
When no scheduler can be reached, the v4.45 client backs off exponentially at first (as it should), but then goes into a cycle of 1 minute backoffs.
Hopefully, I'm wrong and am overlooking something here. But if my concern is justifued, there exists a danger that after a server outage all the 4.45 clients in the world will try to check in together every minute or so; a kind of self-inflicted denial of service attack.
You can see the log demonstrating this effect here.
I've left the machine running, and will report again if it does eventually go back into the exponential backoff.
The break in service by the LHC scheduler was simulated locally and the real LHC is still up and running. I will, of course, reconnect it well before the LHC wu gets near its deadline and in the meantime no harm is being done to LHC nor to its stranded wu.
It's funny that you decided to agree with me ~~gravywavy, because after reading up on how LTD and STD work i think we can make your idea work just fine. Now, we have to balance LTD separately on every level as i suggested to keep track of work done on each level and to make the numbers as small as possible. Now i was wrong about the STD. After reading up on how the STD works, i agree on that it would work as you originally suggested. So the code for STD would not have to be changed from what we have today.
Edit
EDF would solve any problems that i originally thought of between the levels.
/Edit
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
It's funny that you decided to agree with me ~~gravywavy, because after reading up on how LTD and STD work i think we can make your idea work just fine ...
we are obviously both quite persuasive,
or maybe it is like a football match where we change ends at half time ;-)
thanks for taking so much care in thinking about my suggestion Ziran. I am not clear, are you one of the project devs? Or developing an alternative client? Or just helping me think through the effects of my suggestion?
I am just an ordinary participant. So i am only helping you think through the effects of your suggestion and hopefully give some worthwhile input in the process.
I am running on a 600 MHz Celeron, so my biggest contribution to the BOINC community will probably be in the forums.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
I said RE: I'd
)
I said
and I'd like to amplify that with an example: text entry devices.
It might seem that a phone keypad is simpler than a computer keyboard. The phone has fewer keys on it so it must be simpler, eh?
But then try typing in your code using a phone keypad. Suddenly, having the right number of controls for the task in hand, one key for each letter, seems a lot simpler than having to multi-key every letter.
But think again.
We don't actually have one key for every character on a computer keyboard. We have a shift key so that one letter key can do for both 'g' and 'G'. A keyboard where these were on separate keys would be harder to use, because the current design exploits the relationship between the characters.
Simplicity turns out to be quite subtle. It means having an appropriate number of controls for the job in hand, not too many and not too few. It means that it has to be a judgment call in each case, but simplicity is still never a pre-judgment that more options means more complex.
~~gravywavy
Further testing has uncovered
)
Further testing has uncovered another issue that might be important.
When no scheduler can be reached, the v4.45 client backs off exponentially at first (as it should), but then goes into a cycle of 1 minute backoffs.
Hopefully, I'm wrong and am overlooking something here. But if my concern is justifued, there exists a danger that after a server outage all the 4.45 clients in the world will try to check in together every minute or so; a kind of self-inflicted denial of service attack.
You can see the log demonstrating this effect here.
I've left the machine running, and will report again if it does eventually go back into the exponential backoff.
The break in service by the LHC scheduler was simulated locally and the real LHC is still up and running. I will, of course, reconnect it well before the LHC wu gets near its deadline and in the meantime no harm is being done to LHC nor to its stranded wu.
~~gravywavy
It's funny that you decided
)
It's funny that you decided to agree with me ~~gravywavy, because after reading up on how LTD and STD work i think we can make your idea work just fine. Now, we have to balance LTD separately on every level as i suggested to keep track of work done on each level and to make the numbers as small as possible. Now i was wrong about the STD. After reading up on how the STD works, i agree on that it would work as you originally suggested. So the code for STD would not have to be changed from what we have today.
Edit
EDF would solve any problems that i originally thought of between the levels.
/Edit
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
RE: It's funny that you
)
we are obviously both quite persuasive,
or maybe it is like a football match where we change ends at half time ;-)
thanks for taking so much care in thinking about my suggestion Ziran. I am not clear, are you one of the project devs? Or developing an alternative client? Or just helping me think through the effects of my suggestion?
~~gravywavy
I am just an ordinary
)
I am just an ordinary participant. So i am only helping you think through the effects of your suggestion and hopefully give some worthwhile input in the process.
I am running on a 600 MHz Celeron, so my biggest contribution to the BOINC community will probably be in the forums.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.