> This is just another one of those schemes, like the guy weaving in and out
> during rush hour, he saves 15 seconds on his trip at the expense of everyone
> else on the highway...

It's not even much of a scheme... It's more a system of false economy.

Whether you store the completed WUs in your cache, or they sit on Berkeleys servers, you are not effecting the speed at which your credits are granted.

In fact, you are delaying how quick you are given credits. If you have a few WUs in your cache that already have the quorom returned except yourself, if you had returned it in a timely manner, you would have already received credit for it! Instead, it's sitting in your cache doing nothing for anybody.

So this "scheme" may have the percieved effect of (more or less) instant gratification, in no way can it be said that it will "get your credits much faster...". It's merely a factor of when you decide you want to look at your credits. Do you want to see them as soon as they are granted, or do you want to hold off turning them in so you can bask in the glory of witnessing a larger incrementation of credit.

Think of it like your bank. Every few weeks you deposit your check from work. At the end of the year you end up with X amount of dollars you've deposited. One year you decide to "make your money much faster". So you hang on to all your checks for the year, then make one large deposit at years end. By any stretch of logic could this one large deposit be considered to have been made "faster" than the smaller deposits made throughout the course of the year? No, didn't think so.

The speed is the same, you are only filtering your perception of how quick you see credits by delaying the return of a large amount of WUs...

> > This is just another one of those schemes, like the guy weaving in and
> out
> > during rush hour, he saves 15 seconds on his trip at the expense of
> everyone
> > else on the highway...
>
> It's not even much of a scheme... It's more a system of false economy.
>
> Whether you store the completed WUs in your cache, or they sit on Berkeleys
> servers, you are not effecting the speed at which your credits are granted.
>
> In fact, you are delaying how quick you are given credits. If you have a few
> WUs in your cache that already have the quorom returned except yourself, if
> you had returned it in a timely manner, you would have already received credit
> for it! Instead, it's sitting in your cache doing nothing for anybody.
>
> So this "scheme" may have the percieved effect of (more or less) instant
> gratification, in no way can it be said that it will "get your credits much
> faster...". It's merely a factor of when you decide you want to look at your
> credits. Do you want to see them as soon as they are granted, or do you want
> to hold off turning them in so you can bask in the glory of witnessing a
> larger incrementation of credit.
>
> Think of it like your bank. Every few weeks you deposit your check from work.
> At the end of the year you end up with X amount of dollars you've deposited.
> One year you decide to "make your money much faster". So you hang on to all
> your checks for the year, then make one large deposit at years end. By any
> stretch of logic could this one large deposit be considered to have been made
> "faster" than the smaller deposits made throughout the course of the year? No,
> didn't think so.
>
> The speed is the same, you are only filtering your perception of how quick you
> see credits by delaying the return of a large amount of WUs...
>
> <a> href="http://www.boinc.dk/index.php?page=user_statistics&project=sah&userid=91863">
>

Let's put some numbers to it, Heffed. You've got some good points here. Whether it helps depends upon how quickly the other two results are returned for any given WU, of course.

Let's take two scenarios:

1. Preferences set to connect to network every 2 days. Then the average age of WU's being processed will be 3 days, and the average delay in reporting results will be 1 day.

2. Triple the setting: preferences set to connect to network every 6 days. Then the average age of WU's being processed will be 9 days, and the average delay in reporting results will be 3 days.

So, assuming no forced updates (which is a weak assumption since this is likely to be used by people who are anxious to get their credits in a hurray), the average age of the WU's will be increased by almost half of the allowed reporting period with a cost of 2 additional day's delay in reporting.

Now, since many of the comparatively young results in scenario 1 will probably be delayed by at least two days longer than those in scenario 2, due to delays in reporting by the other participants working on them, the net additional delay in scenario 2 is likely to be offset by that effect.

