Deesy: I tried to end previously on such a positive note, but it appears little of my message got through. The time comes when I have to wonder whether the problem is with my explanation or your understanding. Looking at your responses from everyone here and the usual feedback I get, the balance of likelihood is very one-sided.

I'd taken it, when you said you worked in IT for 30+ years and were a long time IT Director, that's what you meant, so when you said there were so many (simple) things you'd never come across, it made some sense. But it seems you now have 40+ years in manufacturing too. Which is it? Getting a bit whiffy.

I think I’ll return to the BOINC defaults. They wouldn’t be defaults if they were sub-optimum, would they?

They would be lowest common denominator settings available for all projects, so of course they'd be sub-optimum. But if you think it'll solve your problems, don't let me stop you.

Is there any part of this you're actually getting, because you're doing a great job of convincing me otherwise? I'm already certain you appreciate little of logistics. Now I'm doubting if you work in IT either. Sad.

As usual, your interpretation is too narrow. I have actually been working in a manufacturing environment for more than 50 years, but I didn't count the portion of my manufacturing experience that took place before my military service. I didn't say I worked in IT for 30+ years, I said I worked with systems for 30+ years, which is true. These systems included the systems I worked with when I studied for my degree in Computer Sciences from a major American university, and the systems design and development I worked on for one of the largest computer manufacturers in the world. Oh, that would also be manufacturing, by the way. We manufactured computer hardware and software.

After that, I held a number of positions in manufacturing companies that produced computer-based products. At two of my former positions, we designed and built our own microprocessor-based computers and communications systems. As most people are aware, computers are of little use without the appropriate software or firmware that makes them perform the tasks expected of them, so systems skills are always required to succeed in such an undertaking.

BTW, if you consider cheap shots to be "such a positive note," I wonder what you say when you are being critical and insulting.

My machine (admittedly older and less powerful than the new ones) had been earning about 800 credits/day until I changed my settings to those you had recommended. Now it is earning about 750-760, so it appears that the defaults might not actually be sub-optimum. Not that I care especially about the total number of credits, except that it is apparently a measure of the level of contribution made by a cruncher.

By the way, you still have not responded to my challenge to show me where I had ever complained about the number of tasks waiting in my buffer, which you appeared to have addressed to the exclusion of everything else in your previous posts.

Well?

deesy

My machine (admittedly older and less powerful than the new ones) had been earning about 800 credits/day until I changed my settings to those you had recommended. Now it is earning about 750-760, so it appears that the defaults might not actually be sub-optimum. Not that I care especially about the total number of credits, except that it is apparently a measure of the level of contribution made by a cruncher.


deesy

AFAIK, settings don't affect the work done. Although, when having a shorter run time, you are less affected credit-wise (and like you said amount-of-work-done-wise) when one of your WUs fail for any given reason. (Compare a WU failing @ 19hrs of processing to a WU failing @ 2hrs of processing... Who lost the most?)

