I have multiple customers pulling 3000kbs+ when their SM and the AP show them connected at the below rates. Anyone else seeing this?
I do not use BAM or prizm. I use the AP and configure the SM to the allowed speed.
Sustained Uplink Data Rate 768 (kbps)
Uplink Burst Allocation 768 (kbits)
Sustained Downlink Data Rate 1500 (kbps)
Downlink Burst Allocation 1500 (kbits)
Is your AP set to use configuration source: SM?
yes, the sm is configured to above speeds and the ap is set to config source of:SM
The ap shows the sm at the correct speed in the session list, however speed tests have dramatically different results.
8.2.2 on the affected SM’s? Have you tried downloading files from a reliable FTP instead of using a speedtest that may report incorrect speeds?
I just happened to test a new v8.2.2 radio from a customer’s site the other day, before and after putting QOS settings in, and everything seemed to be working as advertised for me…
I use the mini speed test on my server (from http://www.speedtest.net/mini.php) and test only my infrastructure, then out to the backbone. It really helps from our perspective. We can see local speeds without the internet issues cluttering it up.
CVS,
After seeing your post about using Speedtestmini I decided to install it as well. We have tested a couple different Speed Test Software packages. However neither of them report the proper bandwidth usage.
For example, today we were doing some testing. We tested using our Old Speedtest software and we only got 500K. We tested with the New Speedtestmini and we Got 700K, then we tested it online at Speedtest.net and were get 1.2Mb, which is about what we should have been getting with the profile we were set to.
I just find it odd that we are seeing the proper speeds on the internet but not when we test to one of our servers. This is pointing me towards something in our NOC that is throttleing the Speed test or something to do with the Server it’s self that the Speedtest software is installed on. Also we have to connect to the VPN to actually be able to access the Speedtest Server, could this be causeing the bottleneck?
Does the Software require specific ports to be open on the Server it’s running on?
A couple other things to note
All the Speed Test Packages we tried have been ran from the Same server (it’s actually our Cacti / IPPlan Server)
Secondly when I access the VPN from Home and run a Speed Test to BOTH of these Speedtest Packages, I get PERFECT results every single time.
Anyone have any suggestions??
Frothingdog.ca wrote: CVS,
After seeing your post about using Speedtestmini I decided to install it as well. We have tested a couple different Speed Test Software packages. However neither of them report the proper bandwidth usage.
For example, today we were doing some testing. We tested using our Old Speedtest software and we only got 500K. We tested with the New Speedtestmini and we Got 700K, then we tested it online at Speedtest.net and were get 1.2Mb, which is about what we should have been getting with the profile we were set to.
I just find it odd that we are seeing the proper speeds on the internet but not when we test to one of our servers. This is pointing me towards something in our NOC that is throttleing the Speed test or something to do with the Server it's self that the Speedtest software is installed on. Also we have to connect to the VPN to actually be able to access the Speedtest Server, could this be causeing the bottleneck?
Does the Software require specific ports to be open on the Server it's running on?
A couple other things to note
All the Speed Test Packages we tried have been ran from the Same server (it's actually our Cacti / IPPlan Server)
Secondly when I access the VPN from Home and run a Speed Test to BOTH of these Speedtest Packages, I get PERFECT results every single time.
Anyone have any suggestions??
I would expect the VPN to create a bottleneck as it has to encrypt data before sending it over the tunnel - that causes overhead and that's why VPN doesn't work well on slow or high-latency connections. When you say "perfect" results from home - (1) are you using your wireless sytem there and (2) by perfect you mean expected speed test results?
It may be doing exactly what you’re telling it to.
Keep in mind that until you empty your burst bucket, you’ve got everything that the radio can transfer. If you want to make sure that you are limiting as you expect, either turn off the burst entirely and test, or download a 2 meg file and immediately start your speed test as it finishes.
Make sure you understand the mechanism of the bandwidth controls used in the radios. See page 86 and following, especially the “Token Bucket Concept” section of 7.1.7.
I’m not on our wireless service at home, I’m on DSL. When I test to our Speedtest server over the VPN it gives me results of 1Meg by 300K which is exactly what I have for a DSL connection and testing on the internet to Speestest.net show me 1Meg by 300K as well.
We have tryed multiple settings in the SM while testing. We have tryed setting all values to 1024, we have tryed removeing the burst entirely (setting it to 0) testing from several towers testing with different types of SM’s (LITE, Standard, Advantage) We also tested using a different Freq. None of them show the proper test results.
I’m actually starting to think it’s our NetEnforcer that chokeing the test but haven’t had a chance to prove it out yet.
We had been running as a speedtest.net site and then later as a mini site for over a year.
My conclusion is that the mini tests (that we test internal speed) are not as accurate (show slower download speeds) than the speedtest.net host sites.
We’ve seen that a few times with our speedtest mini also. Once in a while, the local test runs slower than the offsite test. Weird.
cvs wrote: We've seen that a few times with our speedtest mini also. Once in a while, the local test runs slower than the offsite test. Weird.
There's no question that if your network is functioning smoothly, speeds to a server at your NOC absolutely should at least equal speeds to a server 500 miles away.
I believe it mostly has to do with the server in question, rather than the speedtest app/procedure being inconsistent. Three R's: Resources (network interface) Resources (memory) Resources (CPU). If it's a linux system dipping into swap forget about valid results, same if you're approaching packet-per-second limits. (which is often easier to hit that bps)
I tested on two linux servers: Same hardware, same cisco switch. One a little-used apache web server, one my monitoring and troubleticket server. Monitoring consists of a constant but relatively light flow of pings, but with surges every few minutes as subnets are scanned for canopy devices, and SNMP polling pulls everything imaginable from them and stuffs in DB. Plus a few dozen auto-refresh connections to the monitoring web UIs. Predictably the apache server was more reliable - from outside our network or from within it, speedtest mini on that box consistently shows within 5% of expected DL rate, while the monitoring box (in large part due to packet bursts every few minutes polling Canopies, sometimes pulling SNMP from 100 at a time) ranged from 80% expected down to 25%.
j
Ever use Iperf?
Start an Iperf daemonized server on one of your servers in your NOC that is accessible directly by your wireless network.
When you go out to customer locations, run an iperf test from customer to NOC iperf server.
I usually do this, then run a test across the 'net and make a note of the results.
Iperf is a great tool, for both TCP/UDP and simultaneous testing. =)
I actually have a couple iperf servers running due to the network infrastructure on servers in the NOC including iperf servers running at each tower. I run cronjobs that would execute an iperf test from tower to tower and record the results and email it to me…maybe a little over excessive, but I like to know how the network stands or where it’s starting to fail, etc.
I once found a problem at a tower due to a failing switch – Tower to Tower (19mi) I was getting 34mbps FDX, but past the core tower to the NOC it was killing it down to just over 2mbps. Stinkin switches. =/ So customers 2 hops out could only achieve 2mbps, and once that link was saturated, all hell broke loose on the tech lines. It’s also nice just to have that available to figure out why you’re only getting Xmbps or Xkbps when you should be getting Xmbps or Xkbps.
- Rich
I actually have a couple iperf servers running due to the network infrastructure on servers in the NOC including iperf servers running at each tower. I run cronjobs that would execute an iperf test from tower to tower and record the results and email it to me...maybe a little over excessive, but I like to know how the network stands or where it's starting to fail, etc.
This is what we're looking to do as well. Is IPERF easily installed on on FreeBSD boxes?
Frothingdog.ca wrote:
I actually have a couple iperf servers running due to the network infrastructure on servers in the NOC including iperf servers running at each tower. I run cronjobs that would execute an iperf test from tower to tower and record the results and email it to me...maybe a little over excessive, but I like to know how the network stands or where it's starting to fail, etc.
This is what we're looking to do as well. Is IPERF easily installed on on FreeBSD boxes?
Yes, http://dast.nlanr.net/Projects/Iperf/