Of course there are a lot of assumptions here, but two conclusions seem pretty evident: 1) left to run on its own, the system probably won't result in a net delay and in my opinion seems likely to result in somewhat speedier credits. 2) with forced updates the credits would certainly be granted faster.

***

BTW, thanks to you, Paul, and several others, for discussing this objectively and not "shooting the messenger" again. I didn't set up the BOINC or SETI protocols; I'm just describing an option that's there in the system they gave us. It's an objective option that's there. Period. Personally, I'm not using it. But there has been so much complaining about slow credits and this seemed so obvious, that I thought that by pointing it out perhaps it would placate some of the more impatient users and give them something to do about it - a measure of control - that could reduce their frustration (and noise) somewhat. And as I also pointed out in my original post, as scores mount over time these little timing variations will diminish to the "noise" level, regardless of how somebody earns and reports his/her credits.

So, for me, it's been mostly just an analytical exercise. As it has turned out, it's sure been fun to see the amazing range of reactions!

And that's probably my swan song on this topic.


--Bill Z.

Bill,

Shouting rarely gets you anywhere.

And opinions are that, and that only. Just an opinion. It may be an informed one, it may not be informed at all. I also know that the older I get, the less I seem to know ...

I think it was an interesting discussion, and agree that civility is better than the alternatives. We do have problems in this new and exciting system. And, we should not blind ourselves to the flaws, neither should we be shooting messangers.

I tend to do more updates than I probably should, but in part I am also trying to observe the parts of the system I can lay my hands on so I can talk to the observations I have made.

One of the features that I am most excited about is the multi-project aspect. Heffed made the point in LHC@Home that he is doing cp.net and is never out of work. I have all 5 of the project locked and loaded and as work is available I have been enjoying seeing the system function and return science and in the nonce it is also exercising the system so that BOINC can grow and improve.

I think that for those that are looking for "faster" gratification that projects like Predictor@Home may be more to their liking with faster work units. This is not an option for everyone as Predictor@Home, LHC@Home, and (i believe) Pirates/Einstein@Home are all restricted access still... If Predictor gets their new hardware up we may see them take on more participants, and LHC@Home is talking about opening up again by the end of the month (hope, hope, hope ...) so taking a little pressure off of SETI@Home.

I also saw a rumor (I don't remember where) that Astropulse may be back in development which is also good news...

Last point and we can all let it die ... I think you got one point about the "feeling of being in control"... There is a perception here that the UCB people are not responsive to the participant community. And this may be leading to more angst than is warrented. I am not sure what is needed to remove this perception, or even if it is possible to remove it ... Oh, well, back to football ...
<p>
For BOINC Documentaion: Click Me!

> In the grand scheme of things it should not have a significant impact.

I think it does. Let's say, just hypothecaly, everyone begins doing this, and the number of results that don't get reported or even uploaded before the deadline go dramatically up as a result of using this "scheme", more wu's have to be re-issued - thus slowing the whole project down.

> depending on the project's policies they can issue more initial results to
> fill the quorum faster. So if the quorum is 3, they could issue 5 and the
> first 3 win.

Must admit, I don't really understand this ;-) Could you explain this in more detail?

> The real issue here is are you here to assist in resaeach and also have a
> metric indicating the quantity? Or are you here for the metric and all else
> is unimportant?

And I gues this is kind of bothering me - as it seems to me most are here for the metric only. But I guess the message boards can't be used as an accurate indicator of this ;-)

> The idea here is that after you have primed the pump you should feel better
> because you appear to be getting the gratification faster. However, it is an
> illusion.

No kidding :-D

> This is just another one of those schemes, like the guy weaving in and out
> during rush hour, he saves 15 seconds on his trip at the expense of everyone
> else on the highway...

If he even saves a second at all ;-)


S@h Berkeley's Staff Friends Club ©

Surely this "strategy" will only work with units that have allready been out twice
With all other units you will just be delaying them 2 weeks before they can go to someone else.
Would that be right or have I missed something ?

