Using Obrut to simulate a busy workstation under VMWare 4.0 and need insight under what conditions Obrut releases resources as more VMs are added to a server. How is this impacted by VMware or Obrut settings? Anyone else using this to test CPU performance? Thanks

Obrut is quite abusive to the system, as per the design! When using the "PMem" setting it will take and keep the memory by constantly using it, and thus preventing Windows from paging it out.

I haven't tested this via VMWare for a while, and I can't remember what version I used last. But I just tested Obrut on my 4 GB Core Duo running Windows 7 and it succeeded in causing a near system lockup; I had running Process Explorer and it stopped updating the screen. The mouse was still active though so I could press the "Stop" button and a few seconds after the system returned to me.

However please note that since Obrut is a 32 bit program you'll need a few copies of it to fully abuse any system with more than 2 GB or RAM. I had one copy with CPU A on 800/Most and CPU B on 400/Most as well as 1500 MBytes allocated in "PMem", and two other copies with just 1500 MBytes allocated in "PMem". The system was quite tolerant (but certainly not happy!) until I pushed the load beyond the actual RAM. (As a FYI using "VMem" results in the Commit going up, but very little else changes.)

But to answer your question, Obrut is designed to not release memory at all if using the "PMem" setting, and will be accommodating or aggressive with CPU resources depending on what you set the load as. (The CPU load is a combination of "work" time and a selectable "sleep" period.)

We are using "5000,Most" for both CPU A and B and find that we do not have much of a release on CPU resources as we add multiple VMs running Obrut. I notice you are using levels like 800, 1500 etc. What is the difference do 800, 1000, 3000, 5000 make on the CPU consumption algortihm?

gigabob wrote:We are using "5000,Most" for both CPU A and B and find that we do not have much of a release on CPU resources as we add multiple VMs running Obrut. I notice you are using levels like 800, 1500 etc. What is the difference do 800, 1000, 3000, 5000 make on the CPU consumption algortihm?

So you want Obrut to be less demanding under different external circumstances by, for example, monitoring CPU usage? If so sorry, Obrut isn't designed to do that (adding it is a possibility), it's more for creating consistent loads. If not, may I ask what you want Obrut to do?

In regard to the CPU controls, the number is the load intensity, and it's just a number that relates to how many times the load routine is run prior to the break time of "Some", "More" or "Most", which give load breaks of approximately 900, 500 and 50 milliseconds respectively. In other words, the number is not scaled to relative CPU speed. (The load itself simply involves moving memory around in a 500KB area.) Thus, to answer your question, a higher value will result in a longer time of CPU load prior to the set load break.

I am simulating a very busy workstation - and deploy 10 VMs running Obrut each time on a server (Dual Quad Cores with 48GB of memory). As I understand Obrut it should take over everything an not let go - which is what I see in my tests, which tend to cap out at 12 VMs when giving Obrut access to a full 2.5GHz vCPU. However others running this test can somehow load 40, 50 and 60 VMs - indicating that the workloads balloon out when deployed then contract - ready for more. Trying to get a clue as to why that might happen.

1. Misconfiguration of Obrut: Using VMem instead of the more useful PMem will completely change the results.2. Dynamic memory / CPU resources: Are the VMs set to re-allocate memory or CPU load or is it constant? That can make a difference as the "load breaks" are simply calls of the Windows function Sleep. This function is used as it prevents a complete system overload. One of the key things about the Sleep function is that it can result in the thread "sleeping" longer than asked for if the system is busy... which is very likely in this case.