Which apps are acceptable?

Any of them????

I have set all my machines , but 1 to NNW. and on that one machine have set it to the supposedly official app and am now getting invalid results on that machine.

PLEASE PLEASE PLEASE!!!!!!!!!!

What is acutually accepable

And please Sticky this thread and lock it make it the DEFINITIVE answer no questions no arguments WHAT CAN WE RUN!

From what I have read Linux apps are acceptable but *some* (how many?) windows apps are giving bad results. Which means not all, but atleast one is. Perhaps if someone starts to get no credit for returned results the specific app can be noted and changed.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Yes but what travis is saying is no optimised apps will be getting credit by tomorrow. So an answer to what can we run is required. from what iread ie no optimised apps getting credit then all we can run is the official app and that is 10 times slower on my machine.

Yea I know. Here 6 hours ago he says it is ok after the no credit was posted: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=567&nowrap=true#8683

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

EXACTLY!!!!

Any optimized app needs to be recompiled as per the instructions in the code discussion forum. If you're using an optimized app, you're going to want to swap back to the stock app until that app is recompiled.

If you're using a stock app then you should not have any problems getting credit.

At the moment (there will be a news post tomorrow), all apps are being granted credit, with the exception that if a result is returned with an impossible result, that is marked invalid and no credit is awarded. Tomorrow, after the announcement, only stock apps and optimized apps compiled with the new instructions will be awarded credit.

As to the original poster, are ALL workunits crunched by that machine being marked invalid? Or just a couple? If they're all being marked invalid there might be some problem with your machine that needs to be looked at.

*edit* looking at your hosts, it seems that all the most recent WUs you've processed have been returned as valid...

---

Here is a better idea lets all go to ABC. see you all there...

---

I think you will drive more users away than before. You keep changing the 'rules'. First it's ok to use the apps as long as they checkout to the 10th place, which many of them did. Then no one is allowed to use another app. Either the code is open and new ones can be created or not. It is understandable that bad results are comming back and should be corrected. But this is TOO harsh for all users. Since you could tell who was turning in bad wu's 5 weeks ago why not now so that the users can change the app to one that works?

You should post the current 'rules' so that everyone can follow them and know what to expect.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I think you will drive more users away than before. You keep changing the 'rules'. First it's ok to use the apps as long as they checkout to the 10th place, which many of them did. Then no one is allowed to use another app. Either the code is open and new ones can be created or not. It is understandable that bad results are comming back and should be corrected. But this is TOO harsh for all users. Since you could tell who was turning in bad wu's 5 weeks ago why not now so that the users can change the app to one that works?

You should post the current 'rules' so that everyone can follow them and know what to expect.

Why is this too harsh? People can use the stock application and there should not be any problems. They can update to the latest optimized applications when they are released, which probably will be rather quickly. I don't think having to use the stock app for a day or two is such a horrible measure.

Sadly, this is the only way to get our server-side validation of correct results in place, due to the fact that way too many of our users are using apps which are returning incorrect results. Again, this project is still in alpha (with good reason), so things like this WILL happen from time to time.

*edit*

Also, the main point of this project is to do actual science. Right now the incorrect apps floating around out there are getting in the way of that. This is the best and fastest way I could come up with to resolve the problem. I also think you're making a bigger deal out of this than it actually is.

1. if you're using the stock app, you should be totally unaffected.
2. if you're using an optimized app (that hasn't been updated with the changes I posted yesterday), you can revert to the stock app until a newer version is made available.

I purposefully let everyone know about this a couple days in advance, so they would have time to revert to our stock app or get a more recent version of an optimized app. The changeover wont be until late tomorrow, so I don't see why this is an issue.

---

There is nothing wrong with having an optimized app identify itself. It's been that way at SETI for a very long time.

Windows optimized S@H Enhanced application by Alex Kan
Version info: SSE3 (AMD/Intel, Core 2-optimized v8-nographics) V5.13 by Alex Kan
SSE3 Win32 Build 41 , Ported by : Jason G, Raistmer, JDWhale

---

me@rescam.org

The reason for it being too harsh is that there is already much faster windows apps that do work.

Since you could tell who was turning in bad wu's 5 weeks ago why not now so that the users can change the app to one that works?

Why not answer this? It should only be an app or two that is having problems.

I purposefully let everyone know about this a couple days in advance

A couple days?? You posted on the main page in the afternoon yesterday and in this topic at: 20 Jan 2009 3:47:05 UTC and today the other apps are going to be invalid. That is not a couple days advance.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Aside from running the optimised client against the stock client on the test WU, the current way to check is whether your hosts are getting credit now Travis is running the script on the assimlator/validator. Bad results return will not get credit, and you can see if this applies to your hosts.