Bruno,

> I think it does. Let's say, just hypothecaly, everyone begins doing this, and
> the number of results that don't get reported or even uploaded before the
> deadline go dramatically up as a result of using this "scheme", more wu's have
> to be re-issued - thus slowing the whole project down.

Well, I think there is a large "silent-majority" out there that don't even do much more than plug the program in and let it rip. In SETI@Home Classic I did not visit the forums very much at all. In part because of the clumsy interface.

In the case of SETI@Home there is a huge pool of people contributing. With that almost all issues will likely be processed fairly fast. I have a total of 6 computers now (had to get rid of 4, sigh) and even with multiple projects, with equal allocations of 20% (assuming Pirates/Einstein@Home goes live soon, and Predictor@Home also comes back in the next week or so) to each project I will still spend 20% of my time doing SETI@Home. At, call it 3.5 hours per SAH WU, 20% of a day is 4.8 hours available. Add in the fact that I have 2 HT machines and the Macintosh is a dual G5, I am going to have ... roughly 12 WU each day (4.8 * 9 / 3.5) returned as results.


> > depending on the project's policies they can issue more initial results
> to
> > fill the quorum faster. So if the quorum is 3, they could issue 5 and
> the
> > first 3 win.

Sure, look it up! :) It is in my glossary ... look in the "Q" section ...


> And I gues this is kind of bothering me - as it seems to me most are here for
> the metric only. But I guess the message boards can't be used as an accurate
> indicator of this ;-)

No it is not. Many lurk and don't get into the fray. The people that are angry or have some other agenda sometimes seem to come to boards and fan fires. I don't know why. But, one of the things that I am a believer in is that knowledge is useless if not shared. So, what little I know, I try to spread around. That does not make me infalible, nor noble. But, there has to be some that come here and talk/type and counter the heat with no light.

I don't always succeed. Nor have I been free of error myself. But when I have made a mistake, I have, and always will appologise. But we are digressing ...

> If he even saves a second at all ;-)

Exactly.

My best suggestion is to read what I have written, look at the links I have to the BOINC Developer site where you can see where I got my source data. Many of the pages were first written during the Beta test and field tested with the beta test group. Now I am mostly adding "features", a couple bugs in my scripts, and refining the content.

When I am well and can put in the time I get 4 to 12 hours work in ... last Friday I touched or added 84 pages or images. That was the object count of the up load. I got some time in Saturday so I already have abuot 20 objects touched, fixed, or added.

Other specific places you might want to look is in the BOINC FAQ and (to a lessor extent) the SETI FAQ. The pages in the Web Site Owner's Manual for the pages pending credit, results, and computer summary may also help ... happy reading.

<p>
For BOINC Documentaion: Click Me!

> One of the features that I am most excited about is the multi-project aspect.
> Heffed made the point in LHC@Home that he is doing cp.net and is never out of
> work. I have all 5 of the project locked and loaded and as work is available
> I have been enjoying seeing the system function and return science and in the
> nonce it is also exercising the system so that BOINC can grow and improve.

Yes, that's I think the most fascinating thing about BOINC. The ability to run several projects from one application. I find the concept of distributed computing much more interesting than any particular project, so I'm running everything that becomes available.

I'm still attached to BOINC beta, so I have six projects I'm attached to. Currently only three of them are giving regular work, but I'm ready whenever any of them want to send me something.

And yes, attach to CPDN and you'll never complain of lack of work again. :)

> And yes, attach to CPDN and you'll never complain of lack of work again. :)

Well, I don't know about that! My two HT machines downloaded only one model, so, it is possible I could run out... :)

Not likely with LHC@Home and SETI@Home having work most of the time ... But, I am interested to get Predictor@Home back ... I kind of liked having a few WU that would be done fast ... :)

Like a kid at Christmas time, I can't resist peeking all the time when I am working ...

I just hope most of my machines get done with the LHC@Home WU before they turn on the next generation ... I still have a bunch of those to work off ... But I think they will mostly be gone by tomorrow...

Now all I have to do is to remember to reset my allocation tomorrow, first thing! :)
<p>
For BOINC Documentaion: Click Me!

Should a regular use of the "Update" button not be a better way to get credits faster?
I think with the new low water mark rule that maybe this could accelerate it.

Greetings from Belgium.

> Should a regular use of the "Update" button not be a better way to get credits
> faster?
> I think with the new low water mark rule that maybe this could accelerate it.

Yes it will, in the sense that the requested credit would be posted earlier. But you are still dependent on the other members of the quorum. In the long run, I don't think any of these schemes will do more than give you the feeling that it is working better.

Since I am always peeking, I do that a lot, but, I am paying less and less attention to the whole business. Heck, I even changed to a non-credit signature. :)
<p>
For BOINC Documentaion: Click Me!

>
> > > depending on the project's policies they can issue more initial
> results
> > to
> > > fill the quorum faster. So if the quorum is 3, they could issue 5
> and
> > the
> > > first 3 win.
>
> Sure, look it up! :) It is in my glossary ... look in the "Q" section ...
>

Looks in your glossary under Quorum...
"Only those that participate in the creation of the quorum qualify for credit."

Sorry, this is a bug in your doctumentation and is not correct.

Remember, as long as you crunches correctly and returns before your individual deadline is out, you'll get credit if passes validation. The "canonical result" is immediately assimilated, but can't be deleted before all "results" for a wu is accounted for, either by validation, error or missed deadline.

I'll recommend to take a look on the examples below.
http://boinc.berkeley.edu/redundancy.php

> > Should a regular use of the "Update" button not be a better way to get
> credits
> > faster?
> > I think with the new low water mark rule that maybe this could accelerate
> it.
>
> Yes it will, in the sense that the requested credit would be posted earlier.
> But you are still dependent on the other members of the quorum. In the long
> run, I don't think any of these schemes will do more than give you the feeling
> that it is working better.
>
Well, it's more than just a feeling. Aging work units first before processing them and then promptly returning them will give faster credits, not just a feeling of faster credits.

Let's try describing it this way. If a result is returned the same day it is first issued (let's call it a "young" result), chances are the user will wait a while for the credit to be granted since the other two results for that WU, in general, won't be returned yet. And if a result is returned on the last day permitted (an "old" result) (not recommended to wait that long, BTW!), chances are the user will get credit right away since the other two results for that WU will, in general, already be returned. And so on to varying degrees for results somewhere between "young" and "old".

So, a user will generally get credits faster by aging WU's a little (as described in earlier posts) BEFORE processing them, then processing and promptly returning such "older" results (just as long as they don't get TOO old!). This is more than just a feeling; it's statistically valid. The older a result when returned, the faster (overall) will be the granting of the credit for that result. This provides a way to concentrate one's work on "older" results.


--Bill Z.

> Looks in your glossary under Quorum...
> "Only those that participate in the creation of the quorum qualify for
> credit."
>
> Sorry, this is a bug in your doctumentation and is not correct.
>
> Remember, as long as you crunches correctly and returns before your individual
> deadline is out, you'll get credit if passes validation. The "canonical
> result" is immediately assimilated, but can't be deleted before all "results"
> for a wu is accounted for, either by validation, error or missed deadline.
>
> I'll recommend to take a look on the examples below.
> <a> href="http://boinc.berkeley.edu/redundancy.php">http://boinc.berkeley.edu/redundancy.php[/url]


You are correct, it is not correct in the definition.

But I got you to look! :)

<p>
For BOINC Documentaion: Click Me!

I understand it now - Billy you're holding onto those units Soooo tight ( not really of course, you only propose the theory - of course you would NEVER practice what you preach) that you never-actually-let-them-go... which would go to some length to explain your RAC... lots of missed opertunites Billy !. If only you'd released the units a little earlier you'd have been part of the quorum !.

