-- [ Picked text/plain from multipart/alternative ] I think you're both coming at it from opposite angles and depends what you are looking at. For example because of the way srcds has changed (until its fixed), it _may_ take 100%, however thats a specific case. If you take a game without that issue and a fixed tic it would use less than that. So a fair amount depends on the game/app as well, there isn't really any rule that covers all.
I still go with my earlier comments though its better to reduce the nice priority (positively) of those apps u don't consider important rather than to negatively nice the processes you prefer. 2 ways to skin a cat or something. Ultimately at this moment in time, you _won't_ get the nice issue if you use increase the value of those processes you deem less valuable, rather than reducing the nice value of those you do. On 4/21/06, Matt Judge <[EMAIL PROTECTED]> wrote: > > John Sheu wrote: > >> Imagine a scenario of an ideal system, with nothing else running and, > no > >> overheads for swapping processes. You have 1 high CPU-bound process(a) > >> utilising 70% of the CPU time slices/s. It is happy using the CPU > >> without any interruptions from any other processes. (re)nicing it will > >> not make it run any faster or slower as there is no other processes to > >> share the CPU time slices. In this scenario, there is no point to > >> renicing the process as there is nothing else to share the CPU time > with. > >> > > > > Under this ideal system, with one CPU-bound process, it would monopolize > > the processor, i.e. 100% utilization. The only reason why such a single > > process would _not_ use 100% CPU is if the thread were blocking on > > something else, e.g. I/O requests or sleeping. > > > I guess you are trying to be a pedant here. Or I over simplified my > explanation. Expanding on your view point, my CPU utilisation would be > 100% all the time, distributed between all the processes currently > running. Guess what? it isn't. Go and learn about kernel scheduling. > > I did try replying to the rest of your email, but it was patently clear > that trying to explain how Unix type operating systems work would be > clearly beyond you, so I gave up. All the answers are in my previous > post, please read it and be enlightened. > > Matt. > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
