Bill2's Process Manager : le forum

Bill2's Process Manager, Votre gestionnaire de processus automatique
 
AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  GroupesGroupes  Connexion  

Partagez | 
 

 Metrics might be nice

Voir le sujet précédent Voir le sujet suivant Aller en bas 
AuteurMessage
MarkShot
Supporter
Supporter


Nombre de messages : 28
Date d'inscription : 21/05/2008

MessageSujet: Metrics might be nice   Jeu 22 Mai - 1:02

The whole point of PM is that of load balancing manually, since XP/Vista don't know how to do that. You are looking to achieve one or both of the following:

(1) Increased work load - meaning have your PC accomplish more work per unit time.

(2) Improved responsiveness - meaning your PC responds more quickly to whatever your request from it.

So, I am thinking some basic metrics would allow users to:

(1) Measure if using PM has resulted in an improvement.

(2) Allow different rule sets (groups) to be compared for their effectiveness.

In my case, over the course of a X number of hours, I would like to know the average total CPU (sum of individual processors) utilization. The higher I manage to raise this number on the average, the more work my PC is doing and ideally the better the response time. Of course, one problem with this simple metric is except for when playing intensive compute video games, the system is often largely idle. Thus, comparisons of different profiles might not yield very significant differences. Perhaps, more interesting might simply the total number of CPU cycles expended during X hours. However, that still doesn't measure if the system has become more responsive, but it does indicate that more work was done (assuming no thrashing).

For responsiveness, the metric should only be taken during times of heavy load. For example, perhaps measuring the total number of minutes over time that each processor exceeded 80% utilization. Effectively, the longer the amount of time that processors are at 80% or greater, the more frequently that CPU starvation is taking place and the user is waiting on the PC. A poor load balancing would frequently see processors running at very high utilization

...

Okay, maybe the above is still too simplistic. Maybe what needs to be measured is whenever a processor is at 100% and that 100% is composed of more than a single process. Assuming there is a free processor in such occassions, then the load balancing is off. Since one processor is maxed out while another could be used to service additional work.

...

Well, I think you get my point. Some form of metrics would be nice to demonstrate that PM really does make a difference and to help the user tune his/her machine.

---

Additionally, this suggests another new feature. Currently, you have implemented process priority demotion when a process is hogging the CPU (absorbing the entire available cycles). What might be interesting is dynamically changing the affinity of such processes to another processor which is idle. Ideally, this is what XP and Vista should be doing, but they do not. They should move processes across processors to minimize wait time for CPU resources. Instead once an application has been assigned to a given processor, it remains there despite the availability of additional CPU cycles elsewhere.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Bill2
Administrateur
Administrateur
avatar

Nombre de messages : 418
Age : 39
Localisation : Dijon
Date d'inscription : 21/11/2006

MessageSujet: Re: Metrics might be nice   Jeu 22 Mai - 20:03

Oh!!!
What a big, big post !

Well, despite the fact that my soft may be the best in his category, and have unique functions like handling minimized Windows or distribute each instances of a process on different "autorized" CPU, I know that statistics features are really missing

(Hum, a very big sentence, I'm not sure it's understandable ...)

In fact, the problem is in the .Net Framework itself : there are no functions to know time used on each CPU.
All you can have, is the total CPU time used for each process, but without the details about each CPU.
For exemple, if a process run on CPU 1 and 2, I can't know if it use 25% of CPU1 and 25% of CPU, all I know is this process is user 50% of the whole processor.

So, I know the functions you mention are missing, but at this time, I can't implement them "natively". I have to look into windows API, but I don't have a great knowledge of them Crying or Very sad

What is possible "quite easily", is having a list of how many processes are autorized to run on each CPU, based on current running processes.

An little exemple with two process.
You create rules for two process :
- Process A, autorized on CPU1
- Process B : autorized on CPU+CPU2

I can generate a list :
CPU1 : 1 process autorized
CPU2 : 2 process autorized

This can help to have a better manual balancing.

BUT, the problem is you don't use you computer identically each day.
So a repartition will be OK on monday, and can be worse on tuesday.


What I recommand is simple : put on the same CPU the soft you don't use at the same time!
For exemple, you can put all your games on CPU2, because you can use only one game at the same moment.
And on this CPU, you can also put enconding softs, if you don't encode during games king


I think your current repartition (seen on the forum you mention) is really good.

And I kown my soft lacks stats functions, but such features are really very hard to implement in .Net.

However, I plan to do something to compensate for this issue.


