Greetings,

Milkyway@home 1.43 OpenCL app doesn't show.

Milkyway@home is the app. 1.43 OpenCL is a version.
https://milkyway.cs.rpi.edu/milkyway/apps.php

Some projects do it differently.

There are similar discussions in the News of Projects and Apps Starting and Ending... thread.

Sadly, looks like this hasn't changed.
Milkyway@home Separation v1.46 (opencl_ati_101) or Milkyway@home Separation v1.46 (opencl_nvidia_101) are the GPU versions but it still reports as MilkyWay@Home on WUProps.


Is there a limit on the WU data field at WUProps to 32 characters?
Could the (opencl_ati_101) or (opencl_nvidia_101) be truncated?

There are 2 apps and you can receive credit for both. One is just missing 'separation'
Milkyway@Home MilkyWay@Home 28,755.23 83.38
Milkyway@Home MilkyWay@Home N-Body Simulation 1,321.95 0.00

There are 2 apps and you can receive credit for both. One is just missing 'separation'
Milkyway@Home MilkyWay@Home 28,755.23 83.38
Milkyway@Home MilkyWay@Home N-Body Simulation 1,321.95 0.00

Yes, this was obvious from analyzing my results.
This wasn't my question.

Is that a limitation of the exported sub-project data from Milkyway or is (opencl_ati_101) and (opencl_nvidia_101) being lost due to a truncation of the data field here at WUProps?
This answer would need to come from someone that actually works on WUProps database.

There are 2 apps and you can receive credit for both. One is just missing 'separation'
Milkyway@Home MilkyWay@Home 28,755.23 83.38
Milkyway@Home MilkyWay@Home N-Body Simulation 1,321.95 0.00

Yes, this was obvious from analyzing my results.
This wasn't my question.

Is that a limitation of the exported sub-project data from Milkyway or is (opencl_ati_101) and (opencl_nvidia_101) being lost due to a truncation of the data field here at WUProps?
This answer would need to come from someone that actually works on WUProps database.

Would you settle for an answer from the guy who runs the PrimeGrid project?

There's a difference between an "App" and an "App Version". It's got nothing at all to do with the length of the strings.

WUProp combines your hours by "apps". It's the individual project administrators who determines what an "app" is.

The information you were given before is correct: Milkway has two apps, with many app versions each.

It's the same thing at PrimeGrid. You can run PPS-Sieve on a CPU, on an Nvidia GPU, on an AMD GPU, and theoretically on Android devices. But they're all set up as different app versions of the same app, so they count as just one app at WuProp.

If I instead set them up as different apps at PrimeGrid, then they would count as different apps at WUProp.

Does that make sense?

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

There are 2 apps and you can receive credit for both. One is just missing 'separation'
Milkyway@Home MilkyWay@Home 28,755.23 83.38
Milkyway@Home MilkyWay@Home N-Body Simulation 1,321.95 0.00

Yes, this was obvious from analyzing my results.
This wasn't my question.

Is that a limitation of the exported sub-project data from Milkyway or is (opencl_ati_101) and (opencl_nvidia_101) being lost due to a truncation of the data field here at WUProps?
This answer would need to come from someone that actually works on WUProps database.

WUProp doesn't distinguish between plan_class within an app. Asteroids isn't listed for SSE2, SSE3, AVX, etc. Just 'Period Search Application', the app name.

Project: MilkyWay
App: MilkyWay@Home Simulation
Version or plan_class: opencl_ati_101

There is no sub project. Maybe grid projects like WCG can be considered to have a sub project.

Once you all mentioned 'app version' and 'plan class' my understanding crystallized. I've not taken part in a coding project since the late 80's.

Would be nice for WUProps if all projects differentiated by major changes in app versioning (as from CPU to GPU implementations) but frustrating to achieve 100,000 hours if every new version meant an 'app' name change on WUProps. SETI@Home has done 8 versioning changes to the app title, and couple other projects have gone V1 to V2 that I've seen.

Thanks for your responses and patience.

In my defense these are the data columns upon exporting WU results from Milkyway:

Task/Work unit/Sent/Time reported or deadline/Status/Run time(sec)/CPU time(sec)/Credit/Application

The person that created the data set titles is also guilty of misusing app/app-version. The column heading should read application(version).

This is what I had been looking at, before making my above forum post, as I worked on the results spreadsheet for baseline performance characteristics. (Hence my asking about the truncation of the exported data from that results table).

Seems that's the common reporting headings on standard BOINC server software. Application and version are not differentiated.
Look at this as if you were completely new to BOINC results reporting then came to WUProps and were trying to understand hours reporting after looking at your WU results page and saw the 'application' column. Because the data that is actually being reported in the 'application' column is plan_class, not app.
That kind of error can crash Mars Climate Observers, as imperial units are not metric, and, in this case, confuse newcomers to WUProps.

Would be nice for WUProps if all projects differentiated by major changes in app versioning (as from CPU to GPU implementations)

