Bright idea #1 wrote:

It would be nice to be able to see the total number of local tasks for each project, on the "projects" tab of the boinc manager, instead of having to log into my account.

In theory this could reduce data driven web page traffic slightly, if implemented.


Bright idea #2 wrote:

Make full st_derr.txt output visible under "properties" for completed and error tasks that have been uploaded but not yet reported to the project server

I have had to hit the update button too many times for no other reason then to be able to see the error report immediately.
While I'm sure I could go into the project folder and read the data there, it is difficult to locate amongst 1000 tasks.

MOD: please do not lock this thread after reply, I have some other ideas but have yet to figure out the best way to suggest them.

Before someone else hollers at you, you may want to suggest your ideas for BOINC on the BOINC Message boards. Keep in mind that with any suggestions you make for BOINC, that the idea must make sense across the scope of projects BOINC supports and not just SETI@Home.

Personally, I think I like your first "Bright idea" and see no reason why BOINC cannot count how many tasks are local on the system and display that number somewhere, perhaps in the Projects tab and/or the Disk Usage tab.

Before someone else hollers at you, you may want to suggest your ideas for BOINC on the BOINC Message boards. Keep in mind that with any suggestions you make for BOINC, that the idea must make sense across the scope of projects BOINC supports and not just SETI@Home.

bright idea #2 would be a seti@home related I'd think ... is the verbosity of the output from st_derr.txt, between upload and reporting a boinc issue or SAH?

I cant look as I have no other projects 'running' currently (nor any past errors for them for that matter)

I will use this thread as a sounding board that I might make a more informed suggestion on the boinc forums

It is up to the project to decide what files/information get reported back to the project, and I think data size has a lot to do with the decision. I think SETI@Home has just the right amount of data returned so that the Project Administrators know what happened with the workunit in case of errors, otherwise all signal information is returned and stored.

It is up to the project to decide what files/information get reported back to the project, and I think data size has a lot to do with the decision. I think SETI@Home has just the right amount of data returned so that the Project Administrators know what happened with the workunit in case of errors, otherwise all signal information is returned and stored.

um.. did you read the suggestion?

It was referring to the amount of data displayed in the task's properties prior to being reported to the project. if you look at an error task that has been completed but not yet been reported, you will see only the basic file info. No error data or scientific data is viewable.
The information is present/available in the st_derr.txt output if your willing to seek it out, just not displayed under properties ,where I feel it would be useful for diagnosing error problems as soon as they occur.

The question posed by this was : is it a boinc or SAH concern?



*me takes away volunteer testers balloon popping pin

The question is, why do you think every response is targeted at "popping your balloon?" If you wish to sell your ideas, perhaps you should engage people in discussion without attacking them. It reflects poorly upon you.

There's no need to be a jackass toward someone who obviously misunderstood the suggestion. Have fun looking for feedback.

Now who's "hearing" things that are not stated ?

Attack ? I don't think so

This is a quest for information , not trying to "sell" anything
you posted an incorrect response to the thread ,I tried to set you back on track.
Forgive me if I stepped on your toes ,I have ridiculously big feet.

For "idea #1" you may want to get BoincTasks:
http://www.efmer.eu/boinc/boinc_tasks/

Screenshots:
http://prikachi.com/gallery_view.php?user=18390&gal=11810


For "idea #2" I don't know easy way to view stderr.txt "for completed tasks that have been uploaded but not yet reported"
(I'm using also BoincMonitor (from BoincTasks install dir) and BoincLogX - shows part of stderr.txt, saves more in boinc.csv)

* for running (started) tasks the stderr.txt is in 'slots' sub-dirs 0, 1, ...

* to check manually stderr.txt for completed tasks that have been uploaded but not yet reported:
- Copy client_state.xml somewhere and play with this copy
- search for <stderr_txt> (e.g. Ctrl+F in Notepad)

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Attack ? I don't think so

Then don't ask if I even read the suggestion, because that is quite insulting. I did read the suggestion but obviously misunderstood it.

not trying to "sell" anything

Any idea you try to suggest, you are in fact trying to sell the idea to others. This is the way the information world works. If those in charge of writing the code don't agree with you, how else do you convince them other than to sell the benefits of the idea to them?

you posted an incorrect response to the thread ,I tried to set you back on track.
Forgive me if I stepped on your toes ,I have ridiculously big feet.

You could have done it much differently, for example say, "No, that's not what I meant. Here's what I meant..." An incorrect response obviously shows a misunderstanding, and that is an opportunity for you to help them understand.

I wouldn't worry so much about your big toes as I would your quick fingers.

On my computer, SETI causes the GPU to overheat and make display errors. Although BOINC allows a user to limit percentage of CPU cycles consumed, the only limitation that can be applied to the GPU is allowing it to be used only when the computer is not being explicitly used by a user. This means that I must watch the temperature of the GPU, then suspend SETI when the temperature gets too high, then enable it when the temperature drops.

Recommendation: incorporate some method of limiting GPU use in BOINC.

Recommendation: incorporate some method of limiting GPU use in BOINC.

Already there, through the normal CPU throttle function of "Use at most X% CPU time". Since the GPU is being fed by the CPU, throttling the CPU will in effect throttle the GPU.

And if that's not to your liking, then use a third party app like TTrottle which can do more.

---

What would be really great is if there was a diagnostic function that would tell me why units aren't being processed - the server is down, it can't find the server(ie maybe something wrong with my network), I've done something stupid with my settings, etc. There have been so many times where I look at complete units that aren't sent or (as is happening right now) nothing being processed because it can't seem to get any more units.

What would be really great is if there was a diagnostic function that would tell me....

Press CTRL+SHIFT+E simultaneously. That opens the Event Log with messages.
Can also be found at Advanced->Event Log.

By adding client configuration flags you can increase the amount of information that BOINC returns.

---