Are you seeing these changes in RAC on a 24/7 running machine? If not, then a few hours more left on/off can make such differences in RAC. ((Sometimes when you restart your PC, the WU starts a bit behind than were it left off before shutting down)(this doens't happen on 24/7 running machines)) If yes, then it's probably what I mentioned first.

Bet you haven't seen double parentheses on the work before :-)

---

My machine (admittedly older and less powerful than the new ones) had been earning about 800 credits/day until I changed my settings to those you had recommended. Now it is earning about 750-760, so it appears that the defaults might not actually be sub-optimum. Not that I care especially about the total number of credits, except that it is apparently a measure of the level of contribution made by a cruncher.


deesy

AFAIK, settings don't affect the work done. Although, when having a shorter run time, you are less affected credit-wise (and like you said amount-of-work-done-wise) when one of your WUs fail for any given reason. (Compare a WU failing @ 19hrs of processing to a WU failing @ 2hrs of processing... Who lost the most?)

Are you seeing these changes in RAC on a 24/7 running machine? If not, then a few hours more left on/off can make such differences in RAC. ((Sometimes when you restart your PC, the WU starts a bit behind than were it left off before shutting down)(this doens't happen on 24/7 running machines)) If yes, then it's probably what I mentioned first.

Bet you haven't seen double parentheses on the work before :-)

My machine runs 24/7. At one time (a couple of months ago), I changed my run times to 24 hours on both CPUs, and it seemed to me that the tasks would crash more often, and I would lose much more progress on the restarts. That's why I accepted the defaults when I reinstalled BOINC after upgrading to Windows 7. I did, however, change the run time from the default 3 hours to 4 hours, and my RAC climbed to about 800, and it hovered there until I changed the run times to 12 hours.

There appears to be some correlation between credit awarded and CPU run times (at least on my machine). I have not seen a complete task crash since the middle of June, so that is an improvement. I don't know if the stability improvement was because of my upgrade to Windows 7, or because the Work Units were different. I do have a record of seven Work Unit tasks that crashed on my machine between May 5, 2010 and June 13, 2010, but nobody seemed interested, so I just killed the task and accepted the fact that I had lost progress and credit. I did post a couple of WU Names on a different Rosetta forum, though.

deesy

deesy: I'd love to chat more, but seeing as you're putting on 10 years to your age and experience each time you post I'm worried for your (and everyone's) health. There was some good advice from others earlier in the thread. I will be taking it. Adieu, with all best wishes for your crunching.

---

deesy: I'd love to chat more, but seeing as you're putting on 10 years to your age and experience each time you post I'm worried for your (and everyone's) health. There was some good advice from others earlier in the thread. I will be taking it. Adieu, with all best wishes for your crunching.

Why am I not surprised when somebody who is unable to formulate a cogent response runs away, taking another cheap shot over his shoulder as he departs?

deesy

Cogent? That was that cop show in the 70's with Telly Savalas, right?

Cogent? That was that cop show in the 70's with Telly Savalas, right?

Be careful! You're dating yourself. Soon, somebody will accuse you of changing your age and experience. :)

deesy

My machine (admittedly older and less powerful than the new ones) had been earning about 800 credits/day until I changed my settings to those you had recommended. Now it is earning about 750-760, so it appears that the defaults might not actually be sub-optimum. Not that I care especially about the total number of credits, except that it is apparently a measure of the level of contribution made by a cruncher.


deesy

AFAIK, settings don't affect the work done. Although, when having a shorter run time, you are less affected credit-wise (and like you said amount-of-work-done-wise) when one of your WUs fail for any given reason. (Compare a WU failing @ 19hrs of processing to a WU failing @ 2hrs of processing... Who lost the most?)

Are you seeing these changes in RAC on a 24/7 running machine? If not, then a few hours more left on/off can make such differences in RAC. ((Sometimes when you restart your PC, the WU starts a bit behind than were it left off before shutting down)(this doens't happen on 24/7 running machines)) If yes, then it's probably what I mentioned first.

Bet you haven't seen double parentheses on the work before :-)

After I changed my settings to 12 hours as a result of a suggestion on this forum, my RAC dropped to about 750 (746 to be exact). When I changed it back to 4 hours, it rose to about 800, then leveled off. I have experienced no interruptions or restarts during this period (that I am aware of). In spite of my vaaast manufacturing and computer systems experience, I can't explain the increase. :-) One thing seems certain though: There is a correlation between CPU time and credit awards.

I have just restarted another machine, so I will probably get a kick in my credits for a while, but I think my previous observations have been confirmed.

deesy

After I changed my settings to 12 hours as a result of a suggestion on this forum, my RAC dropped to about 750 (746 to be exact). When I changed it back to 4 hours, it rose to about 800, then leveled off. I have experienced no interruptions or restarts during this period (that I am aware of). In spite of my vaaast manufacturing and computer systems experience, I can't explain the increase. :-) One thing seems certain though: There is a correlation between CPU time and credit awards.

Much as I promised myself otherwise, it's hard to avoid commenting on this.

The credit system is described here. Each WU type has its credit per decoy calculated separately from different WU types and as you can see it's a moving average within a task type, without considering whether you're running the same range of tasks as you were the previous day.

Not sure if it's still the case but RAC calculation was described in this old thread here and includes a decay factor, so it's not just the credits that you add but the ones that age that affect the change in RAC. Credits could theoretically be going up but RAC decline and vice versa depending on what's aging out of the calculation.

The only detailed calculation I've ever seen of a change in credits for specific jobs as runtime changes seemed to indicate that the longer the runtime the higher the RAC, but seeing as there were unknowns in that case too I didn't consider it definitive. But that was never the point of the change I suggested anyway nor your req't at the time.

Suffice to say, what appears to you as certainty is nothing of the sort. Still, even if it was simple I'd expect you to find it inexplicable anyway.

---