finish file present too long

Message boards : Number crunching : finish file present too long
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · Next

AuthorMessage
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744726 - Posted: 25 Nov 2015, 11:28:30 UTC - in response to Message 1744722.  
Last modified: 25 Nov 2015, 11:29:20 UTC

Well a second is practically an eternity in modern processor scheduling. Optimising so as to complete requests in milliseconds on contemporary hardware would be the go (even if challenging). The hardest part would be that bloated simulation for scheduling the tasks, but even then that could be shelled off to a low priority thread leaving the main one high priority and mostly asleep.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744726 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744728 - Posted: 25 Nov 2015, 11:38:43 UTC - in response to Message 1744724.  

And there are two different issues in play, and they've become conflated.

1) The Manager/Client combo takes too long to get it's act together at Windows startup, and displays an error condition (red dot on tray icon) while it does so. If anything, that calls for higher priority (for the obsessives who notice these things) during startup - though a better solution would be a separate indicator to distinguish 'still starting' from 'has failed'. Either way, special startup processes should apply at startup only, not continue for the whole of the next month.

2) Interference between BOINC processes (mainly spawned science apps) and the daily bread-winning tasks of the computer. Smarter (and more graduated) suspend options - especially a choice of "at work" and "idle / away / asleep" settings, including partial suspension of some/all CPUs or GPUs, would be a better route to travel down.
ID: 1744728 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1744729 - Posted: 25 Nov 2015, 11:46:43 UTC

where;s the original request again? I dont think it was the client at all that needed to be better but rather an overcommitent because VMs started by the client proved too much load when the user started his own VMs.

I still think you can handle that problem with exclusive apps ...
A person who won't read has no advantage over one who can't read. (Mark Twain)
ID: 1744729 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744730 - Posted: 25 Nov 2015, 11:48:33 UTC - in response to Message 1744729.  

where;s the original request again?

#1392

Scenario

Usually i have boinc running at max 90% CPU core speed, entering idle mode when my other processes go up 30%. Sometimes, when i'm working with my vm (2 some times) the computer with boinc running gets really sluggish. I noticed that this was mainly because boinc was running applications that made use of vm's too. One time i had 4 vm's running at the same time, which is overkill for my 8GB of RAM, and mainly, the the Main Storage Drive (that couldn't handle all the IO).

Idea

Knowing that boinc starts processes with CPU priority by default:low i don't know if this applies also to IO access priority.

If it does not, it would be of interest to change this.
If it does (most prob.), a mechanism to halt applications consuming absurd amounts of Bus Bandwidth (or all boinc applications) would be very useful, resuming when IO went back to normal.
This would be a mechanism similar to the IDLE/ACTIVE used for CPU usage.
I think that there is no thread like this.
ID: 1744730 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744732 - Posted: 25 Nov 2015, 11:52:07 UTC - in response to Message 1744728.  
Last modified: 25 Nov 2015, 11:52:54 UTC

Yes that's pretty inevitable with the client having adopted the position of being a pseudo mini-OS in itself, assuming control, and fighting with the host for dominance. I've had better success yielding when possible, or quoting Dune "I bend like a reed in the wind". That's poetic language for a sophisticated design thing called "Éngineered camber". It's a lot tougher to do that than it sounds, but makes for extremely robust software :)
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744732 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744735 - Posted: 25 Nov 2015, 11:57:36 UTC - in response to Message 1744732.  

Presumably it involves queuing things which aren't time-critical, and promoting some things which are. The trick is making the decisions quickly enough (while supporting older/slower processors) and getting them right every time - and getting round to everything eventually.
ID: 1744735 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1744737 - Posted: 25 Nov 2015, 12:02:50 UTC

Well that request is very different from what David did!

As I understand it the _app_ was using up too much io and he wanted a mechanism to lower _app_ IO usage (or suspend those apps with a high usage when there is IO contention)

I _still_ think something that makes sure the VM tasks are better behaved is needed.
A person who won't read has no advantage over one who can't read. (Mark Twain)
ID: 1744737 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744739 - Posted: 25 Nov 2015, 12:09:53 UTC - in response to Message 1744735.  

Presumably it involves queuing things which aren't time-critical, and promoting some things which are. The trick is making the decisions quickly enough (while supporting older/slower processors) and getting them right every time - and getting round to everything eventually.


Exactly. Even tighter, marshalling such queues as quickly as possible, then getting right out.

Another way to look at it might be: nothing about the boinc client 'needs' to happen this particular timeslice (unless there are multimedia boinc apps I'm not aware of). Just check the existing queues are proceeding and push a bit more on.

That's a design philosophy it's taken more than ten years for game developers to catch onto, so shouldnt be trivialised'. It does come down to assumptions about how important your work is than mine etc. Not really something I'd expect the client to have enough information on hand to decide. IMO the host and the user can only do that. Linux, Windows and OSX/FreeBSD seem to have differing approaches to scheduling tasks/threads under contention. Using all three I'd suggest none of them is 'ídeal', though all substantially better than 'do this now'
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744739 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744741 - Posted: 25 Nov 2015, 12:14:33 UTC - in response to Message 1744737.  
Last modified: 25 Nov 2015, 12:16:03 UTC

Well that request is very different from what David did!

As I understand it the _app_ was using up too much io and he wanted a mechanism to lower _app_ IO usage (or suspend those apps with a high usage when there is IO contention)

I _still_ think something that makes sure the VM tasks are better behaved is needed.


Yeah VMs are tricky because some systems will have specialised extensions to handle VMs better than others, and some VMs will use those extensions better than others (or not at all).

Throwing VMs into the mix is a bit of a curveball all around, though I'm sure simpler for project devs to release single applications to everyone. It is a big bloated demand on resources, and probably not in line with our efficiency focus at all. Not sure completely where that direction is headed yet. [Seems like an odd choice with the price of energy these days...]
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744741 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744743 - Posted: 25 Nov 2015, 12:24:19 UTC - in response to Message 1744741.  

Isn't there some suggestion that the makers of the specific VM that BOINC has partnered with - Oracle Virtual Box, chosen because it's Open Source - have recently introduced 'security' measures which prevent the host OS fiddling about with things like priorities? I'm going to try and test that this afternoon.
ID: 1744743 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744744 - Posted: 25 Nov 2015, 12:32:42 UTC - in response to Message 1744743.  
Last modified: 25 Nov 2015, 12:57:56 UTC

Isn't there some suggestion that the makers of the specific VM that BOINC has partnered with - Oracle Virtual Box, chosen because it's Open Source - have recently introduced 'security' measures which prevent the host OS fiddling about with things like priorities? I'm going to try and test that this afternoon.


Oh yes that sounds right. That sure sounds like something virtual machine makers might fight about. In this context the makers of the [host] OS, Boinc client, and VM+app are all 'virtual machine makers', and each knows what you want better than the other or what you do.

[Edit:] the LLVM (low level virtual machine) project, which is actually about compilers and machine level optimisation more than what we'd recognise as a VM, threw nvidia for wobblies to such an extent they fielded opinion and switched to it completely for their mainline compiler after Cuda 3.2, I believe there are similar disruptions in the NIX+mac/BSD worlds leading to clang supplating GCC for some things already. [I think MS virtualised things more or less completely from NT onwards, but could easily accept correction on that]...[Original XPDM/XBox/directX was physical hardware bound, but later hybridised to be compatible with Vista+, so I guess displays weren't considered part of the virtual machines until the hardware could cope.]
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744744 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1744766 - Posted: 25 Nov 2015, 14:24:31 UTC - in response to Message 1744728.  

1) The Manager/Client combo takes too long to get its act together at Windows startup, and displays an error condition (red dot on tray icon) while it does so.

Coming back to this, having found a PC with a keyboard to answer as this is undoable on a phone... I don't see why the Manager can't run on a lower than Normal priority, as it doesn't do that much anyway. It shows the messages from the client, and allows you to control the science application & write configuration files. The only reason why you want to keep the manager at Normal priority is for this OS start-up scenario where it otherwise can take several minutes before the manager makes contact with the client.

