Summary Screen Bytes/Sec representation

[tecnalb]

I have a test case I performed this Am. I will post more details in a bit, but this test case demonstrates my point.

[slansing]

Great, we will await the reply!

[tecnalb]

This AM I remote-accessed a client’s site. I first ran a speed test to verify their service. They have a cable-broadband 10x1Mbps circuit. Speedtest.net confirms (see image)

speedtest.jpg

Then I accessed their router, which is also running rflow(netflow) and setup the graphs to display WAN and LAN. However, I set the LAN to display MBps(bytes) and the WAN was left at default Mbps(bits) so you could see the comparison.

I then went to CentOS website and started a download of the OS DVD (about 3.5GB in size). I was able to get a 10Mbps download. I let this run for 30 minutes. The attached graph will show you what the router indicated. Some simple math, and you can see that the WAN and LAN indicate correctly.

Screen Shot 2014-01-15 at 8.29.49 AM.png

If you look at NAA’s graph, at the start of the transfer, notice the numbers.. 11034115 Bytes/Sec... Multiply by 8 bits per byte and you get 88,272,920 bits, or 88Mbits/sec

Screen Shot 2014-01-15 at 8.28.12 AM.png

[tecnalb]

Here is 2 more shots.... Clearly there must be a label issue, or math problem.

Screen Shot 2014-01-15 at 8.32.26 AM.png

Day Sample.png

[sreinhardt]

OK, we did a whole lot of digging on the various parts, so let me see if I can keep it all straight....

1) snmp counters for ifoutoctets\ifinoctets and ifHCoutoctets\ifHCinoctets are all counted in and presented as bytes, not bits per cisco* and snmpd definitions. I can only believe that ddwrt(what it looked like your router was using) would use the standard snmpd daemon as its embedded linux essentially.

2) XI takes the data from mrtg in the form of bytes out of the mrtg rrds with a plugin called check_mrtgtraff. This plugin DOES convert it to bits and correctly label it as such, this data is stored in another rrd file for pnp and nagios graphs to use, again in bits.

I guess that's not quite as much info as I had in my mind. But with that, I know that the XI\MRTG graphs are correct. I also validated this against my own system, where I was downloading a beta game this weekend and know it was running at ~3.5MBps, which my XI puts at ~27 mbps ( / 8 = 3.5MBps). NNA however is also showing 27MBps for that timeframe, so NNA is the one with the labeling issue(as you might have intended to point out initially). Taking the total byte per second NNA value and turning it to MBps does come out to 3.5 MBps (/8/1000/1000). This would seem to confirm what you are seeing, that XI is correct with bits and NNA actually is mislabled and should say bits not bytes. The developers agree with this logic, and it will be patched into the next revision of NNA.

Thanks for bringing this up, it may have been a bit of a trek to verify all the different working parts, but I think we agree on the same points, and what to resolve.

* http://www.cisco.com/en/US/tech/tk648/t ... 69ac.shtml

[tecnalb]

Yes, I agree that it seems to be a label issue. I have not compared all of the other graphs, but this was the one sticking out to me as odd. The numbers I have seen all seem to be accurate, if ignoring the label. I just wanted to bring it up in case you purposely meant to display in MB... then it might be a decimal-placement issue. Happy to provide some helpful feedback.

[sreinhardt]

OK cool, glad we agree. I will lock this up for now since we know the issue, and nothing can be done until the next update. If you run into anything else let us know!

[cmerchant]

Fixed in Nagios XI trunk, which should be in the latest XI version.