B24 capacity monitoring?


#1

Getting ready to install a new B24 link, been working on monitoring side. So far I’ve not found any way to remotely poll the actual IP capacity up/down. I can pull the PHY up/down (either per-stream via SNMP or total via API) but not the actual expected max data throughput. What am I missing?

Web UI for example may give me:
PHY Tx/Rx (Mbps): 1040 / 1170
MAC Tx/Rx (Mbps): 624 / 234

But other than writing a script that will log into the webUI via HTTP(s) and scrape the MAC Tx/Rx I can’t find any way to monitor capacity. The API docs seem to indicate that TxRate and RxRate are what I want, but when actually retrieved from the radios they are always exactly the same as Tx_Phys_Rate and Rx_Phys_Rate.

An unequivocal pair of values (up/down) via SNMP representing the expected IP throughput capacities would really be welcome.

j

PS - it’s annoying that there’s no MIB for the B24. Took me a couple days to figure out that the B5 MIB was repurposed for these radios. (and many fields include ‘BFIVE’ in the name - not a problem, just personally annoying)


#2

Just so we are clear, you are looking for the “MAC TX/RX” rate?

Someday we will get some free time and setup SNMP for our Mimosa products, or I will convince the board that paying for the Mimosa Cloud is not that horrible of an option…

I would guess there should be a Tx_Mac_Rate or TXMac. I feel you on the MIB stuff though, I understand Mimosa repurposing the B5 stuff (especially because it makes it easier to add the B24 to an existing network and monitoring) maybe if they unified the whole B line to use the exact same MIB then it would be kinda sweet.


#3

Yes, I’m looking for an estimate of the actual IP throughput expected.

j


#4

I don’t think there will be any OIDs for MAC Tx/Rx as these values are estimated/calculated in the WebUI based on PHY-rate , traffic split and TDMA timing.

If you have monitoring set up you could write your own script to calculate this and graph it. Its calculated like this;

Mac Tx = PHY_Tx rate * (traffic_split /100) * (TDMA_efficiency / 100)
Mac_Rx = PHY Rx_rate * (traffic_split /100) * (TDMA_efficiency /100)

TDMA efficiency is based on 90% at 8ms, 80% at 4ms and 70% at 2ms window.

For example if you have PHY 800/800, 75/25 traffic split and 2ms window the results would be;

  • Mac_Tx = 800 * 0,75 * 0,70 (== 420 Mbps)
  • Mac_Rx = 800 * 0,25 * 0,70 (== 140 Mbps)

However it would require 10 SNMP polls just to gather info for the calculations…


#5

@morris

That is what I was wondering if could be done, but ya, that is a lot of queries for just one value…


#6

@morris - Thanks, that gives me what I need to graph the capacity for our purposes. The TDMA efficiency and up/down ratio are fixed values, so if I accept hardcoding them in the polling script then all I need to retrieve are PHY_Tx and PHY_Rx. So if we’re running 75/25 and 4ms then (approximate) downlink would be 0.6 x PHY_Tx and (approximate) uplink would be 0.2 x PHY_Rx. (just need to make a mental note the edit the calculation if we change the link settings, which is unlikely once the link is deployed)

I wish I could retrieve the totals via SNMP, instead of needing to sum the rates for each of four streams in each direction - like the values accessible via the API. But this is now doable.

My thinking is that we’re deploying this to replace an existing link to a 450’ distribution tower, and without knowing the expected capacity over time I’ve no easy way of estimating whether a new tower fed from there would be supportable or not. (E.G. say we’re running 250 Mbps peak down right now, and a neighboring tower pulling 130Mbps down peak would be easy to feed from there instead of straight from the NOC - whether the B24 downlink capacity generally runs 400Mbps or 500Mbps would be vital to making that decision)

j

(edited to correct formula that was getting parsed instead of displayed)