Say you run one task at a time and you want to have another spare task made available to you as soon as you start the first one. Think of it as a KanBan in ERP terms. You call for it and you get it. Great.

But if you don't get it, you call for it again 10 minutes later, then again and again and finally after an hour, let's say, (and 6 'failures') it arrives. Is that 6 failures or not a problem at all because your first job takes 3 hours to run and the new one arrived well before the in-progress one finished?

It's a failure because it doesn't meet your criteria, but if your criteria is decided in order to allow for 20+ failures without facing a real problem then it's a success for your criteria and for your 'production'.

This, I believe, is the crux of your misinterpretation. You make no distinction when the distinction is actually everything.

Hmm. I think that your analogy breaks down. A more accurate analogy might be that the KanBan system tries to “pull” materials from Inventory, but the materials aren’t there. Regardless of the number of attempts made, no materials are available. As a result, the Work Station or Manufacturing Cell runs out of materials and has to stop work. Production ceases. In this scenario, it is not the IT Manager who gets a close look at the parking lot, it is the Materials Manager (assuming that the MRP program correctly generated the correct Purchase Requisition at the correct point in time). Wouldn’t the interruption of production be regarded as a very bad thing? Even if the KanBan system had sufficient materials to produce for a day or two, it wouldn’t help much in the event of a stockout on an item with a (for example) one-week lead time, right?

The IT analogy would be that production must be halted because the database and applications servers are down, and no transactions can be completed. EVERYBODY is upset because Customer Orders cannot be entered, Purchase Orders cannot be generated, MRP cannot be run, Inventory levels cannot be checked, etc., etc. When the servers are down, production often ceases. At the very least, it becomes seriously impacted.

When a Rosetta contributor uses the KanBan-like method of attempting to retrieve Work Units, and no Work Units are forthcoming, isn’t that analogous to the Materials Management situation where the Workstations run out of materials and production ceases?

In my experience, having a VP who wasn't a bit of an idiot is a rarity. Sounds like you have one of the usual ones.

First, though, you'd need to distinguish between the 'crash' over a week ago and the slow-down during all the time since. If you hadn't already assessed the difference between trivial ups and downs and built in some margin for that then you'd deserve that walk to the car. Don't sweat the small stuff and especially don't trouble the big guys with every bump and squeak. They expect you to handle that yourself.

If it's something major that requires more heavyweight intervention you can tweak some stuff (runtimes in our case here to provide more time for the big solution) or the final contingency of having a back-up project altogether. We're lucky that our machinery (Boinc) can run anything else with no changeover time.

The point being, set a safety margin that covers the small stuff and stop worrying if your safety margin is being eaten into - that's precisely what it's for. How you set your safety level depends on your situation. I'm away for half of each week so I keep 2 days usually. 1 day may be better for you if you check things each night.

If your safety margin is close to being exhausted, as long as you're sure solutions are being worked on by TPTB and you've tweaked as much as you can, it's out of our hands. At the end of the day, the loss is theirs. If you're prepared to keep a back-up project you can stay productive and returned when the problem's properly solved (looking better now, and the slow validator issue seems to have gone too).

MY VP of Operations was very sharp, and a very good leader. His job was Production. If we didn’t make our production targets, his butt was on the line, so to speak. If we experienced interruptions due to IT problems, then my butt was right alongside his on the line. I can tell you that I spent more than one night, weekend and holiday in the Data Center in order to ensure that our ERP system was up and available (we ran 24/7).

I believe that I have not been affected by any slowdowns (not that I’ve noticed, anyway). When my buffer emptied out, and no new Work Units were available for a couple of days, my production ceased. I simply reported that fact on a thread that was established by another poster for the same reason. What I thought I was seeing in some of the reply posts was analogous to saying that a Work Station could not possibly be starved for materials because some other workstation was able to work just fine. To me, that was (and is) a nonsensical position). It’s kind of like saying that you couldn’t possibly be stuck in traffic on 8th Street because I am driving along just fine here on Elm Street.

As I understand it, when BOINC and Rosetta install, a buffer of appropriate size is created automatically. The default run time is 3 hours, but can be adjusted up to 24 hours. The downside of having a large buffer is the possibility of missing deadlines. We are advised that increasing buffer sizes is not necessarily a good idea. We are left, then, in the situation of the manufacturing Workstation running a KanBan system. If we try to pull materials (Work Units) that are not available, then production ceases. How do we handle that ourselves? Are we not 100% at the mercy of the server systems that distribute the work to our workstations?

