Pilot Error! :-)

Yep, it seems to correspond to the brief period when a lot of the backend dropped out Wednesday, which makes sense.

Alinator

On my computers between 8th 22:49 and 9th 00:33 UTC.

Andy

From what I can tell, sometime around 23:00 UTC today (Wednesday). It caught my eye when I was looking over some of the Top Cmputers results.

WU with IR = 2

Alinator

Well, the issue of trailers is now moot for the most part. I just noticed the IR is now 2.

Alinator

When did this happen? I happen to have 9 aborts right at this moment, 8 of them on machines that were out of work completely earlier today, so I would think that those would have been in the IR 2 group... Unless it just happened in the past couple of hours?

-Dave

---

Well, the issue of trailers is now moot for the most part. I just noticed the IR is now 2.

Alinator

If I'm not mistaken, we ran 4/3 initially, when ESAH came out we ran 3/3 for a long time, and now they're experimenting with 3/2, on the way to 2/2.

So it wasn't a problem at 3/3, and it won't be at 2/2....

It was still 4/3 after the transition to ESAH, until they dropped to 3/2 back in early April.

That was what got me looking at it when I started getting a lot of trailers on my Intels after that with a 3 day CI.

When I stated going through the results I noticed that the old timers had gone from about having a 50-50 chnace of making the quorum to virtually zero chance and moved them all over to EAH exclusively and SAH as a backup only.

As it turned out, there are some problems with the scheduling of the longer results and slow hosts over on EAH, and with MB coming up I started letting them run SAH again, even though they run mostly trailers at this point.

Alinator

snipped .....

If I'm not mistaken, we ran 4/3 initially, when ESAH came out we ran 3/3 for a long time, and now they're experimenting with 3/2, on the way to 2/2.

So it wasn't a problem at 3/3, and it won't be at 2/2....

I'm pretty sure that originally it was 3/3, I sent Paul D. Buck some figures from my younger sons computer, that showed approx 38% of units in that snapshot had to wait for further issues so that quorum could be met.

N.B. Spec for min computer, was, benchmark 1000/1000, on 10% of time, would return work on time and have RAC approx 10.

@Fred,
If you turn the figures round in my earlier post 615586 what they mean is if you cannot return a unit in 48 hours then you have less than a 4.5% chance of that work being one of the first two return, i.e. useful.

I would go even further, looking at the same computer, today the 6th, it has so far downloaded 8 units. 2 are still here, one crunching, one in cache. Of the other 6 units only one (1) is pending.

Thats over 60% granted credit in 22 hrs.

Actually much less as first wasn't downloaded until after 10:00 UTC.

Andy

It's only a downside when they're sending three, and requiring two.

It has been stated that at some point in the (not too distant) future, they'll send two and require two.

This is a transient problem.

Understood and agreed! :)

Except I don't know about calling it 'transient'. It's been this way for as long as I can remember.

Back when I first started running BOINC, and it was still pretty 'betaish' with pretty unrefined and creaky CC's I could go along with the rationale for sending trailers in order to speed things up for development purposes overall.

Personally I don't think this has been the case for quite awhile and should have been addressed last year after they had gotten ESAH settled in.

Alinator

If I'm not mistaken, we ran 4/3 initially, when ESAH came out we ran 3/3 for a long time, and now they're experimenting with 3/2, on the way to 2/2.

So it wasn't a problem at 3/3, and it won't be at 2/2....

---

[quote]OzzFan: At the risk of repeating myself, if users who ONLY run a K6-2 class machine run with no cache (effectively), then they will start a WU as soon as it it downloaded. This will report (in many cases) before faster machines have got down to that WU in their (5 - 10 day) cache and, therefore, one of the faster machine will get "aborted by Project" and pick up another WU. So the project benefits, the "slow" machines ARE doing useful work. Of course, this does not apply if the "slow" machines are running with any cache.

Fred: This logic is not correct. Just because a faster machine with a 5 day cache might not start processing this WU right away, doesn't mean that it still won't beat my K6-II CPU. Many machines can process many per day, regardless of how large their cache is, and can (and do) report before my K6-II.

In point of fact, I have ran SETI on a K6-II 500, 450, Cyrix PR366, Pentium 233MMX, Pentium II 333 and every one of them except the PII 333 return last (third in a quorum) more than 80% of the time.

Please, before you assure me that my computers "are" doing useful work, run a slow computer yourself and see what the results are. If you cannot, then you do not know and cannot assure me of what you speak of.

---

If one of your client computers is not meeting your specific goals for whatever reason then that is your problem.....not the projects. Maybe you should retire those client computers??

Well let me assure you that I look closely at what all of my hosts are doing at all times, and when they fail to meet expectations at any time are either adjusted or retired from service in that role.

But that's hardly the point that mandating by decree all hosts might have to waste time on trailers for no good reason given the current state of the project before 221 functionality came along.

Also, it should be apparent by now that all 221 functionality does is mitigate the problem of wasted time for faster hosts with big caches, at the expense of making it more worthless to run the project for other hosts, which are otherwise fully capable of meeting the minimum specifications of the project for participation, as stated on the web site and WU parameters.

In addition, if the project had intended to restrict participation to only the latest and greatest, then why were the deadlines set using an older host running a 33 percent uptime duty cycle as the standard (I forget what the exact spec was but ISTR something like a PI/100 running 8 hours a day). One hardly needs up to 6 week deadlines to accomodate A64, Opty, P4, and Core 'X'.

I could turn your statement around by saying why should I retire perfectly good hosts from service just so somebody else can get credit granted sooner or let the project 'overbook' their servers?

Alinator

OzzFan: At the risk of repeating myself, if users who ONLY run a K6-2 class machine run with no cache (effectively), then they will start a WU as soon as it it downloaded. This will report (in many cases) before faster machines have got down to that WU in their (5 - 10 day) cache and, therefore, one of the faster machine will get "aborted by Project" and pick up another WU. So the project benefits, the "slow" machines ARE doing useful work. Of course, this does not apply if the "slow" machines are running with any cache.

With all due respect, this is not correct in practice.

What you are saying is theoretically correct, except the sum total of all participants running at either extreme of CI (or Cache override) setting is small. Most are probably between the default 0.1 day and 3 days. It would be nice if the project would post an overall result turnaround time statistic for just this reason.

Also, you are assuming an old timer running a minimum CI is only crunching for SAH. At least for me this not the case, since one of the main reasons I run them on BOINC is to make sure the new versions of the CC and backend work as expected with older hosts. With a minimum CI, the only way to ensure they don't go idle is to run multiple projects.

Finally, both Ozz and I run K6's, so let me assure you under a multple project scenario the K6's have a very slim chance of making the quorum (and I have hard data to back that up), even though they still return the result within the deadline by a wide margin for SAH.

Alinator

Then tough for them, and let them be noisey.

The fact of the matter is pending credit has no real downside. I have been unable to find a negative effect on any aspect of my participation overall in over a year of trying to find one.

OTOH, wasting my hosts time running a trailer has a measurable negative effect on my electric bill, by merely using a 'Kill-a-Watt' and pocket calculator.

Personally I'm going to say that one reason for poor participant retention in BOINC overall, is that the vast majority of people who give it a try (but don't post one way or the other, if at all) are able to figure this simple situation out for themselves and would rather not waste their money if they can help it. I include 'forced' hardware upgrades to continue to donate an 'unused quantity' effectively as part of wasting and being outside the scope of the intent of the whole BOINC concept.

Alinator

If one of your client computers is not meeting your specific goals for whatever reason then that is your problem.....not the projects. Maybe you should retire those client computers??

---

Boinc....Boinc....Boinc....Boinc....

Seems to me then that you need to make a decision as to the usefulness of the K6-2 class computers to meet your goals in the projects assigned to it. It's a user decision NOT a Boinc project decision.