We never, ever, want to do that unless it's absolutely unavoidable.

Generally, an "App" handles one type of problem. In the example I stated before, that's a PPS-Sieve task. I want the CPU and GPU app versions to be part of the same app because I want interoperability between the different app versions. If person 1 gets task 123456 and runs it on a Windows X64 CPU app version, I want the double check task run by person 2 to be able to be run with a Linux AMD GPU app version. I don't want to have separate task queues for CPUs and GPUs and so forth. We want one task queue (meaning one app), that will run on many different hardware configurations (i.e., app versions.)

What the data collection site WUProp does with the information it gathers is entirely up to WUProp's administrator. He's free to create badges that count app_version hours instead of app hours if he wants to. Just don't expect projects to start breaking up apps because you want more stars. That's very much a case of the tail wagging the dog.

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

Would be nice for WUProps if all projects differentiated by major changes in app versioning (as from CPU to GPU implementations)

We never, ever, want to do that unless it's absolutely unavoidable.

And yet SETI@Home does this. So you are critical of their choices?

What the data collection site WUProp does with the information it gathers is entirely up to WUProp's administrator. He's free to create badges that count app_version hours instead of app hours if he wants to.

That is not what my last post was about. I was stating that most all (except WCG and YoYo to my experience) misreport WU results in their last column as APPLICATION instead of APPLICATION(Version). Primegrid also does this:

Application
Generalized Cullen/Woodall (Sieve) v1.00 <--- this is the application AND versioning not simply the application as you defined.
This is the data column that I was referring to in my very first post that started this entire discussion. That WU result column is mislabeled in the server software; the reported data is app(plan_class), not simply app.
I think counting hours by every version would be a time management disaster for WUProps.

Just don't expect projects to start breaking up apps because you want more stars. That's very much a case of the tail wagging the dog.

Many projects other than yours do break the app by GPU version and CPU version. It's their choice and they may have a different guiding paradigm than yours.

Accusing me of delving into this topic and making suggestions just because of my star count (it's a personal goal, I'll never compete with the top people on here) was inappropriate and incorrect. My curiosity was why I entered a research field years ago and investigation of practices and procedures is an interesting subject.

BTW, if I were such a peacock about badges and stars wouldn't it be a signature in all my forum posts? Unless I missed one, all my sigs in every BOINC forum is empty.

"Generalized Cullen/Woodall (Sieve)" is the app WUProp sees.

The app is in the gray bars. There is no version number in the gray bar. The app is not what is displayed as a task in BM.
https://www.primegrid.com/apps.php

I agree with Michael Goetz.

The app is not what is displayed as a task in BM.

The BOINC Manager displays Application as a column heading above what is clearly app+version+plan class data.

https://i.imgur.com/EsYRozu <--(if IMG tag is not properly displaying, click the link)

"Generalized Cullen/Woodall (Sieve)" is the app WUProp sees.

The app is in the gray bars. There is no version number in the gray bar.

That is not the Application data column being referred to (and this has been stated several times now in the discussion above).
Look at the data column to the far right of your tasks page; this is what you look at to see task results.
This is the area that a user collects data about their project.
They do not use the apps.php page.

https://www.primegrid.com/results.php?hostid=yourid

This is what the end user sees: Generalized Cullen/Woodall (Sieve) v1.00

Or in the case of the original post:

https://i.imgur.com/gJ07eam<--(if IMG tag is not properly displaying, click the link)

This would be the corrected data column heading from which end users collect their data:

https://i.imgur.com/B9SoJXY<--(if IMG tag is not properly displaying, click the link)

The manager is wrong. Your entire argument is based off false info.

https://boinc.berkeley.edu/wiki/Client_configuration

name
short name of the application as found in the corresponding <name>xxxxx</name> tags in your client_state.xml file.
The application name can also be found using the <sched_op_debug> logging flag: a new task shows "Starting task task_name using Application_Name ..."

WUProp Reports the User Friendly Name. There is no version # in it.

From my own client_state file as I am running that very same app

<app>
    <name>gcw_sieve</name>
    <user_friendly_name>[b]Generalized Cullen/Woodall (Sieve)[/b]</user_friendly_name>
    <non_cpu_intensive>0</non_cpu_intensive>
</app>

There is no version # in the app name. I doesn't matter what the user sees. Do not use the apps page? WTF, it clearly states the app name and 1.00 has the version.

The manager is wrong.

You just agreed with my entire argument...
If the manager, which every end user's eyes sees, is wrong, then shouldn't it be corrected?

Your entire argument is based off false info.

If that's what you think, then you need to go back and reread my last post which was about how the BOINC Manager and results page columns are mislabeled leading to confusion for the end user.

Look at the last picture I linked and see the correction made to what the column should read.

I argued the entire time that the column entry on the results page, and then the BOINC manager column entry, was mislabeled. It's confusing to the end user since what they see disagrees with what you and Michael Goetz tell the end users about WUProps.

What I don't understand is how you missed this.

