Results 1 to 5 of 5
  1. #1
    Newbie
    Join Date
    Dec 2016
    Posts
    11

    Default Scale on the side of graphs is often misleading

    I have noticed that changing a reports time frame makes the bytes per second on the side inaccurate. The one hour report shows about 130 kB/sec. The 3 hour view shows about 270 kB/sec for the same client at the same time. Does anyone have a fix for this? I tried editing the formula but haven't found the right combo. I've attached two screen shots.

    Here is supports response which is accurate.
    ****copy****
    This is more of a cosmetic thing with our reports than a misrepresentation of data- but I do understand where the confusion is here. Our reports are measured in kB, and the misleading data shown at 3 hours, is the result of the time frame. So the kB's being shown 3 hours out are changing the scale, because the time frame is so far off from the hour in which the data was collected. It looks skewed, because the kB is intended to be viewed in 1 hour increments. Here is the algorithm from the report: (s2c_bytes+c2s_bytes)/60 which measures server bytes + client bytes / 60- so the true data rests at 1 hour.

    1 hour.png
    3 hour.png

  2. #2
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,605

    Default

    yes, it is due to the data always being averaged by hour over the displayed different time periods.

    You won't see any real min/max spikes.
    You will need a specific query against the database for those.
    Even then, this won't be extremely granular, due to storage limitations.
    If you really get 'into the weeds' you will start affecting performance.

    In order to interpret any data from visual graphs, you need several views into it (perspectives). Your brain wants all of the data (trees) and the big picture (forest)

    A single graph format isn't the best way to 'pivot' the data for your brain's hunger.

    Ultimately, Untangle isn't necessarily the best tool for that kind of instrumentation.
    For me, it is a pretty good hammer.
    Last edited by Jim.Alles; 03-26-2020 at 12:57 PM.

  3. #3
    Newbie
    Join Date
    Dec 2016
    Posts
    11

    Default

    Thanks for the reply. I would have expected averages for 3 hours to show lower kbps than averages for one hour not the other way around.

  4. #4
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,605

    Talking Welcome

    ...to Untangle and the forums! (belated)

    except that it is not averaged over three hours, they don't do that extra work.
    It is the sum of (3) one-hour averaged values.

    Imagine it being like a change in the size/shape of a container. As the volume of the container is reduced (time increments) it 'piles up' into a higher level.

    It may well be that I have been ignoring this. I am not sure of the bytes/S label - that is data rate. But note the datapoint tag. That Kbytes is a total data (sum) in a chunk, at a specific time.

    If I was concerned, I might dig into the raw data.
    But this graph is a tool to compare relative to itself on a single graph, not to extract accurate details.
    having that algorithm from UT is a big help. I will chew on it.

  5. #5
    Newbie
    Join Date
    Dec 2016
    Posts
    11

    Default

    Ah, yes. 3 one hour averaged values makes sense. For me it is now just an awareness that the reports are for comparison only or to make sure you are in the one-hour view. I don't need exact values, but sometimes I like to check these reports to see if bandwidth controls are in place and working. Thanks again for the help.
    Jim.Alles likes this.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2