Now, about you suggestion feature (dynamic affintiy changing).

I've done tests, with Celestia (Yes, I love this soft !)
Windows use dynamic repartition!

If you launch two Celestia processes on CPU1, and then autorize one instance to use CPU1+2, then each instance will use 100% of one CPU.
Then if you close the "first" celestia, then Window will "switch" the second Celestia from CPU2 to CPU1 (because the process can use the two CPU, but Celestia isn't multithreaded.)

Because my soft "force" affinity on one CPU (generally), Windows management is not applied. And it is what my soft is done for!

Dynamically change affinity require to know what CPU is overloaded, and Is I mention is an other message, the .Net Framework does't have functions to compute those informations.

What you can do is a little bit far-fetched:
Create all rules using only 3 CPU, but allow certains "big CPU consumming" programs to use CPU4 if necessary.
As you have associated CPU4 with games, it will be a good deal to test.
With this repartition, if 2 processes use to much CPU, Windows will be autorized to "put" them on CPU4 "dynamically".

This way, you can use integrated windows management - that is not so bad in fact - and have the ability to "manually" manage you processes using Bill2's Process Manager.

Does my suggestion sounds good to you? Rolling Eyes Wink

_________________
Rubik's Addicted !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://www.bill2-software.com/processmanager
MarkShot
Supporter
Supporter


Nombre de messages : 28
Date d'inscription : 21/05/2008

MessageSujet: Re: Metrics might be nice   Jeu 22 Mai - 22:47

Yes, I understand. Your proposal is having a designated overflow processor when the workload exceeds the pre-assigned processors. That seems like a good idea.

In another thread, I mention marketting BPM. Another issue to consider is that the window for BPM as product is limited. Sooner or later, maybe with Windows 7, Microsoft will do a better job with OS scheduling. In the meantime, software will head towards being more and more multi-threaded. The problem I see now is that many things are multi-threaded, but not such that the threads are really balanced in any intelligent way. Thus, if you have three threads, then one thread end up doing 90% of the work. The preformance gain is rather limited in such cases. However, eventually compilers/linkers/schedulers/hardware will all come together to support highly parallel operations. At that point, there will be no need for a BPM. In fact, a BPM will actually make a users machine perform worse. It will be like using a memory manager these days that flushes everything from memory and ends up forcing lots more disk access in the apparent quest of improving performance by increasing physical memory available! Smile

Take care.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
MarkShot
Supporter
Supporter


Nombre de messages : 28
Date d'inscription : 21/05/2008

MessageSujet: Re: Metrics might be nice   Ven 23 Mai - 1:17

Yes, I understand. Your proposal is having a designated overflow processor when the workload exceeds the pre-assigned processors. That seems like a good idea.

In another thread, I mention marketting BPM. Another issue to consider is that the window for BPM as product is limited. Sooner or later, maybe with Windows 7, Microsoft will do a better job with OS scheduling. In the meantime, software will head towards being more and more multi-threaded. The problem I see now is that many things are multi-threaded, but not such that the threads are really balanced in any intelligent way. Thus, if you have three threads, then one thread end up doing 90% of the work. The preformance gain is rather limited in such cases. However, eventually compilers/linkers/schedulers/hardware will all come together to support highly parallel operations. At that point, there will be no need for a BPM. In fact, a BPM will actually make a users machine perform worse. It will be like using a memory manager these days that flushes everything from memory and ends up forcing lots more disk access in the apparent quest of improving performance by increasing physical memory available! Smile

Take care.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Bill2
Administrateur
Administrateur
avatar

Nombre de messages : 418
Age : 39
Localisation : Dijon
Date d'inscription : 21/11/2006

MessageSujet: Re: Metrics might be nice   Ven 23 Mai - 6:33

Well, ever ig the windows scheduler is better with a new version, it will always be interesting to manage affinity "manually" to force application on a certain CPU.

We just have to wait for Seven to be out Cool

_________________
Rubik's Addicted !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://www.bill2-software.com/processmanager
Contenu sponsorisé




MessageSujet: Re: Metrics might be nice   

Revenir en haut Aller en bas
 
Metrics might be nice
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» Leurs chiens meurent pendant la traversée Nice-Calvi
» Scott 17 mois croisé teckel/papillon (06) Nice
» Bérénice - Faris
» Voir Nice Sous la Pluie
» Paris-Nice (PT) >>> Avant mardi 16h00

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
Bill2's Process Manager : le forum :: Suggestion de fonctionnalités-
Sauter vers: