The intention of this thread is to brainstorm and not to harp on weaknesses, but to suggest improvements. Basically, things that you would like to see so for those who are programming this might take some ideas and incorporate them.

The idea I had was with how many work units it will download for the queue. For me, I set it at connect every 10 days and it will only download about 1 day or 1.5 days of work. Obviously, it would be nice to have a healthy queue going into the Wednesday maintenence or during any outage. The argument for the lack of queue has been "well, if it downloaded all your other projects into the queue, then you would miss several deadlines."

Solutions:
1: multipliers/divisors for the number of projects that you are attached too.

2: multipliers/divisors for the %resources you have assigned to a project. For example, I set SETI at 90% and LHC at 10% so I would get 90% of a seti only queue.

3: update actually, update the queue so I could update tuesday night.

4: Auto update queues before scheduled outages which would be attached to the preferences for the individual projects.

I think some of these could help lower complaints and actually lower sever overloads on reboots from maintenence. Of course, a better scheduling system might be ideal for that, but this would help.

---

TEAM
LL

Would this be new ideas since the last thread like this (3/4 months ago) or do you want all ideas irrespective? Also I presume you are talking seti now and not boinc? If its boinc you need to add a thread like this to the boinc forum...which actually has this I see.

---

Running boinc.exe & boincmgr.exe @ LOW cpu priority (which it seems that Trux has hit on in his latest models of these programs, @ least for boinc.exe & I start boincmgr.exe @ LOW cpu priority here via a .cmd file with the start /low commandline in it)...

That's so the actual "WorkHorse" program in this suite that does the actual crunching (SETI 4.x) has access to (potentially/in theory @ the VERY LEAST) more CPU megacycles...

LASTLY, that stated on my last note to run boincmgr.exe & boinc.exe @ LOW cpu priority?

I still think running SETI 4.x @ HIGH cpu priority would help as well!

Especially for someone who runs this project the way I do (mostly when I am @ work or sleeping, leaving ONLY the seti 4.x process & its mgt. portions in boinc.exe + boincmgr.exe as the LAST ring3/rpl3/usermode apps left running, with a bare minimum of services needed to keep the OS itself up, & NO backgrounded other apps or services!).

Offering a commandline paramstr (or gui configuration option in boincmgr.exe, or a rightclick WORK tab popup menu options for the running processes for HIGH cpu priority would be an improvement), not just (as iirc, Trux DOES offer via his remotehosts.cfg file which I admittedly have not used or understand fully) via a config file!

Point-N-Click GUI convenience for this, OR a commandline parameter string one can use in a .bat or .cmd file (as I do to start boincmgr.exe @ LOW cpu priority)...

e.g.-> start /low boincmgr.exe HIGH

(At the tail-end of that .cmd/.bat file commandline, just insert HIGH here as a paramstr to start SETI 4.x @ HIGH cpu priority, or NORMAL, or LOW as you the end-user see fit)...

People, not a doubt in my mind @ least - this is flexibility & a good feature-add for this project's mgt. portions in boincmgr.exe or boinc.exe (whichever one starts up the workhorse, seti 4.x).

I.E. -> By having boinc portions do their CreateProcess/NtCreateProcess code use the parameter switch for that... it is doable, & easy in fact, when boincmgr.exe (or boinc.exe, whichever one actually starts seti 4.x) kicks up seti 4.x!

E.G.-> Here, I cut my system down to an ABSOLUTE minimum of processes running by knocking out trayicon & other background operating apps, services (trimmed to bare bones minimum here) & even stopping explorer.exe shell (your desktop &/or taskbar)...

This type of "radical surgery" trimming setup MASSIVELY opened up CPU megacycles, not just potentially/in theory either, for SETI 4.x (the actual program workhorse here that processes the UNIT data) to grab up via running @ HIGH cpu priority!

Not a doubt about it in my mind @ least...

(However/admittedly - I have no "hard numbers" gained via tests running SETI 4.x @ HIGH cpu priority to offer either! BUT, conversely, neither does anyone else that I have that says running SETI 4.x @ HIGH cpu priority harms it processing faster, since none I have heard who say that has setup their system in a "radical configuration" of process trimming as I do for this project while it runs while I am @ work, or sleeping!)

