CPU Killer would increase the CPU temperature.mf wrote:I wonder what CPU Killer was made for, then...crappish wrote:Eh? Nobody wants to limit the CPU speed...
Processor Scheduling
Moderator: Moderator Team
-
AcetoliNe
- Posts: 115
- Joined: Wed Jan 05, 2005 10:53 pm
- Location: a thousand miles from Hinterland
- Contact:
I don't really think the processor scheduler in windows in inefficient. In my opinion, it does the job well.
Lengthening the processor quota to increase performance sounds logical, but you must realize that it only takes up a very small fraction of overall time.
A user-configurable scheduling system would be a very good idea, in my opinion.
I would really appreciate some factual numbers on this.
Lengthening the processor quota to increase performance sounds logical, but you must realize that it only takes up a very small fraction of overall time.
A user-configurable scheduling system would be a very good idea, in my opinion.
I would really appreciate some factual numbers on this.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.
we shall reinvent the wheel until it turns properly.
I was talking about the thread in question.mf wrote:I wonder what CPU Killer was made for, then...crappish wrote:Eh? Nobody wants to limit the CPU speed...
Can't provoke anyone? Why bother posting?
slowing CPU is only a solution for DOS programs to run on the OS like SlowDown. it works different from that what I meant, because it USES the cpu heavily
what i wanted is good to mention in an example
there is a well known game called Ultima Online. The client from UO runs on any windows platform, needs low performance to run and so on. but it uses 100% CPU time. even on faster machines, you see the problem: on a 3200 machine 100% cpu is more power and heat, as on 500MHz... and no matter which "Threading Priority" it gets, because THREAD PRIORITY helps only in two situations: * some progs need to run besides to some CPU eating one without blocking each other, * some process needs to run in realtime or higher prio.
it doesnt help if you run ONE prog, which is eating all the CPU away for no reason. then you would have to limit cpu time. it doesnt get a "lower priority", instead the application gets only "certain amount of threadcycles". so it has no matter how much apps are running beside it, the one prog always just get its piece of cake.
if some readers are still not following, a last example: if you have a piece of cake and want to divide it between 4 persons, but one person insist getting half of the cake others get, so you use percentages. 3 persons get 87% percent of the cake thru 3, while one gets 12,5%. still depending on the cake size, this can be a lot or not as much. thats thread priority. if all are eating as much as they can, they get percentages.
different from absolute numbers, or something similar: if one person has diabetes, he wont get more than 50g of cake. if the percentage he would get is above 50g, he only gets his 50g of cake, nothing more. this is time limiting. his threading cycles are bound to 50 cycles, no matter how many are maximum.
this would also solve issue one, where some programs are crashing if they get too much cpu time at once, like old dos progs.
what i wanted is good to mention in an example
there is a well known game called Ultima Online. The client from UO runs on any windows platform, needs low performance to run and so on. but it uses 100% CPU time. even on faster machines, you see the problem: on a 3200 machine 100% cpu is more power and heat, as on 500MHz... and no matter which "Threading Priority" it gets, because THREAD PRIORITY helps only in two situations: * some progs need to run besides to some CPU eating one without blocking each other, * some process needs to run in realtime or higher prio.
it doesnt help if you run ONE prog, which is eating all the CPU away for no reason. then you would have to limit cpu time. it doesnt get a "lower priority", instead the application gets only "certain amount of threadcycles". so it has no matter how much apps are running beside it, the one prog always just get its piece of cake.
if some readers are still not following, a last example: if you have a piece of cake and want to divide it between 4 persons, but one person insist getting half of the cake others get, so you use percentages. 3 persons get 87% percent of the cake thru 3, while one gets 12,5%. still depending on the cake size, this can be a lot or not as much. thats thread priority. if all are eating as much as they can, they get percentages.
different from absolute numbers, or something similar: if one person has diabetes, he wont get more than 50g of cake. if the percentage he would get is above 50g, he only gets his 50g of cake, nothing more. this is time limiting. his threading cycles are bound to 50 cycles, no matter how many are maximum.
this would also solve issue one, where some programs are crashing if they get too much cpu time at once, like old dos progs.
A user configurable system would be perfect, especially if it can be set to extremes in either direction and is easily accessable from a menu setting (not in the registry).A user-configurable scheduling system would be a very good idea, in my opinion.
Actually so would I.I would really appreciate some factual numbers on this.
EDIT: I just remembered that one of the main reasons I suggested this in the first place is that some people have reported sizeable performance increases after setting the scheduler to the backround setting (long, fixed threads) from Programs (Short, Variable) threads.
I intend to test this, can anyone reccommend a program?
-
Alex_Ionescu
- Developer
- Posts: 34
- Joined: Thu Apr 07, 2005 12:49 am
There's absolutely nothing wrong with the scheduler, especially in the newer one used in 5.1+. The thread quantum were specifically selected for workstations and servers and act differently. There are also dynamic quanta which are sometimes applied depending on PriotitySeparation, so some threads will even have quantas of 18 or more. (Up to 6*<thread quantum base>), resulting in 36. Unlike the pathetic *x schedulers which heck, didn't even use threads until now, I think the VMS design is much better.
To answer your question, ours works completely different. It didn't even support quanta until recently, and even now the support is shaky. It doesn't support priority boosting fully, doesn't actually schedule threads, and has some really weird idle thread functionality. It also doesn't support pre-emption and it's really really slow. I have been working on fixing these issues and creating a more NT-like Scheduler, while also trying to avoid some of the bloat that it has. We've actually spent 2 weeks optimizing a single operation (which we'll actually do faster then XP, but in 2003 MS used our trick too).
Best regards,
Alex Ionescu
Kernel Developer, ReactOS
To answer your question, ours works completely different. It didn't even support quanta until recently, and even now the support is shaky. It doesn't support priority boosting fully, doesn't actually schedule threads, and has some really weird idle thread functionality. It also doesn't support pre-emption and it's really really slow. I have been working on fixing these issues and creating a more NT-like Scheduler, while also trying to avoid some of the bloat that it has. We've actually spent 2 weeks optimizing a single operation (which we'll actually do faster then XP, but in 2003 MS used our trick too).
Best regards,
Alex Ionescu
Kernel Developer, ReactOS
Who is online
Users browsing this forum: No registered users and 20 guests