I believe the optimised clients I use are cleared by others, when they reported earlier in other threads. But, I am regularly checking my hosts for no-credit returns to be safe.

Problem is: even if the optimized Windoze app did return GOOD results all the times the WUs won't validate anymore until the good app is recompiled with the new flags which are now needed:

...So as of tuesday/wednesday, we'll not be awarding credit to applications compiled without these flags (ie, those that don't write the app_name and app_version to the WU's result)...

(quoted Travis from here.)


EDIT: So I guess we need these guys who compiled the (good) optimized apps again to add these flags when recompiling their apps... PLEASEEEE! ;-)

---

Lovely greetings, Cori

There is nothing wrong with having an optimized app identify itself. It's been that way at SETI for a very long time.

Windows optimized S@H Enhanced application by Alex Kan
Version info: SSE3 (AMD/Intel, Core 2-optimized v8-nographics) V5.13 by Alex Kan
SSE3 Win32 Build 41 , Ported by : Jason G, Raistmer, JDWhale

Holy crap, I agree with Misfit!

Ditto!!!

What's the problem with adding or altering a small portion of any code so that all optimised apps return info about which app was used, so the validator can accept or reject results based on whether they come from a good or bad app?

I only started using optimised apps recently, and am getting used to being competitive with my CPU time (and electricity bill!), so appreciate knowing there is an option to use known good apps without fear of losing all my credits for any app. On the other hand, I also understand that some people are not fortunate enough to be online every day, so some folk might have updated their optimised apps at the weekend, and find next weekend when they get online again that they have no credits for the week (or half of it...).

Swings and roundabouts...

BTW, I will continue to use the latest optimised apps that are known to be good (and returning credits) until such time as newer apps with the same good results are released (and will not have more than a few short hours gap, in case I am out for the evening when they get updated).

The reason for it being too harsh is that there is already much faster windows apps that do work.

Since you could tell who was turning in bad wu's 5 weeks ago why not now so that the users can change the app to one that works?

Why not answer this? It should only be an app or two that is having problems.

Telling if a WU result is bad manually by personally looking at the data is a LOT easier than having a computer do it automatically for you. In fact, robust error detection is still a rather open research question. If i look at results coming in I can get a pretty good idea if they're good or not, but having the Milkyway server detect if a result is bad based on other results is seen isn't nearly as easy. I think we've gotten a good system set up for this now (which is part of why doing this took so long), but to do it we need a certain % of results to be good before we can start weeding out the bad ones.

I purposefully let everyone know about this a couple days in advance

A couple days?? You posted on the main page in the afternoon yesterday and in this topic at: 20 Jan 2009 3:47:05 UTC and today the other apps are going to be invalid. That is not a couple days advance.

I know and i haven't stopped rewarding any credit to anyone yet :)

---

Just to make my spot clear, I have nothing against adding flags or however to see which version is used. It just seems that each step forward is a handfull back.

@ Travis: Do you know which/any specific computers/users are turning in bad results? If the a/an app is known, then that can be eliminated as a good one all the quicker and get the good data flowing sooner. Instead of recompiling a bad app and putting it back out to be used.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Just to make my spot clear, I have nothing against adding flags or however to see which version is used. It just seems that each step forward is a handfull back.

@ Travis: Do you know which/any specific computers/users are turning in bad results? If the a/an app is known, then that can be eliminated as a good one all the quicker and get the good data flowing sooner. Instead of recompiling a bad app and putting it back out to be used.

The way things are right now it's not possible to tell which applications are returning the bad results (ie, there's no flag or information that says what application is being run). All I know is that there is 1 to 3 bad optimized windows applications out there. The compilation requirements for applications to be awarded credit will let us know which results are coming from which applications, because this will append the applications name/version to the resut, and this will let us find out which are applications are causing problems.

---

Just to make my spot clear, I have nothing against adding flags or however to see which version is used. It just seems that each step forward is a handfull back.

@ Travis: Do you know which/any specific computers/users are turning in bad results? If the a/an app is known, then that can be eliminated as a good one all the quicker and get the good data flowing sooner. Instead of recompiling a bad app and putting it back out to be used.

The way things are right now it's not possible to tell which applications are returning the bad results (ie, there's no flag or information that says what application is being run). All I know is that there is 1 to 3 bad optimized windows applications out there. The compilation requirements for applications to be awarded credit will let us know which results are coming from which applications, because this will append the applications name/version to the resut, and this will let us find out which are applications are causing problems.

...now we just need way to find out if someone uses false names for his app; let's say something like "stock".

---

mic.