I doesn't matter what the user sees. Do not use the apps page WTF

That is absolutely ridiculous.
The end users are what make BOINC work.
Any time you can reduce their initial confusion reduces the help desk staff work load.
The results page, and the BOINC Manager data tables, are where the end user gets THEIR data about BOINC.

You're the only one confused about the actual app name is, you admitted that earlier. BM/BOINCTasks displays the App name, Version and possible plan_class.

Once you all mentioned 'app version' and 'plan class' my understanding crystallized.

Also if you're going to quote, someone actually quote them character by character. The way you quoted me completely changes the meaning of the sentence.

Your quote:

I doesn't matter what the user sees. Do not use the apps page WTF

What was said:

Do not use the apps page? WTF, it clearly states the app name and 1.00 has the version.

Removing the ? removes me wondering wtf YOU are talking about. The project apps page is the source of the data that the mgr and WUProp can use. Saying it is not correct is the completely wrong thing and you tried to reword my sentence.

The BOINC Mgr code is open source. You're welcome to separate app name, version and plan class into separate columns.
https://boinc.berkeley.edu/trac/wiki/SourceCodeGit

You started up this 2 year old thread with a misunderstanding. Now you're trying to blame it on BM. So go to the BOINC forums and complain there as it has nothing to do with WUProp or MW.

You're the only one confused about the actual app name is, you admitted that earlier. BM/BOINCTasks displays the App name, Version and possible plan_class.

Once you all mentioned 'app version' and 'plan class' my understanding crystallized.

That's a lie. It's clear from the quote you post that I remembered by 31 Mar 2019 how the app naming works and I can read the client_state.xml information to get the app name, plan_class, etc.
Also, there are, and will be plenty of users that have no idea that the results page Application column data won't be what they see at WUProps.

The point of this whole thread is about getting data from the tables provided by the project results page and the BOINC Manager.
The vast majority of BOINC users will not, nor should they need to, delve into the client_state.xml file.

You started up this 2 year old thread

Because it was the right thread for the topic and was the appropriate place to talk about an app that hasn't changed.

Now you're trying to blame it on BM.

YOU pointed out the BM also has the same flaw.

You seem incapable of admitting, or understanding, that the whole thread was about the results data column not reporting the application correctly. This isn't about how it actually works, but the perception of the new users as they first encounter WUProps having almost exclusively looked at results pages and the BOINC Manager.

This absolutely has to do with WUProps because new users to WUProps will be looking at the results of their WU's Application column and have the same question about why it differs from WUProps listings.

So go to the BOINC forums and complain there

It will take more than just a couple of people pointing out the flaw in the Application column to achieve a change by suggestions on their forums.

The BOINC Mgr code is open source. You're welcome to separate app name, version and plan class into separate columns.
https://boinc.berkeley.edu/trac/wiki/SourceCodeGit

That's the most helpful thing you added to this whole conversation.

Also if you're going to quote, someone actually quote them character by character. The way you quoted me completely changes the meaning of the sentence.

Your quote:

I doesn't matter what the user sees. Do not use the apps page WTF

What was said:

Do not use the apps page? WTF, it clearly states the app name and 1.00 has the version.

Removing the ? removes me wondering wtf YOU are talking about. The project apps page is the source of the data that the mgr and WUProp can use. Saying it is not correct is the completely wrong thing and you tried to reword my sentence.

This is a separate issue so it gets a separate response.

The removal of the ?, or addition of WTF, was accidental and did not much change the meaning.

YOU, changed the meaning by leaving off the first sentence and your sentiment in this quote is what angered me.

I doesn't matter what the user sees. Do not use the apps page?

It absolutely matters what the BOINC users see and the apps results page is critical to end user involvement. It's where they get the results of their work. It's ridiculous for you even to suggest this, as I said before.

(It's not shown in the quoted text, but this is referring to changing the column heading on the web page that displays a list of tasks. There's also a portion that refers to the BOINC Manager, but my reply is about the web page only.)

So go to the BOINC forums and complain there

It will take more than just a couple of people pointing out the flaw in the Application column to achieve a change by suggestions on their forums.

You're right about that. Probably you're more correct than you realize. Getting that changed would be extraordinarily difficult.

You want the column heading changed on the BOINC task webpage. Sounds simple enough, right? In fact, it is a trivial change to some text, provided you don't care about localization, e.g., other languages.

The real difficulty, the part that makes this nearly impossible to achieve, is that getting the BOINC developers at Berkeley to make this change is just a small part of the problem. You also have to get every single BOINC webmaster on the planet to make the change to their servers. That's not going to happen.

There's a few webmasters who religiously incorporate every change from Berkeley. They're a small minority. Most webmasters set up their webserver, customize it as needed, and then never upgrade it from the Berkeley repository again. Some will, when needed, apply only those updates they deem essential.

The bottom line is that even if you get Berkeley to make the change, only a handful of existing BOINC servers will incorporate that change into their systems.

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.