APK

P.S.=> I've "nagged" Trux here about this, & he is unwilling to do that, & in a way?

I don't blame him - features (newly added ones) CAN potentially introduce bugs via such 'feature-creep', but I know it can be done & imo, effectively, just by how I do it here & it works very well...

I see no lockups of the rest of my system (lol, what's left of it running that is via my 'radical surgery' setup noted above), & smooth running of my SETI processing by running boinc.exe + boincmgr.exe @ LOW cpu priority, but MANUALLY having to set my SETI 4.x to HIGH CPU priority via CTRL+ALT+DEL summoning of taskmgr.exe to do it for me (when I can & am here to oversee it, which is not possible while I sleep or work... this feature add would do it for me)...

I also saw folks say "realtime priority settings locks up my system" & that's NOT totally true - everything's still running, but your GUI becomes unresponsive...

e.g. -. Experimenting myself coding, I've coded apps that do that running themselves @ REALTIME CPU PRIORITY, & omitted timeslicing calls in their loop code especially (e.g.-> VB DoEvents, Win32 API sleep calls, or Delphi Application.ProcessMessages) & got that 'bad effect'! I could not even move their screen around via grabbing it on its titlebar with my mouse... not a good move, it stalled my ability to interact with the app itself.

HOWEVER, the apps themselves & all else, were STILL running in their loops doing their work but hogging SO MUCH CPU, it made all else appear to be stalled, which isn't totally true, just their GUI repsonse!

Do I recommend REALTIME?

No!

(As it stalls your ability to interact with your apps & especially if an app set to run REALTIME CPU PRIORITY processes a lot of work in loops... I wouldn't even recommend it the way I have things here setup)

However, again, using HIGH cpu priority for seti 4.x, @ least as an option via the GUI configurations for it, a commandline paramstr for boincmgr.exe, or rightclick WORK tab process' running via popup menus with CPU priority control?

That I do recommend it as an OPTION... it does work here, w/out stalling out the ability to interact with all else here... apk

---

http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"

The intention of this thread is to brainstorm and not to harp on weaknesses, but to suggest improvements.

Here's one - I'd like to see the assigned WUID (instead of just the WU Name) in the Work tab of BOINCMGR. Would aid in troubleshooting (looking up a particular WU) and comparing results.

---

.

Maybe I should take this to the boinc board, but i'm particulary concerned with SETI myself. If you know the link to where I should look to find the threads that you're refering to, I'd add to those.

---

TEAM
LL

Maybe I should take this to the boinc board, but i'm particulary concerned with SETI myself. If you know the link to where I should look to find the threads that you're refering to, I'd add to those.

Here you go. http://boinc.berkeley.edu/dev/forum_index.php

---

I intende a specific thread. I can find my way to the forums. LOL

---

TEAM
LL

I intende a specific thread. I can find my way to the forums. LOL

Go there and sign up to join that forum...for boinc. Its well worth it.
Ah drop the forum_index.php bit at the end sorry

edit: and the dev bit too lol

---

Hiya. :)

Found your thread.
In a similar vein, I've started a thread more specifically for those who take the time to connect via DIAL-UP.

There are, you can imagine, other concerns for efficiency and speed etc with regards to uploads and downloads especially, and I thought it would be good to give DU users a space to express their concerns, or air their ideas, specifically related to experiences they've had with BOINC over dial-up.

Even though Broadband is on the rise, many are still out there contributing their time and computing cycles, but only managing to connect via dial-up, so this "demographic" (sorry!) definitely needs to be heard. =)

It's only just started, but THANKS to all who contribute!

Here: http://setiathome.berkeley.edu/forum_thread.php?id=26805

Kind Regards,

.Cx.

Speaking for the "underdogs" of the crunching world... those with only one computer, and nowhere near the millions of credits others claim..!

---

Here's one - I'd like to see the assigned WUID (instead of just the WU Name) in the Work tab of BOINCMGR. Would aid in troubleshooting (looking up a particular WU) and comparing results.

this is discussed in more detail in this thread
I think it would be better to have the result ID thou, as it would make things easier (can get to the WU page easilly from the result ID page, and can see your specific result quicker, rather than having to find out which is yours from the WU page)