Hi Everyone,
I noticed a discrepancy on the monitoring system, i.e. on cnMaestro and on the Subscriber Module.
On cnMaestro the throughput display does not match the display on the Subscriber Module. Is there a method to match these ? Since cnMaestro is sole monitoring system available to the team, access to the subcriber module is limited to IT technicians.
Kind regards,
Below are picture proof.
Throughput display on *Subcriber module*Throughput display on *cnMaestro*
Hi. I think what you’re seeing here is averaging. So on the radio’s throughput display, you have a resolution of ‘seconds’ selected, and when you look at the throughput for the last 2 minutes, it will show you the peak throughput averaged over just seconds, and you’re seeing the instantaneous throughput.
On the other hand, when you’re looking at cnMaestro, you’re looking at 4 hours of graphs, with 5 minutes per graph point of resolution.
So, an event which lasts for only a minute or two, will hardly make a blip on a 5-minute resolution graph. The throughput over that 5 minute time span will be averaged in a five-minute resolution graph.
It would be nice if the graphs on cnMaestro showed more real-time throughput than just the average throughput.
I've had this gripe for a while. I understand that "real time" would be pretty server intensive (particularly as the number of devices went up) but if the graphs retained the min/max in that time frame, that would help tremendously.
I posted this suggestion to cambium a while ago...
@Cheree King wrote:It would be nice if the graphs on cnMaestro showed more real-time throughput than just the average throughput.
Well - yes, I agree. BUT, in this particular poster's (NicoPM242) question, he's looking at a 2 minute event, and cnMaestro (and most graphing packages) only sample a data point once every 5 minutes. So - in this particular type of example, it wouldn't matter if he had MRTG or PRTG or CACTI, or whatever Nico was using for graphing - looking at 'real time' graphs is going to always be different than looking at data points sampled once every 5 minutes, for a short 2 minute event.
Now - that being said: YES, the resolution and the length of time cnMaestro keeps it's history does substantically lessen it's value. With a package like CACTI, you have the option of sampling however often you'd like (every 5 minutes is usually often enough). AND - most importantly - with a package like CACTI, when those 'daily' graphs made up of every 5 minute samples roll accross to the 'Weekly' or 'Monthly' or 'Yearly' graphs, you can set the resolution you want to keep - at the expense of more data storage space consumed.
So, in our situation - our CACTI 'Weekly' graphs are averaged to every 30 minutes, BUT we can choose to ZOOM in and still see 5 minute data points in that graph. However, there still is a tradoff in how much storage spage you choose to graph. A 30 day 'Monthly' graph that is stored in 5 minute resolution is about 9000 data points for that one host, for that one month. So - you do have to balance your need to resolution vs storage and overhead. :)
Also - CRITICALLY - for a package many graphing packages, you can also choose how much data is stored in a 'Day' or a 'Week' or whatever. So, you can have your 'Daily' graphs be longer than a day - we like ours to be the last 48 hours. Likewise, your 'Weekly' graphs are 'weekly' resolution, but with most graphing packages you can choose that graph to be the last 10 days or 14 days or whatever amount of storage space you feel you want to dedicate to the extra resolution. This is KEY to having useful resolution.
MOST MOST IMPORTANTLY - for us, we need AT LEAST 16 month's of previous data in our 'Yearly' graphs.
I know that Cambium has said that they have the intention to increase the history to 1 year - BUT IN THE REAL WORLD, THAT IS NEXT TO USELESS. I would hate to see Cambium spend the time and money and resources to extend cnMaestro's storage to 12 month's, and fall just short of making it useful as a diagnostic tool. :)
Cambium - if you are reading this: please understand this.... 12 months of data will typically mean this. A customer calls with a problem, we look at their signal and we see that it's dropped off in the last few weeks. So, if it's July 31st 2019 - we can look back through July 2019 and we can see the signal has dropped off in the last few weeks. BUT, WHAT WAS IT DOING IN JUNE & JULY 2018? Is the problem a seasonal tree problem? Does this happen every year this time, or is it that their antenna has just moved or bent a couple weeks ago? Is it a humidity thing? It is a neighbor's grain bin that blocks more signal when it's full this time of year? I can't tell any of this with 12 month's of graphs. As a matter of fact, a 12 month (52 week) graphing package has saved that information for me for a whole year - for the last 52 weeks.. and then it just just deleted it, right when I might need it. Needing to see what a client did last year this time is very very very common occurrence, and we don't need to see 'the next few weeks from last year' - we need to see 'the last few weeks from last year'. So - cnMaestro people, we need to see longer graphs, and yes a year is better than a week... but 16 or 18 months is MUCH more useful as a diagnostic tool than 52 weeks. :)
I think there was talk/plans for the pro version (paid for version) of cnMaestro to carry data back much farther and at higher resolution.
@Eric Ozrelic wrote:I think there was talk/plans for the pro version (paid for version) of cnMaestro to carry data back much farther and at higher resolution.
Yes, Eric, I believe so. That will be good. I know they had said "a year history" to me at one point, and I really, really hope they understand that a year is just short of being useful to diagnose seasonal weather foliage issues - and that it's expandable to 18 month's or so. :)