I don’t think it is accurate to compare a complete cessation of production with a safety margin being eaten into. I don’t watch my buffer levels closely. I shouldn’t have to. The way I noticed that my machine ran out of work was when the cooling fans got quiet. Then I saw that it was unable to acquire new Work Units. If the BOINC system had to be closely monitored in order to assure that it was working properly, then it wouldn’t be as valuable to contributors as it clearly is. I, like a lot of contributors, like to “set it and forget it” with BOINC. That philosophy works pretty well most of the time.

The bottom line for me was not that Rosetta’s servers were down. It was that the “Server Status” page indicated that they were up and running, even though there seemed to be some evidence that they really were not. As a long time IT director, I understand that things happen. What concerned me was the appearance that at least some posters were convinced that nothing had happened, and nothing was wrong.

deesy

Say you run one task at a time and you want to have another spare task made available to you as soon as you start the first one. Think of it as a KanBan in ERP terms. You call for it and you get it. Great.

But if you don't get it, you call for it again 10 minutes later, then again and again and finally after an hour, let's say, (and 6 'failures') it arrives. Is that 6 failures or not a problem at all because your first job takes 3 hours to run and the new one arrived well before the in-progress one finished?

It's a failure because it doesn't meet your criteria, but if your criteria is decided in order to allow for 20+ failures without facing a real problem then it's a success for your criteria and for your 'production'.

This, I believe, is the crux of your misinterpretation. You make no distinction when the distinction is actually everything.

Hmm. I think that your analogy breaks down. A more accurate analogy might be that the KanBan system tries to “pull” materials from Inventory, but the materials aren’t there. Regardless of the number of attempts made, no materials are available. As a result, the Work Station or Manufacturing Cell runs out of materials and has to stop work. Production ceases. In this scenario, it is not the IT Manager who gets a close look at the parking lot, it is the Materials Manager (assuming that the MRP program correctly generated the correct Purchase Requisition at the correct point in time). Wouldn’t the interruption of production be regarded as a very bad thing? Even if the KanBan system had sufficient materials to produce for a day or two, it wouldn’t help much in the event of a stockout on an item with a (for example) one-week lead time, right?

The IT analogy would be that production must be halted because the database and applications servers are down, and no transactions can be completed. EVERYBODY is upset because Customer Orders cannot be entered, Purchase Orders cannot be generated, MRP cannot be run, Inventory levels cannot be checked, etc., etc. When the servers are down, production often ceases. At the very least, it becomes seriously impacted.

When a Rosetta contributor uses the KanBan-like method of attempting to retrieve Work Units, and no Work Units are forthcoming, isn’t that analogous to the Materials Management situation where the Workstations run out of materials and production ceases?

In my experience, having a VP who wasn't a bit of an idiot is a rarity. Sounds like you have one of the usual ones.

First, though, you'd need to distinguish between the 'crash' over a week ago and the slow-down during all the time since. If you hadn't already assessed the difference between trivial ups and downs and built in some margin for that then you'd deserve that walk to the car. Don't sweat the small stuff and especially don't trouble the big guys with every bump and squeak. They expect you to handle that yourself.

If it's something major that requires more heavyweight intervention you can tweak some stuff (runtimes in our case here to provide more time for the big solution) or the final contingency of having a back-up project altogether. We're lucky that our machinery (Boinc) can run anything else with no changeover time.

The point being, set a safety margin that covers the small stuff and stop worrying if your safety margin is being eaten into - that's precisely what it's for. How you set your safety level depends on your situation. I'm away for half of each week so I keep 2 days usually. 1 day may be better for you if you check things each night.

If your safety margin is close to being exhausted, as long as you're sure solutions are being worked on by TPTB and you've tweaked as much as you can, it's out of our hands. At the end of the day, the loss is theirs. If you're prepared to keep a back-up project you can stay productive and returned when the problem's properly solved (looking better now, and the slow validator issue seems to have gone too).

MY VP of Operations was very sharp, and a very good leader. His job was Production. If we didn’t make our production targets, his butt was on the line, so to speak. If we experienced interruptions due to IT problems, then my butt was right alongside his on the line. I can tell you that I spent more than one night, weekend and holiday in the Data Center in order to ensure that our ERP system was up and available (we ran 24/7).

I believe that I have not been affected by any slowdowns (not that I’ve noticed, anyway). When my buffer emptied out, and no new Work Units were available for a couple of days, my production ceased. I simply reported that fact on a thread that was established by another poster for the same reason. What I thought I was seeing in some of the reply posts was analogous to saying that a Work Station could not possibly be starved for materials because some other workstation was able to work just fine. To me, that was (and is) a nonsensical position). It’s kind of like saying that you couldn’t possibly be stuck in traffic on 8th Street because I am driving along just fine here on Elm Street.

As I understand it, when BOINC and Rosetta install, a buffer of appropriate size is created automatically. The default run time is 3 hours, but can be adjusted up to 24 hours. The downside of having a large buffer is the possibility of missing deadlines. We are advised that increasing buffer sizes is not necessarily a good idea. We are left, then, in the situation of the manufacturing Workstation running a KanBan system. If we try to pull materials (Work Units) that are not available, then production ceases. How do we handle that ourselves? Are we not 100% at the mercy of the server systems that distribute the work to our workstations?

I don’t think it is accurate to compare a complete cessation of production with a safety margin being eaten into. I don’t watch my buffer levels closely. I shouldn’t have to. The way I noticed that my machine ran out of work was when the cooling fans got quiet. Then I saw that it was unable to acquire new Work Units. If the BOINC system had to be closely monitored in order to assure that it was working properly, then it wouldn’t be as valuable to contributors as it clearly is. I, like a lot of contributors, like to “set it and forget it” with BOINC. That philosophy works pretty well most of the time.

The bottom line for me was not that Rosetta’s servers were down. It was that the “Server Status” page indicated that they were up and running, even though there seemed to be some evidence that they really were not. As a long time IT director, I understand that things happen. What concerned me was the appearance that at least some posters were convinced that nothing had happened, and nothing was wrong.

deesy

That's why I run other projects in case Rosie has a bad day.
I also keep a buffer of 5-7 days of Rosie if I can, then I can keep crunching even if she has a headache. Right now I am working more with the mad physics scientist and waiting for him to get out of the way before I can get back to Rosie and her tasks.

Say you run one task at a time and you want to have another spare task made available to you as soon as you start the first one. Think of it as a KanBan in ERP terms. You call for it and you get it. Great.

But if you don't get it, you call for it again 10 minutes later, then again and again and finally after an hour, let's say, (and 6 'failures') it arrives. Is that 6 failures or not a problem at all because your first job takes 3 hours to run and the new one arrived well before the in-progress one finished?

It's a failure because it doesn't meet your criteria, but if your criteria is decided in order to allow for 20+ failures without facing a real problem then it's a success for your criteria and for your 'production'.

This, I believe, is the crux of your misinterpretation. You make no distinction when the distinction is actually everything.

Hmm. I think that your analogy breaks down. A more accurate analogy might be that the KanBan system tries to “pull” materials from Inventory, but the materials aren’t there. Regardless of the number of attempts made, no materials are available. As a result, the Work Station or Manufacturing Cell runs out of materials and has to stop work. Production ceases.

No it wouldn't. Not at all, in any way, shape or form. It would be a shortage of back-up stock but not of production. The task you're crunching is the only one in 'production'. That's not affected by whether you have 1, 10, a million or zero back-up tasks.

I tried to keep it simple, but that obviously didn't work. Instead of targetting one taskkanban let's say the target is to have 10 tasks available after the one in progress. Trouble is, we can only get 7, and by the time we get #8, 9 and 10 some more tasks have been completed and we still only hold 7 at one time. Or maybe 6 or 5, or 8. Problem? No. Only when you have zero AND one is called into production is it a problem.

When you're dealing in achieving safety margins they're designed to be eaten into at times. If you can always meet your safety margins by the full amount it's a sign they're too high, your stockholding is too high and your stock-turn too low. That you don't think this is too relevant completely explains why you're worried and others like me weren't.

In my experience, having a VP who wasn't a bit of an idiot is a rarity. Sounds like you have one of the usual ones...

MY VP of Operations was very sharp, and a very good leader. His job was Production...

Well, there you are then! (That may be a bit too subtle). Let's just say production people aren't always the best at the logistics of keeping them supplied. They may be, but more often they aren't. IT people more certainly aren't. That tends to be why it's all feast or famine from their point of view as they miss the subtleties along the way. That's what tends to lead to talk about 'walking to the car park' IME.

I spent 20 years pretty successfully in Production, Planning, Materials and Logistics in a variety of environments and have seen most variations of everything - more than I care to. This is a pretty simple example here, yet it's apparent your misunderstanding is pretty fundamental all the same.

