The sinusoidal style of the line has NOTHING to do with

TransformationMatrix, Mor3bane. It has to do with the 3 consecutive

Calc measures that "round" the line by averaging the last 64 values of the previous measure. So what you have now for, say,

NetOut, is something like this:

Code: Select all

```
[MeasureOut]
Measure=NetOut
[MeasureAverageLast64Values1]
Measure=Calc
Formula=MeasureOut
AverageSize=64
[MeasureAverageLast64Values2]
Measure=Calc
Formula=MeasureAverageLast64Values1
AverageSize=64
[MeasureAverageLast64Values3]
Measure=Calc
Formula=MeasureAverageLast64Values2
AverageSize=64
```

What happens here is that the last 64 values of

MeasureOut are averaged, then the last 64 values of that average is again averaged and finally the last 64 values of the previous average are...you guessed it, again averaged. In practice, this makes the line have that nice sinusoidal look. The 64 value that configures how many of the last values will be averaged doesn't mean anything, it could be 10, 20 or whatever. Thing is, the bigger the value, the more "round" will the line look. You can try and change the

avg variable in your code to a smaller value and see for your self, the line will be less "rounded", less "sinusoidal looking".

Now, things will work just fine for

PhysicalMemory too, but here's the catch: while

NetOut has a lot of values that can be averaged (since the network traffic is almost continuous), a

PhysicalMemory measure will "jump" straight from 0 to the actual value of the memory used or whatever stuff you want to measure with it, and stay at the latter value until the memory used increase or decrease (that will happen eventually, but it will be after a LONG time). What this means in practice is that the following

Calc measures that average the last N values of the preceding measures will have MUCH LESS of

**different** values to average in order to make the line sinusoidal looking. For a long time they will have only 0 and the first value of the memory used, since that value changes at a much slower rate than the value of a

NetOut measure.

So what is the solution to this, you may ask? Well, there are 2 workarounds, but none of them is perfect and each of them has disadvantages:

- SOLUTION 1: decrease the value of the

avg variable, from 64 to less than that. That will get the last N values to be averaged faster ... although it won't "round" the line as much as if the

avg value was higher

- SOLUTION 2: wait for the memory used values to change. While this will make the line just as "round" as in the case of

NetOut, it will, as I said, take a LONG time until you notice it ... and, of course, you will

**never** get a sinusoidal look for initial values of the memory used (i.e. when the value "jumps" from 0 to the actual value of the memory used), only for subsequent values. The latter disadvantage is minor though, as that 0 to x "jump" will eventually go "off screen", if you wait a little bit:

Sinusoidal Graph Lines.jpg

This was after I used Chrome for a while and then closed it. Since it takes a lot of RAM when used for longer, the difference is noticeable when the its process (or better said, processes) is closed. You can try the same to "speed up" the process of creating the sinusoidal look for the physical memory.

You do not have the required permissions to view the files attached to this post.