When I started to process data for this project that work moved fast and things flowed well. Sometimes I get work that moves fast and other times, mostly other times I get work that takes forever and a day to process hence it takes away from my other space sciences research. Who screwed this up? I would like to know and can it be fixed? I suspended the project until it works the way it used to. It seems that every time someone tries to make something better they turn it into a nightmare. Is it going to be fixed or not?


Ronald C. Spencer-Astronomer

---

I'm not sure precisely what you're referring to because the change to various length tasks happened about 6 weeks ago.

In case it relates, it was addressed in this thread.

It may be that you're unhappy about the change in deadline for the work. If so, that was posted to the news on the front page and discussed in this thread and this one as well. The deadline is set short due to the nature of the project requirements. I'd explain it in more detail, but frankly, I already have in the above posts and I'm getting a bit weary of it.

So to answer your issues:

Sometimes I get work that moves fast and other times, mostly other times I get work that takes forever and a day to process hence it takes away from my other space sciences research.

At present there are 3 different sizes of tasks. Some are quite short (minutes), some are medium (~3-4 hours) and some are quite long (~6-8 hours). Unless you have the cache of work in your machine set to more than a couple days the BOINC client should hold off doing work for this project until it makes up the time for other projects.

Who screwed this up? I would like to know and can it be fixed?

Nobody. The really short work was never intended to be the final product. This is a BETA project and the developers are finding the correct balance between science returns vs. run-times. I'd say it's likely that we'll not see a large variety like this in the future, but a new application is coming soon, so it's certainly possible.

I suspended the project until it works the way it used to.

I'm not really quite sure what to say other than... Okay, bye. Again, it's a beta project, so things are going to change, but they're never going to change back to they way they "used to" be.

It seems that every time someone tries to make something better they turn it into a nightmare. Is it going to be fixed or not?

I understand that not everyone can achieve your evident sublime perfection, but I would suggest that you not participate in beta test projects with a 6-7 year old Pentium III if you want everything to go perfectly. In the meantime, try switching to decaf. It might help prevent you from making petty, angry and belligerent posts in the future.

To those who read these forums who's opinion I care about: Yes, I know I was a bit of a sarcastic ass, but I really get tired of people who don't read the forums and instead make whiney posts to express why projects should change to meet their needs exclusively. Oh, and I don't drink decaf either.

---

Who screwed this up? I would like to know and can it be fixed?

Nobody. The really short work was never intended to be the final product. This is a BETA project and the developers are finding the correct balance between science returns vs. run-times. I'd say it's likely that we'll not see a large variety like this in the future, but a new application is coming soon, so it's certainly possible.

This problem was encountered over at Einstein with S5R3. People would routinely complain about how Einstein was "hogging" their system. Most of the people affected had older/slower machines or low resource shares. I advocated a change from 14-day deadlines to 18-day deadlines so as to help reduce the angst...

That same suggestion cannot be made here. Why?

The difference between the two projects is that the observations that Einstein asks users to process have already happened, with new task generation not depending upon other tasks to be completed, where as each generation of tasks here (except for maybe the 371s????) requires someone else to have completed work before it...

Since NHST (Northern Hemisphere Summer-Time) is coming to a close, there will be more and more participants bringing their systems back online over the next few weeks, so I would anticipate this topic to be repeatedly brought up, with much gnashing of fingers and teeth...

Also, as I pointed out in another thread here, the other way to do this to get results back quick is to increase the number of Initial Replications, but this will draw the ire of another equally (if not more) vocal set of users who don't like the additional replications and see them as placation of users who demand to have work available. The example project I am referring to is LHC... LHC took the approach of setting the replication to 5, but quorum to 2, so 3 tasks are possibly "wasted", and if they are, then you bet your bottom dollar there will be a group of people over there griping about how wasteful the project is and that they should lower their deadlines instead (leading to the situation we have here)...

Ronnie C and his Pentium III (733), is getting a large amount of attention from some very talented people (myself excepted).

He apparently feels the impact of his cherished hardware on this project deserves
major revisions to the protocol the rest of us are satisfied with.

Have I missed something?

Ronnie, lose the doorstop.

Voltron

---

Vcore...Vcore...gotta make it sweat to score.

OK folks, thank you for your input and information. Have a great Labor Day weekend.

Hence the reason to post system requirements somewhere, A link right under "Join MilkyWay@home", on the home page, might be a good place. Minimum requirements would be? My Intel(R) Pentium(R) D CPU 3.20GHz, 1 Gig ram, stock, per core; takes about 8 hours for a long task.

[edit] I would guess a Pentium(R) 4, 2.0GHz, would be the minimum at this time. [/edit]

Thanks for this input. We don't like to limit people from projects. While the tasks are very very long on this sort of machine, some people still like to contribute with what they have. What do you think?

---

Dave Przybylo
MilkyWay@home Developer
Department of Computer Science
Rensselaer Polytechnic Institute

Thanks for this input. We don't like to limit people from projects. While the tasks are very very long on this sort of machine, some people still like to contribute with what they have. What do you think?

But at some point, I would be wasting cpu time. At what point and what share would that be? Will my 486DX2-50 work? Do I have to crunch for a week to find out that it was to slow?

Thanks for this input. We don't like to limit people from projects. While the tasks are very very long on this sort of machine, some people still like to contribute with what they have. What do you think?

Good try there. But then you to take into consideration that there are people who have older systems that want to contribute even if it does take a very very long time and with short deadlines they are now having to make a decision if it is worth the effort.

---

Thanks for this input. We don't like to limit people from projects. While the tasks are very very long on this sort of machine, some people still like to contribute with what they have. What do you think?

Well, Nate, and Travis (And I assume you too) are of the opinion that if your host can meet the deadline, then the work it did has value and wasn't wasting its time.

So my experience is anything as capable as a G3/400 Mac has no trouble making it even on the long work. I have a K6/300 which is overrunning the deadline for a long one, but should be able to make it for the others.

So I'm not seeing a problem in this regard. So what if they take a while to run? They are still almost infinitesimal compared to CPDN! ;-)

Alinator

Thanks for this input. We don't like to limit people from projects. While the tasks are very very long on this sort of machine, some people still like to contribute with what they have. What do you think?

Well, Nate, and Travis (And I assume you too) are of the opinion that if your host can meet the deadline, then the work it did has value and wasn't wasting its time.

So my experience is anything as capable as a G3/400 Mac has no trouble making it even on the long work. I have a K6/300 which is overrunning the deadline for a long one, but should be able to make it for the others.

So I'm not seeing a problem in this regard. So what if they take a while to run? They are still almost infinitesimal compared to CPDN! ;-)

Alinator

Hmmm...that's a good point. I didn't really think about some machines being able to meet some deadlines and not others. Maybe we'll have to set a hard line for requirements for each workunit type and leave it up to the users to decide if it's worth not meeting some deadlines.

---

Dave Przybylo
MilkyWay@home Developer
Department of Computer Science
Rensselaer Polytechnic Institute

What do you think?

---

me@rescam.org

I have a K6/300 which is overrunning the deadline for a long one, but should be able to make it for the others.


Alinator

Just wondering how close the K6 comes to completion on the long work units.
I have a k6-2 300 oc to 350mhz I retired it from s@h about 6 months ago where it was managing a RAC of about 13 running 24/7. It was running s@h for over 8 years on and off and it might be fun to fire it up again if it has a chance to complete the long work units.

UncleVom

PS It either works or it doesn't, I don't think the project should be modified to accommodate such historic artifacts. ;-)

Hmmm...that's a good point. I didn't really think about some machines being able to meet some deadlines and not others. Maybe we'll have to set a hard line for requirements for each workunit type and leave it up to the users to decide if it's worth not meeting some deadlines.

Well, I don't think it will be a problem once you guys get a little bit better handle on the POP estimates for the searches.

If you get them set between different 'difficulty' factors so the TDCF isn't jumping around a lot, then the scheduler should be able to make a pretty good judgment about whether the host is going to be able to cut it on that particular search.

Alinator

Just wondering how close the K6 comes to completion on the long work units.
I have a k6-2 300 oc to 350mhz I retired it from s@h about 6 months ago where it was managing a RAC of about 13 running 24/7. It was running s@h for over 8 years on and off and it might be fun to fire it up again if it has a chance to complete the long work units.

UncleVom

PS It either works or it doesn't, I don't think the project should be modified to accommodate such historic artifacts. ;-)

It looks like the K6/300 will blow the deadline by about 18 hours. However, I've been watching the new wingman, and it'll be close but I think the old timer will still get it back before the wingman reports. ;-)

My K6-2/500's and K6-3/450 run the long ones with around 24 hours to spare.

They may be old, but they take a lickin' and keep on tickin'! :-)

Alinator

It looks like the K6/300 will blow the deadline by about 18 hours. However, I've been watching the new wingman, and it'll be close but I think the old timer will still get it back before the wingman reports. ;-)

My K6-2/500's and K6-3/450 run the long ones with around 24 hours to spare.

They may be old, but they take a lickin' and keep on tickin'! :-)

Alinator

Thanks I'll give it a shot then and see what happens.
This one is on an old FIC VA503+ motherboard, the beast with the all the jumpers.

When the cold weather comes I'll probably fire up a few Athlons too, in the winter I can justify it as heating. :-)

UncleVom

Hmmm...that's a good point. I didn't really think about some machines being able to meet some deadlines and not others. Maybe we'll have to set a hard line for requirements for each workunit type and leave it up to the users to decide if it's worth not meeting some deadlines.

I'm not meaning to over-complicate things here, but...

ClimatePrediction has a feature in its account settings to enable one to pick which length of work unit to run. Maybe it would be possible to do this purely for the longest work units - then people with slower computers could leave it blank and not get them. I guess it'd have to be well 'publicised' to make sure everyone knows about it, so that those who can run the longest work units don't miss out.

Just a thought... :-)

Thanks I'll give it a shot then and see what happens.
This one is on an old FIC VA503+ motherboard, the beast with the all the jumpers.

When the cold weather comes I'll probably fire up a few Athlons too, in the winter I can justify it as heating. :-)

UncleVom

LOL...

Yep, the VA503+ is solid performing board for its day. I know all about the jumpers. I've got an Asus P-5A, P5-VM, and a Tyan Trinity, so I've got plenty of them to play with too! :-)

Aliantor

I'm not meaning to over-complicate things here, but...

ClimatePrediction has a feature in its account settings to enable one to pick which length of work unit to run. Maybe it would be possible to do this purely for the longest work units - then people with slower computers could leave it blank and not get them. I guess it'd have to be well 'publicised' to make sure everyone knows about it, so that those who can run the longest work units don't miss out.

Just a thought... :-)

That's really not a bad idea. At CPDN there are 3 basic models. The short one takes a couple of weeks on my system. The second group can take 3 to 6 months and you get whatever is available in that group. The new model spedifies memory requirements and system abilites and the scheduler isn't supposed to send that unless it meets the requirements. I don't know what the runtimes are for that. It should be fairly easy for Travis to set up the same sort of system here. Staggard completion times based on the type of work that the system pulls down. That way he can have a few manageable models to work with and all of them have a deadline set fo that particular model and then the science is relevant for his science apps. And example "could be" small units 2 days, medium units 3 days and large ones 4 days. This is NOT a recommendation but only and example that may or may not work out for the project so that various searches are able to be processed at the same time and volunteers can selectively chose what is right for their systems in order to meet the deadlines.

I realize that this is a beta stage project and maybe having some fresh options presented in the right light could benefit the project. Who knows with all the work Travis and the other project admins have had to do maybe they didn't have a chance to think of this or were so busy with all the other stages that it wasn't an option that could be explored at this time. If we are moving in to a new phase maybe this is something that will help?

For what its worth I have 3 computers with a total of 5 cores. I have 3 set to einstein, 1 to CPDN and 1 to Milky Way and I have my network settings to always available and nothing for additional cache. I'm not havign trouble meeting the deadlines, but I can see where there maybe people who are not able to meet deadlines for any number of reasons.

---

I'm not meaning to over-complicate things here, but...

ClimatePrediction has a feature in its account settings to enable one to pick which length of work unit to run. Maybe it would be possible to do this purely for the longest work units - then people with slower computers could leave it blank and not get them. I guess it'd have to be well 'publicised' to make sure everyone knows about it, so that those who can run the longest work units don't miss out.

Just a thought... :-)

That's really not a bad idea. At CPDN there are 3 basic models. The short one takes a couple of weeks on my system. The second group can take 3 to 6 months and you get whatever is available in that group. The new model spedifies memory requirements and system abilites and the scheduler isn't supposed to send that unless it meets the requirements. I don't know what the runtimes are for that. It should be fairly easy for Travis to set up the same sort of system here. Staggard completion times based on the type of work that the system pulls down. That way he can have a few manageable models to work with and all of them have a deadline set fo that particular model and then the science is relevant for his science apps. And example "could be" small units 2 days, medium units 3 days and large ones 4 days. This is NOT a recommendation but only and example that may or may not work out for the project so that various searches are able to be processed at the same time and volunteers can selectively chose what is right for their systems in order to meet the deadlines.

I realize that this is a beta stage project and maybe having some fresh options presented in the right light could benefit the project. Who knows with all the work Travis and the other project admins have had to do maybe they didn't have a chance to think of this or were so busy with all the other stages that it wasn't an option that could be explored at this time. If we are moving in to a new phase maybe this is something that will help?

For what its worth I have 3 computers with a total of 5 cores. I have 3 set to einstein, 1 to CPDN and 1 to Milky Way and I have my network settings to always available and nothing for additional cache. I'm not havign trouble meeting the deadlines, but I can see where there maybe people who are not able to meet deadlines for any number of reasons.

Hmmm...

The only catch is once you give the participants the choice, you might end up not getting enough horsepower to run a search efficiently due to runtime length or other concerns. It seems like the experience at SAH has folks increasingly looking for a way to opt out of AP due to run length, tightness factor, and concerns about that other issue, for example. ;-)

In any event, it's essential that you have good POP estimates for the various searches because you really have to try to keep the hosts' TDCF from jumping around as much as possible. Fortunately, the nature of the work here would seem to make that much easier than it is for some other projects.

On the old timers front, the K6/300 did finish, and beat the wingman back! :-)

It turned out the long task in just under 312 Ksecs, and made the bump in TDCF to around 80.

However, there seems to be something screwy with the backend work scheduler. The next task it drew was a shorty, which it knocked off in the expected 5 Ksecs range, but the scheduler followed that up by sending another long task. It should now know that the host cannot complete it by the deadline (estimated RT ~310 Ksecs), and thus should have given it a "won't complete in time" brush off.

This seems to be very similar to what was happening on EAH awhile back when they were experimenting with variable deadlines.

Alinator