That's not intended as a criticism or insult, just an appreciation that you're standpoint is different. That requires a different strategy I'd say. If you want to 'set it and forget it' you're better off having a back-up project you can switch to seamlessly. No project has no downtime - most have far more in fact - but the chances of 2 being down at the same time is less (but not zero). Find a reliable one you like the look of and that should ensure your 10th back-up task will be maintained all year round.

---

It seems to me you guys are making a simple process very complicated. We sign on as users to a project, and when the project has work for us we run it. This project is amazingly reliable in providing work for all the active users. Every once in a while, the project won't have work for all of us, for whatever reason.

We aren't entitled to any certain amount of work, and we aren't entitled to explanations from the project folks. After all, we are supporting and helping the project, not adding to their workload.

Comparisons to corporate culture, or commercial web sites, simply don't apply. The project isn't a business, and we aren't paying customers.

I guess I still don’t take your point. Perhaps you have simplified it too much. ;-)

You say: “The task you're crunching is the only one in 'production'. That's not affected by whether you have 1, 10, a million or zero back-up tasks.” (Emphasis added)

You also say: “… let's say the target is to have 10 tasks available after the one in progress.” (Emphasis added)

These assertions imply that I WAS crunching a task during the extended period when no Work Units were being received. That is not a valid assumption. When my Windows Task Manager indicates that the percentage of CPU usage consumed by MiniRosetta is zero, then isn't it clear that NO crunching is being accomplished on my machine? Zero? Zip? None? Nada? When the buffer empties out, the crunching stops.

From the perspective of my particular Work Center (computer), if this happens, then production has ceased on my machine. I am no longer crunching numbers for the Rosetta@Home Project. Since it was obvious that some number of users had also experienced an interruption in the flow of Work Units, then didn’t their production also cease? Perhaps the Rosetta@Home Project continued to function, but it certainly was not at the same capacity, because that capacity must be measured by the number and type of CPUs making up the grid, independent of the number of Work Units available to some contributors in the form of “back-up stock.”

I believe that I made my situation clear. My computer received NO Work Units for a sufficient amount of time that it was no longer able to crunch numbers for the Rosetta@Home Project. The buffers had been exhausted, and no new work was being received.

Now, if one were to assume that the Project is like a very, very large factory, and that all of the manufacturing cells or work centers in that factory are able to process whatever inventory is available into whatever finished good is desired, then perhaps I can see your point. In the real world of manufacturing, however, I have never seen a situation like that.

Typically, a Work Center or Manufacturing Cell can only perform a certain stage of the manufacturing process, and would not be able to process materials or items that are not appropriate to the machines and worker skills. They also are usually limited in the scope of the items they can process (limited number of sizes, designs, or materials).

If I am manufacturing a certain type of (for example) fasteners, and some of these fasteners are (for example) made of Titanium, and some of these Titanium fasteners (for example) require a Teflon sleeve that is set up as a KanBan item, then what happens to the Work Center’s production if no Teflon sleeves are available in Inventory? What if this happened in spite of the number of KanBan baskets of sleeves normally kept in stock? Wouldn’t that particular Manufacturing Cell or Work Center have to shut down? What would that mean to the workers who staff that cell or center? What would be the impact on the Production Manager? How about the customers who might be waiting for the product? What is the overall effect on the company as a whole? Hasn’t the cessation of production in one or more Work Centers or Manufacturing Cells adversely affected overall production levels and, thereby, financial performance?

Wouldn’t it be true that, regardless of the number of backlog Work Units maintained in contributors’ buffers, if the number of running CPUs in the grid were to suddenly decrease, would the project not be adversely affected?

I think we’re going to have to agree to disagree on this one, because I am still not clear just exactly what point you’re trying to make. I appreciate your efforts to enlighten me, but our experiential backgrounds are apparently too different, and we are talking past each other.

deesy

It seems to me you guys are making a simple process very complicated.

Perhaps it is more complicated than you might realize.

We sign on as users to a project, and when the project has work for us we run it. This project is amazingly reliable in providing work for all the active users. Every once in a while, the project won't have work for all of us, for whatever reason.

This appears to be true.

We aren't entitled to any certain amount of work, and we aren't entitled to explanations from the project folks. After all, we are supporting and helping the project, not adding to their workload.

Sorry! I can't agree with you on this. We are entitled to a sufficient amount of work to keep our machines busy so long as other contributors are receiving sufficient work to keep their machines busy. If nobody has work, then that is a different matter. Your assertion is analogous to saying that we are not entitled to know how a charity spends our money after we have donated it. Where I come from, such a position would probably be considered naive.