Precisely. Can you point out to me where I said it was a project issue? Though, there is a decision to be made by the project for those owners of slower machines that want to contribute to the science.

Do they want those users to walk away? Or do they want their computer power too? I completely understand if they would rather those users walk away, and I would not have negative judgement against SETI if they said so.

I just wanted to make them understand the downside to this new 'feature'.

OzzFan: At the risk of repeating myself, if users who ONLY run a K6-2 class machine run with no cache (effectively), then they will start a WU as soon as it it downloaded. This will report (in many cases) before faster machines have got down to that WU in their (5 - 10 day) cache and, therefore, one of the faster machine will get "aborted by Project" and pick up another WU. So the project benefits, the "slow" machines ARE doing useful work. Of course, this does not apply if the "slow" machines are running with any cache.

If this is done then those who require instant crediting for their work will start crying loudly. And believe my this group can be very noisy!

It's a tough choice for the developers and I for one don't envy them in this decision. They will offend one group or another but the project must go on.

Then tough for them, and let them be noisey.

The fact of the matter is pending credit has no real downside. I have been unable to find a negative effect on any aspect of my participation overall in over a year of trying to find one.

OTOH, wasting my hosts time running a trailer has a measurable negative effect on my electric bill, by merely using a 'Kill-a-Watt' and pocket calculator.

Personally I'm going to say that one reason for poor participant retention in BOINC overall, is that the vast majority of people who give it a try (but don't post one way or the other, if at all) are able to figure this simple situation out for themselves and would rather not waste their money if they can help it. I include 'forced' hardware upgrades to continue to donate an 'unused quantity' effectively as part of wasting and being outside the scope of the intent of the whole BOINC concept.

Alinator

It's only a downside when they're sending three, and requiring two.

It has been stated that at some point in the (not too distant) future, they'll send two and require two.

This is a transient problem.

Understood and agreed! :)

Except I don't know about calling it 'transient'. It's been this way for as long as I can remember.

Back when I first started running BOINC, and it was still pretty 'betaish' with pretty unrefined and creaky CC's I could go along with the rationale for sending trailers in order to speed things up for development purposes overall.

Personally I don't think this has been the case for quite awhile and should have been addressed last year after they had gotten ESAH settled in.

Alinator

It's only a downside when they're sending three, and requiring two.

It has been stated that at some point in the (not too distant) future, they'll send two and require two.

This is a transient problem..

If this is done then those who require instant crediting for their work will start crying loudly. And believe my this group can be very noisy!

It's a tough choice for the developers and I for one don't envy them in this decision. They will offend one group or another but the project must go on.

---

Boinc....Boinc....Boinc....Boinc....

Seems to me then that you need to make a decision as to the usefulness of the K6-2 class computers to meet your goals in the projects assigned to it. It's a user decision NOT a Boinc or Seti project decision.

OK, here's the criteria I use:

Is it possible for the host to complete the result within the deadline, if the project is run as the only one on the host?

If the answer is yes, then it is worthwhile to run it on the project, by definition.

Therefore, the decision to issue trailers by default is an arbitrary project side decision, made for reasons other than whether a host is capable of making the deadline or not.


IMHO, to do so just so credit can be granted quicker in the event of a host failure is not a valid reason to waste any of a participants contributed runtime, if at all possible to avoid. Lets face it, credits are worthless, whereas completed WU and KWh's have tangible value.

If it is done so that a certain factor of 'busy' work is issued so that some aspect of the project backend is not overloaded (Raw data burn rate, DB size management, dropout rate, etc.), then that is still a project side problem.

In this case the issue is better addressed by either putting in hardware resources capable of handling the load, or restricting work generation to a level which the current hardware can handle reliably.

Alinator

It's only a downside when they're sending three, and requiring two.

It has been stated that at some point in the (not too distant) future, they'll send two and require two.

This is a transient problem.

Understood and agreed! :)

---