But alas. It wasn't so...

Actually - Thanks to Paul D. I think I actually understand your point - and grant you that. Still wouldn't do it myself - and neither would you... So I gotta ask - why even suggest it in the first place ?

I think what will actually happen is that the first two (who actually returned the unit in a reasonable amount of time) will get credit when the WU is assigned to a fourth cruncher, and that cruncher returns a result.

So the only one who loses is the one playing games with returned work.

> Nope. Listen to sense. Your half baken plan to speed up credit deleivery by
> placing a two week slow down on your initial delivery has the very real chance
> of failing to return credits at all. Which means that at least two others
> aren't going to get credits either.

> So, a user will generally get credits faster by aging WU's a little (as
> described in earlier posts) BEFORE processing them, then processing and
> promptly returning such "older" results (just as long as they don't get TOO
> old!). This is more than just a feeling; it's statistically valid. The older
> a result when returned, the faster (overall) will be the granting of the
> credit for that result. This provides a way to concentrate one's work on
> "older" results.

I still think you're missing a key bit of logic here Bill.

You aren't affecting speed in the slightest. Merely changing the timeframe in which you choose to measure your sample. It's not even slightly statistically valid as the outcome is the same regardless of "when you look".

Lets look at this another way shall we?

You are driving in your car. You wish to measure acceleration from 0 - 100mph. You have two measuring setups. Measurement one plots the speedometer reading every second, Measurement two plots every minute.

At the end of the run, Measurement one shows a nice steady graph leading up to 100mph. Measurement two however shows only two plots. 0mph, and 100mph. Holy crap!!!! Measurement two went instantly from 0 to 100! This is incredible! This must be the fastest car in the world! Call Guiness, we've set a record!

Kind of silly if you look at it that way isn't it? Both measurements took exactly the same amount of time to complete. Neither was "faster". The only difference is when the sample is measured. That's statistics for you.

> Also, the Work Unit will only be re-issued a certain number of times before it
> is tagged as being a "problem" at which point it will no longer be issued,
> even if there were some successful results.

Isn't this a weakness in SETI@HOME? I mean, what if they have some bug in their software that crashes when it encounters an alien signal? Wouldn't the "problem" unit actually be quite valuable? Do they inspect "problem" units in a non-distributed way at all or do they just throw it away?

> > Also, the Work Unit will only be re-issued a certain number of times
> before it
> > is tagged as being a "problem" at which point it will no longer be
> issued,
> > even if there were some successful results.
>
> Isn't this a weakness in SETI@HOME? I mean, what if they have some bug in
> their software that crashes when it encounters an alien signal? Wouldn't the
> "problem" unit actually be quite valuable? Do they inspect "problem" units in
> a non-distributed way at all or do they just throw it away?
>
The ones that crash on 20(?) machines are errored out of circulation. Development looks to see if they can figure out why. When they figure out why, the code gets fixed and the WUs can then be re-issued as new. I believe that this happened quite often in Beta.

Cool. I like this forum - there's a high signal-to-noise ratio, despite my input!