Comparisons to corporate culture, or commercial web sites, simply don't apply. The project isn't a business, and we aren't paying customers.

I can't agree with you here, either. You can be sure that the Project management and staff has a culture, and it might not be all that different from a corporate culture. (Is Baker Labs a corporation, BTW? I'll bet it is.) A project such as Rosetta@Home has no less responsibility to keep their Web sites current and accurate as any other organization, and perhaps even more of a responsibility in light of the fact that computational resources are being donated to them free-of-charge. It would be arrogant to conclude that the Project need not treat its contributors with a minimal level of respect and consideration because "we aren't paying customers." We certainly are paying. We are contributing our capital resources, the energy required to operate those resources, and the time and effort required to keep those resources in operation.

Altruism is a wonderful thing, but does anybody, anybody at all, believe that the management and staff at Baker Labs are not being compensated for their efforts. They certainly must be altruistic, but you can bet that they are also benefiting from the receipt of salaries and grants, the respect of their peers, the opportunity to publish papers, gain promotions within their organizations, and perhaps even future employment opportunities with pharmaceutical companies.

deesy

deesy, read this: https://boinc.bakerlab.org/rosetta/info.php
Rosetta never promised to keep your computers busy. And they never will.
Any further questions?

---

It seems to me you guys are making a simple process very complicated.

Perhaps it is more complicated than you might realize.

We sign on as users to a project, and when the project has work for us we run it. This project is amazingly reliable in providing work for all the active users. Every once in a while, the project won't have work for all of us, for whatever reason.

This appears to be true.

We aren't entitled to any certain amount of work, and we aren't entitled to explanations from the project folks. After all, we are supporting and helping the project, not adding to their workload.

Sorry! I can't agree with you on this. We are entitled to a sufficient amount of work to keep our machines busy so long as other contributors are receiving sufficient work to keep their machines busy. If nobody has work, then that is a different matter. Your assertion is analogous to saying that we are not entitled to know how a charity spends our money after we have donated it. Where I come from, such a position would probably be considered naive.
deesy

And 'entitled' is what has gotten this Country into alot of problems, "undocumented aliens" think they are 'entitled' to the American Dream but then don't have to work for it. They get it thru 'entitlement' programs such as Welfare, Food Stamps, WIC, etc ,etc, etc! Is that a good thing, not to my way of thinking! Thinking anyone is 'entitled' to workunits is just not correct either, each project TRIES to provide work in a timely manner just as we users TRY to provide our pc's for them to give those workunits too. IF we users are 'entitled' to workunits wouldn't it also be true that each project is 'entitled' to a stable number of users and by extension their pc's? Meaning project A sends me work and I CANNOT move that pc to any other project and if it crashes and I am offline, or if my internet connection goes down, I then OWE the project something because they are 'entitled' to the use of my pc's. I do not think you meant to say 'entitled' in that context and may in fact wish to rethink that whole idea, IMO. 'Entitled' would seem to imply a contract between the project and yourself, meaning they supply you work and you supply them resources, that isn't the way Boinc works. A project is no more 'entitled' to the use of my pc's than I am 'entitled' to get work from them. Now IF you can find a project that will do that, please let us know, alot of us would like to make money for crunching!

Oh and there are PLENTY of charities that refuse to open their books and lose donations as a result! Several years ago the United Way in Alexandria Va got busted for misappropriating money and donations went thru the floor. They 'opened' their books and paid dearly for it. If a project does not have any workunits just move on to another one until they do, most of us have experienced long drawn out outages at most projects over the years, Rosetta is one project that has been up far more than alot of other big named projects! Seti, the place it all began, is now down 2 to days PER WEEK! They also DO NOT believe in keeping its users informed of the progress of outages, when they are back up they are back up, not before and no info will be sent out! Alot of us don't like that practice so we now crunch elsewhere, it is our choice, our pc's, our electricity, our time and our maintenance of those resources.

Now that we have established that everyone knows what they are talking about and confirmed each is talking about their own thing, and therefore little of what anyone else says about it is relevant, can we take any remaining portion of this debate outside to another internet venue?

Work is now available and flowing smoothly. Has been for a day or so. So this thread should now be obsolete, unless there are still folks confused about other reason they might not be getting work.

---

Rosetta Moderator: Mod.Sense

deesy, read this: https://boinc.bakerlab.org/rosetta/info.php
Rosetta never promised to keep your computers busy. And they never will.
Any further questions?