You wouldn't want the client to run on the lower priority due to it possibly giving the error in the thread title. But has anyone tried a client at Lower than Normal instead? The same priority that the GPU apps (and VMs?) run at?
ID: 1744766 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744767 - Posted: 25 Nov 2015, 14:31:06 UTC - in response to Message 1744766.  

The general unintuitive gist is that if you don't 'do much'then runnign at a high priority is just fine, such that you get served and are out of the way. I only say unintuitive since I have a lot of experience dealing with long involved processes and telling others to rack off. Short and sweet requests merit prompt service and efficient delivery.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744767 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744774 - Posted: 25 Nov 2015, 14:50:07 UTC - in response to Message 1744767.  

The general unintuitive gist is that if you don't 'do much'then runnign at a high priority is just fine, such that you get served and are out of the way. I only say unintuitive since I have a lot of experience dealing with long involved processes and telling others to rack off. Short and sweet requests merit prompt service and efficient delivery.

Confirmed. I do exactly this with one of the Einstein apps for intel_gpu. That uses very little CPU support, but when it wants it, boy does it want it fast. So I run the app at real-time priority - yes, High isn't enough - with no apparent detriment to the UI except a barely-noticeable stutter every 8 hours or so when one task finishes and another takes over.
ID: 1744774 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1744777 - Posted: 25 Nov 2015, 14:57:34 UTC - in response to Message 1744767.  

Okay, other question then. Do we know at what priority (if any) RPCs run at?
ID: 1744777 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744779 - Posted: 25 Nov 2015, 15:03:18 UTC - in response to Message 1744777.  

Okay, other question then. Do we know at what priority (if any) RPCs run at?


basically whatever the client is assigned, but since by default a boinc enabled system is in a state of overcommit, something lower determined by the host/OS.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744779 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744783 - Posted: 25 Nov 2015, 15:05:24 UTC - in response to Message 1744777.  

Okay, other question then. Do we know at what priority (if any) RPCs run at?

Well, an RPC is a two-part process. Either the Manager calls, and the client replies: or the client calls, and the project server replies. Here, we're mainly concerned with the client, which might be either calling or replying depending on which type of RPC we're talking about.

I don't know for certain which of the client's threads handles it, but I'd guess the most active one. So the priority would be base 8 / boost 10 (for clients running at normal priority), or base 4 / boost 6 for the clients with David's reduction strategy in operation.
ID: 1744783 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744792 - Posted: 25 Nov 2015, 15:23:42 UTC - in response to Message 1744783.  

maybe oddly, the higher priority client seems the best for our purposes so far. That's on the proviso the client does things quickly/efficiently. Maybe there is still a place for optimisation in this world after all.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744792 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1744793 - Posted: 25 Nov 2015, 15:23:46 UTC
Last modified: 25 Nov 2015, 16:22:37 UTC

OK, I've set two VBox experiments running, both using the CERN CMS-dev virtual machines.

The first uses VBox version 5.0.2 with CMS-dev's current BOINC wrapper (26178): the second uses VBox 4.3.26, with the latest BOINC wrapper v26179. Both are running under BOINC v7.6.16, which is running in David's background mode.

The first has been running for long enough to get through all its startup phases, and has settled down to the usual "one full CPU core" running mode. The BOINC Wrapper is running at 'Low' priority (like any normal BOINC CPU app), but VBox(headless) is running at Normal priority. I can see no sign at all that either the Wrapper or VBox is running any of their various threads at anything other than Normal memory and IO priority.

The second hasn't got up to speed yet, but I should be able to perform the same checks while I can still edit this post.

Edit 1: it took bloody ages for the Wrapper to start up - about 4 minutes for the Client to copy 1.4 GB at minimal IO priority.

Edit 2: That took bloody hours, but I got there.


cmsRun is the key one.

Same result as test 1 - Wrapper running low priority, VBoxheadless running normal, all threads memory and IO at normal priority.
ID: 1744793 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1744794 - Posted: 25 Nov 2015, 15:32:16 UTC - in response to Message 1744793.  
Last modified: 25 Nov 2015, 15:32:30 UTC

I don't know what'that means, but it sounds cool and I eagerly await results.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1744794 · Report as offensive
Previous · 1 · 2 · 3 · 4 · Next

Message boards : Number crunching : finish file present too long


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.