> > So, a user will generally get credits faster by aging WU's a little (as
> > described in earlier posts) BEFORE processing them, then processing and
> > promptly returning such "older" results (just as long as they don't get
> TOO
> > old!). This is more than just a feeling; it's statistically valid. The
> older
> > a result when returned, the faster (overall) will be the granting of the
> > credit for that result. This provides a way to concentrate one's work
> on
> > "older" results.
>
> I still think you're missing a key bit of logic here Bill.
>
> You aren't affecting speed in the slightest. Merely changing the timeframe in
> which you choose to measure your sample. It's not even slightly statistically
> valid as the outcome is the same regardless of "when you look".
>
> Lets look at this another way shall we?
>
> You are driving in your car. You wish to measure acceleration from 0 - 100mph.
> You have two measuring setups. Measurement one plots the speedometer reading
> every second, Measurement two plots every minute.
>
> At the end of the run, Measurement one shows a nice steady graph leading up to
> 100mph. Measurement two however shows only two plots. 0mph, and 100mph. Holy
> crap!!!! Measurement two went instantly from 0 to 100! This is incredible!
> This must be the fastest car in the world! Call Guiness, we've set a record!
>
> Kind of silly if you look at it that way isn't it? Both measurements took
> exactly the same amount of time to complete. Neither was "faster". The only
> difference is when the sample is measured. That's statistics for you.
>
> <a> href="http://www.boinc.dk/index.php?page=user_statistics&project=sah&userid=91863">
> [/url]
>

Thanks, Heffed, for your thoughtful analysis. It’s intriguing.

So. Let’s use your analogy. Here’s how I see it.

It’s not a matter of acceleration and velocity, but of the first integral of each of these: velocity and distance. Thus your (or someone’s) computer/car is running at the same speed every day, cranking out the same number of cobblestones/distance every day. Based upon this, one can calculate what the total credits/distance are at any moment. But to verify this, that person wants to check the UBC credits/milemarkers to verify the expected credits/distance.

Now the question is, how delayed will the external credits/milemarker data be that that person is trying to check?

Thus, it’s not a question of how much work one is doing or the distance being covered. That is a constant every day. It’s a question of how long one has to wait for external confirmation of that work/distance.

If one has to wait a long time for two other people to update their data, the confirmation data will be delayed. That doesn’t change the person’s work rate/velocity or credits/distance; it only changes how quickly that person can get confirmation of it.

That’s all I’ve been talking about – modestly reducing the delay.

Regardless, if one graphs the credits/score over time, there will be many data points, not just the two in your second example. The data of course will be bursty or choppy as your second example illustrates, but the data will resolve over time into a straight line. (A simple linear regression on the data will provide the line.) But the same is true of credits data that is coming in with any other reporting delay, since all reported data is at the mercy of other people working on the same WU’s. It’s just a question of how current the data will be, and not a question of its consistency, constancy, or direction. (Actually, the data should be smoother as one’s delay approaches the two week limit since for most such WU’s there will be less overall additional delay and thus less delay variability in reaching a quorum.)

Here’s another analogy. (I will switch from the impersonal “one” to the personal “you” since I hope you’ll like this analogy.) Let’s say you like wine, and you drink one bottle a week (i.e., a thousand cobblestones a week). But it’s fairly young wine, and you’d rather be drinking wine that’s been aged a bit more. The solution I’ve described is for you to continue drinking one bottle a week (generating a thousand cobblestones a week), but to put more bottles of wine in your wine cellar (increase your cache). As you continue to drink one bottle a week (generate a thousand cobblestones a week), you will notice that the wine you are drinking is getting older (the WU’s you are processing are getting older).

Thus, you are still generating the same amount of credits/consuming the same quantities of wine, but both have gradually become older. Older WU’s (in general) will have their credits granted sooner.

Does it make a real difference? Not really, as I’ve said before. The slope of the linear regression line, in the long run, will still be the same. The line will simply be displaced ever so slightly to the left.

So, why do I continue to promote this, as some have asked? Because others have posted concerns on this message board about credit delays and I wanted to offer them something they could do and control themselves to speed things up a little for themselves. In the past I’ve posted questions and others have helped me. I wanted to help in return. And indeed, the responses and discussions have turned out to be a lot of fun.

As a further personal note, I’ve said I wouldn’t do this myself (although there have been some playful challenges to that assertion). Indeed, as UCB has apparently become a little more stable, I’ve been slowly decrementing my Connect-to-Network setting. It’s currently (and has been for a while now) at 2.5 days.

How’s all that sound to you? :-)


--Bill Z.