Thanks, Jochen. It was interesting to re-read the Rosetta license agreement.

It is difficult to see, however, how it is, in any way, germane to the discussions taking place on this thread, as they do not appear to be license related. I did find it interesting that the Project can (and apparently does) "decide what type of work to assign to [our] computer[s]." So, perhaps the assumption that all contributors receive the exact same types of Work Units is not correct.

deesy

And 'entitled' is what has gotten this Country into alot of problems, "undocumented aliens" think they are 'entitled' to the American Dream but then don't have to work for it. They get it thru 'entitlement' programs such as Welfare, Food Stamps, WIC, etc ,etc, etc! Is that a good thing, not to my way of thinking! Thinking anyone is 'entitled' to workunits is just not correct either, each project TRIES to provide work in a timely manner just as we users TRY to provide our pc's for them to give those workunits too. IF we users are 'entitled' to workunits wouldn't it also be true that each project is 'entitled' to a stable number of users and by extension their pc's? Meaning project A sends me work and I CANNOT move that pc to any other project and if it crashes and I am offline, or if my internet connection goes down, I then OWE the project something because they are 'entitled' to the use of my pc's. I do not think you meant to say 'entitled' in that context and may in fact wish to rethink that whole idea, IMO. 'Entitled' would seem to imply a contract between the project and yourself, meaning they supply you work and you supply them resources, that isn't the way Boinc works. A project is no more 'entitled' to the use of my pc's than I am 'entitled' to get work from them. Now IF you can find a project that will do that, please let us know, alot of us would like to make money for crunching!

Oh and there are PLENTY of charities that refuse to open their books and lose donations as a result! Several years ago the United Way in Alexandria Va got busted for misappropriating money and donations went thru the floor. They 'opened' their books and paid dearly for it. If a project does not have any workunits just move on to another one until they do, most of us have experienced long drawn out outages at most projects over the years, Rosetta is one project that has been up far more than alot of other big named projects! Seti, the place it all began, is now down 2 to days PER WEEK! They also DO NOT believe in keeping its users informed of the progress of outages, when they are back up they are back up, not before and no info will be sent out! Alot of us don't like that practice so we now crunch elsewhere, it is our choice, our pc's, our electricity, our time and our maintenance of those resources.

I think you are twisting the word "entitle" to mean something that is not at all applicable to the Rosetta@Home Project. This off-the-wall rant is an inappropriate introduction of "Tea party" politics into a technical and philanthropic forum. Perhaps it is time to lock or terminate this thread (hint, hint).

deesy

Thanks, Jochen. It was interesting to re-read the Rosetta license agreement.

I didn't link to the license agreement, but to the Rules and Policies.
Scroll down to the bottom of the page and read the disclaimer. At least there is one in the German translation of that page. In bold letters...

---

Thanks, Jochen. It was interesting to re-read the Rosetta license agreement.

I didn't link to the license agreement, but to the Rules and Policies.
Scroll down to the bottom of the page and read the disclaimer. At least there is one in the German translation of that page. In bold letters...

I followed the link. It led me to the license agreement. The disclaimer in bold letters just said that Rosetta was not responsible for any damage to the licensee's computer. I am not aware that anybody has claimed that crunching for the Rosetta@Home Project has damaged their computer, and it is difficult to imagine how it could happen on any modern microprocessor with heat-sensitive throttling capability, like virtually all of the newer Intel processors.

deesy.

Your deliberate way of selective reading leaves me with only one conclusion: You're a troll. I won't feed you anymore.

---

Your deliberate way of selective reading leaves me with only one conclusion: You're a troll. I won't feed you anymore.

Your accusation is crude, rude and uncalled for. Name calling is just such a mature activity, don't you think?

What do you want me to do? Should I copy and paste the license agreement that I see when I click on your link? Without knowing what I see (and it is NOT in German, by the way) you are out of line in calling me a troll and implying that I am a liar.

Mod.Sense, this is getting a little out of control, isn't it?

deesy

Work is now available and flowing smoothly. Has been for a day or so...

Hey, just a quick question before you blast this thread to the oblivion it so justly deserves. Before the slowdown occurred, the Total Queued Jobs" was usually up around 4 million or so, but now I see it is hovering around a million and still falling slightly. This doesn't indicate any continuing problems, does it? Or perhaps one in the near future?

Deesy, I understand what you are saying (I think). I hope your frustration doesn't stop you from continuing to contribute to this or other projects. My reason for contributing to this particular project is identical to yours.

I guess I still don’t take your point. Perhaps you have simplified it too much. ;-)

Quite possibly! Here are the parts where I agree with you:

- "In the real world of manufacturing, however, I have never seen a situation like that."
- "I believe that I made my situation clear."
- "...I am still not clear just exactly what point you’re trying to make."

Again, not a criticism. You can only know what you know and experience what you experience and it's pretty clear how limited that is. Not that it's hard to understand - I'm sure you'd pick it up straight away if the distinction of the differences was pointed out to you, but until then it's not a good idea to apply a limited understanding to scenarios where it doesn't apply. The saying "when the only tool you have is a hammer, every problem looks like a nail" applies here.

Parts that I disagree with or are misunderstood or flat wrong:

These assertions imply that I WAS crunching a task during the extended period when no Work Units were being received. That is not a valid assumption.

Just as well that wasn't stated or implied then. You seem to have a big problem with time. The above applied after you'd been re-supplied with tasks (though insufficient to fill your buffer). At the time you were totally out it was already too late to say something. Your 'set and forget' approach (perfectly legitimate) completely contradicts your need to be in work at all times. This is not the project's fault. The fault is with the parameters you set to meet your requirements.

No problem. Lesson learned. Now it's up to you to decide how to use the options Boinc (and Rosetta) provides to ensure your own req'ts are best met. Have fun!

Now, if one were to assume that the Project is like a very, very large factory, and that all of the manufacturing cells or work centers in that factory are able to process whatever inventory is available into whatever finished good is desired, then perhaps I can see your point.

The project indeed isn't like that (eg: Rosetta can't run Einstein jobs) but Boinc can. As such, the parallel you attempt to draw has no validity whatsoever so I won't dwell further on your convoluted (and inapplicable) what-if scenario - which will at least please Michael G! (In any case, the answer to your questions would be "no" or "none" or "not necessarily", but certainly not "yes" except in the most contrived of circumstances - which kind of explains why your what-ifs needed so many levels).

I think we’re going to have to agree to disagree on this one, because I am still not clear just exactly what point you’re trying to make. I appreciate your efforts to enlighten me, but our experiential backgrounds are apparently too different, and we are talking past each other.

I may've been talking past you, but you weren't talking past me. That's why I'm clear about what you're saying and am sure it's not correct, while you're not clear what I'm saying at all.

Anyway, we've talked through the whole issue pretty well in the last couple of days, even if we've made the Mod's trigger-finger get itchy along the way (sorry mod.sense!). I think if you cast your eye again over your various settings you'll be more comfortable they reflect your intentions and req'ts more fully in the light of what's been said, and you won't get anxious when things don't go smoothly in future. Somehow I'm going to guess you aren't going to stop crunching even if the site goes down completely for a couple of days. Well, if they don't, you'll know who to blame anyway! ;)

Before the slowdown occurred, the Total Queued Jobs" was usually up around 4 million or so, but now I see it is hovering around a million and still falling slightly. This doesn't indicate any continuing problems, does it? Or perhaps one in the near future?

It may or may not, but we don't have the visibility to know either way, nor is it our business until it actually hits zero (it's another safety stock at a different level), but it's a fair question and it crossed my mind recently too.

On the plus side, when CASP started, they dropped a quick couple of million in there in short order so if it did became an issue I'm sure it could be resolved PDQ.

---

Hey, just a quick question before you blast this thread to the oblivion it so justly deserves. Before the slowdown occurred, the Total Queued Jobs" was usually up around 4 million or so, but now I see it is hovering around a million and still falling slightly. This doesn't indicate any continuing problems, does it? Or perhaps one in the near future?

I think once or twice we have briefly run out of work but they seem to be able to restock with another few million jobs within a couple of hours. Normally they seem to take action before it drops below 50,000.

---

Quite possibly! Here are the parts where I agree with you:

- "In the real world of manufacturing, however, I have never seen a situation like that."
- "I believe that I made my situation clear."
- "...I am still not clear just exactly what point you’re trying to make."

Again, not a criticism. You can only know what you know and experience what you experience and it's pretty clear how limited that is. Not that it's hard to understand - I'm sure you'd pick it up straight away if the distinction of the differences was pointed out to you, but until then it's not a good idea to apply a limited understanding to scenarios where it doesn't apply. The saying "when the only tool you have is a hammer, every problem looks like a nail" applies here.

