On 04/19/13 21:19, Craig Small wrote: > Total bandwidth comes from a SNMP get, specifically the ifTable ifSpeed > entry for that interface. A lot of devices mis-report this value, so > first check that it is correct. Also at least in Cisco devices you > can set it with the bandwidth command.
Bandwidth measurement and monitoring has always been a challenge, particularly when a given interface starts exceeding 20% or more of the interface's theoretical maximum throughput, from all designers and manufacturer's, imho. The problem of the low level software development for such are massive and out of scope for this list. It's a pain in the wazoo, but the following technique usually works for verification of bandwith measurement and monitoring. Set up a stand alone, minimize unix system (I use gentoo linux but many will suffice) and dual interfaces (ethernet, serial, T3) using whatever hardware you have available. It really helps if the monitoring interfaces are approximately 10 times larger: (for example, if you want to measure/monitor and 100 Mbit/s ethernet, set up 2 a linux system with 2 1Gbit/S ethernet cards. Route your traffic through that measurement/monitoring system and run any number of low level measurement softwares: such as bwmonitor: http://www.bwmonitor.com/ It's a bit of work, but is very useful to accurately diagnose problems. PS, if you work for a company, with loads of cash, then there are sophiticated products you can use and get vendor support from to diagnose/measure/monitor channel throughput problems. One note that holds true, if a product cannot sustain a given throughput in an isoalated lab environment, it sure as hell will not work on a real communications network, that is multi-vendor and meshed...... > So an E3 has a bandwidth of 34 Mbps, I think you're saying you are > seeing an output or input over this amount though both your examples are > below this. There are telecom support vendors that lease equipment for testing ATM, Sonet, E3, 10G-E and such. Many offer an expert with the equipment which may be your best bet for cost effective identification and resolution to Telcom channel throughput issues. > This would be surprising for two reasons; the first being > that JFFNMS has a clamp to stop that and the second is the SNMP device > should report that sort of figures. It wouldn't be the first time > that's happened: lots of people have been fooled by Cisco 6500s and > SVIs with their bizzare numbers. The real truth here is not limited to cisco but, 99.999% of all commercial communications products. The numbers you get are mostly only reliable at less than 20% of channel utilization, often it is lower than 20%. Communication channels and the measurement and monitoring of these channels is "black magic" if you look at the underlying embedded firmware that defiances how an actual communication product measures and reports actual throughput. Think about it. superfast memory necessary for the data storage on a communication channel, if of premium cost. You think a vendor is going to spend tons of money for that, as oppose to using that superfast memory to enhance channel efficiency: they'd go broke cause their gear would not be cost effective on the market.... For example, Cisco, being the whores of communications equipment, will source different chipsets for identical products (boards, components, manufacturing runs) so that what should be 2 identical channels are indeed and infact engineered by 2 different suppliers, each supplying differnt firmware or SOC solutions for a given interface (board) in a router, switch, etc. But Cisco and all the industry vendors will label these boards as identical. They are mostly work seamlessly, particularly at a "high level" seen by customers, but do not be fooled as performance can and does vary wildly! In the old days, cisco engineers wrote 100% of their low-level code, using the vendor supplied code only as a starting point. Now days, most of the brilliant coders have left cisco, so cisco only works on a given interface, until the code compiles and they ship it. This is another reason the MBA's at cisco keep purchasing small companies and vendors; they cannot innovate internally and the talent pool (of technical folks) is in constant exit mode. Likewise, ALL of these vendors are the same now in order to stay in business.... Why do you think that much of cisco's codebase is available on the net and know hacker sites? cisco has lost it's sole (it's deep respect for coding excellence). Cisco, and all communications vendors have a "pig mess" on their low level code, due to a lack of expertise on code maintenance. We see further evidence of this as products are deprecated in lieu of newer ones, incessantly. Properly maintaining sorry-code is very expensive and often impossible without the original authors being involved. SOCs only add an additional layer of complexity, cause the the coders have to have a deeper understanding of hardware as well as knowledge of robust, low level coding. I know, I have written, debugged and been responsible for a variety of embedded systems over the years. Add to this various "object oriented coding styles" and you should begin to understand the mess the industry is in. Many of the older experts believe that "object oriented" coding and all but destroyed good coding practices in embedded systems. So trust, but verify, and realize you need to select larger hardware ports, and not be in a situation where any given vendor channel needs to run at more than 50%. 20% or less is ideal! Be smart and pick your poison carefully. You should be very thankful that guys like Craig do what they do......for the wider community. /end_rant/ hth, James ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ jffnms-users mailing list jffnms-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jffnms-users