My! How astute of you! I believe that it was you who initially attempted to apply the KanBan analogy to the Rosetta project. Again, it appears that, because you are unable to make your point, you are resorting to an ad hominem attack. Sad!

Insofar as “limited” is concerned, I’ll match my 40+ years of experience in manufacturing, at all levels, in various capacities, in different industries, both discrete and continuous, against your 20+ years any day. But, keep in mind that I’m not the one who started this really distasteful process of bragging about my own experience while criticizing that of my adversary. What was it that was said about “dueling with an unarmed man”?

Parts that I disagree with or are misunderstood or flat wrong:

These assertions imply that I WAS crunching a task during the extended period when no Work Units were being received. That is not a valid assumption.

Just as well that wasn't stated or implied then. You seem to have a big problem with time. The above applied after you'd been re-supplied with tasks (though insufficient to fill your buffer). At the time you were totally out it was already too late to say something. Your 'set and forget' approach (perfectly legitimate) completely contradicts your need to be in work at all times. This is not the project's fault. The fault is with the parameters you set to meet your requirements.

Perhaps you have a reading problem, also. Where, in any post whatsoever, did I express any sort of problem or concern regarding the filling of my buffer? It appears that you have made an unsupported assumption. This might be understandable if English is a second language for you. Of course, I have no way of knowing if this is the case.

All of my remarks applied only to that period of time during which my machine had completely run out of work, and the Server Status page was reporting that the servers were up and running. Once Work Units began to be resupplied to my machine, my buffer filled immediately, and I never said otherwise.

No problem. Lesson learned. Now it's up to you to decide how to use the options Boinc (and Rosetta) provides to ensure your own req'ts are best met. Have fun!

I followed your suggestions regarding CPU run times and buffer sizes, and you attacked me anyway. I think I’ll return to the BOINC defaults. They wouldn’t be defaults if they were sub-optimum, would they?

Now, if one were to assume that the Project is like a very, very large factory, and that all of the manufacturing cells or work centers in that factory are able to process whatever inventory is available into whatever finished good is desired, then perhaps I can see your point.

The project indeed isn't like that (eg: Rosetta can't run Einstein jobs) but Boinc can. As such, the parallel you attempt to draw has no validity whatsoever so I won't dwell further on your convoluted (and inapplicable) what-if scenario - which will at least please Michael G! (In any case, the answer to your questions would be "no" or "none" or "not necessarily", but certainly not "yes" except in the most contrived of circumstances - which kind of explains why your what-ifs needed so many levels).

While it might be true that Rosetta can’t run Einstein jobs, it apparently is true that Rosetta runs a variety of different types of tasks, and the Rosetta license indicates that the Project gathers information about its contributors’ computers so that it can assign different types of work to different users. I do not recall expressing concern about BOINC. My concerns were in regard to Rosetta@Home.

Contrived of circumstances? I thought you had 20 years of manufacturing experience! Do you really expect us to believe that you have never once, in all that 20 years, seen a materials stockout that impacted production? That assertion would be a bit difficult for anybody to swallow.

I think we’re going to have to agree to disagree on this one, because I am still not clear just exactly what point you’re trying to make. I appreciate your efforts to enlighten me, but our experiential backgrounds are apparently too different, and we are talking past each other.

I may've been talking past you, but you weren't talking past me. That's why I'm clear about what you're saying and am sure it's not correct, while you're not clear what I'm saying at all.

Even the most irrational among us are usually certain that they are perfectly lucid and correct.

Anyway, we've talked through the whole issue pretty well in the last couple of days, even if we've made the Mod's trigger-finger get itchy along the way (sorry mod.sense!). I think if you cast your eye again over your various settings you'll be more comfortable they reflect your intentions and req'ts more fully in the light of what's been said, and you won't get anxious when things don't go smoothly in future. Somehow I'm going to guess you aren't going to stop crunching even if the site goes down completely for a couple of days. Well, if they don't, you'll know who to blame anyway! ;)

Well, that was about as clear as mud! I don’t know if you are deliberately trolling, but I know that you do not appear to have provided any clarity to the matter that led to the establishment of this thread in the first place.

While it is true that it might be somewhat valid to compare the relationship between crunchers and servers to a KanBan (pull) manufacturing system because individual contributors’ computers must request Work Units in order to receive them, it is also the case that a materials stockout and the inability of Rosetta servers to provide work to contributors are very similar issues. In either case, once the buffer (safety stock) is empty/used up, the Work Center (crunching computer) can do nothing to acquire more work until the source of that work (Rosetta servers) can provide it.

deesy

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.

---