>>> Instead of being consistent, some would be >>> 3ms, some would be 100ms.
notes... First, latency is not always bad, if it is not created by congestion that usually results in packet loss or slowing down TCPIP. Second, MT allows setting the packet combining into 1 of 3 ways. So if it is a problem, you can select the method that best matches your need. Unfortunteately, Ping is no longer an accurate way to test performance/proper optimization of a wireless network. This has caused me problems with custoemrs, because they don;t understand wireless network, and it makes it hard to guarantee latency in SLAs, if the way latency is meaured is by end user test tools using Ping. I can not speak for how MT does it, but I'm sure they use similar techniques. But I can use Trango ARQ as an example... In order to maximize throughput, if there is a packet lost, it will re-send the packet during the next transmission. So if data is constantly flowing (TCP and UDP) the re-tranmission will occur almost immediately. But with ICMP (ping) the protocol does not require another immediate transmission from the original side (meaning no packet behind it), so it waits a defined period for Trangos ARQ to re-send the Ping packet. That is why when a Trango link has minor packet loss (corrected by ARQ) the Ping times will sky rocket (200ms, 500, 700 etc ), but if you push TCP data, the latency of the TCP data will consistently be low. This can be proven by specific speed tests using the "max speed = latency x window size". You can do a test (web based or Iperf) to the other side of teh US with a real 80ms latency, set to small window size, and watch the speed slow way down. Then do the same test on your wireless link that has random high latency w/ Pings, and Iperfs will show super fast trhoughput as if teh latency was really low. Or one can use a VOIP jitter testing tool. Trango ARQ is a bit off topic, but... Microtik Nstreme has some method of how it handles re-transmissions. This as well potentially could effect how ping reports, expecially in less than perfect link conditions. But it very well might not effect real TCP/UDP traffic. What you can also do is run a UDP iperf at a define slow speed under the capacity of the link. (for example set to do a 1mbps test on a 30mbps capable MT) and then simultaneously do a ping. Do you get the same low ping results? But my points is, Ping is not a reliable tool IF, it either has no other trafiic or has to much other traffic. Again, with packet stuffing, latency can go high IF there is not enough processing power to handle the routines. But it should not increase the latency much to combine packets, on proper equipment. (atleast not if the routine is written well) Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Dennis Burgess - Linktechs.net" <[email protected]> To: "WISPA General List" <[email protected]> Sent: Friday, January 09, 2009 1:10 PM Subject: Re: [WISPA] 5.8GHz Backhaul Radio Recommendations > yep, anything more than -40 is BAD. better tests are around -55 or so.. > > ------------------------------ > * Dennis Burgess, CCNA, A+, Mikrotik Certified Trainer > WISPA Board Member - wispa.org <http://www.wispa.org/> > Link Technologies, Inc -- Mikrotik & WISP Support Services* > *Office*: 314-735-0270 *Website*: http://www.linktechs.net > <http://www.linktechs.net/> > > */ Link Technologies, Inc is offering LIVE Mikrotik On-Line Training > <http://www.linktechs.net/onlinetraining.asp>/* > > > > Jack Unger wrote: >> David, >> >> Just for info here but it's possible that your signals were so loud >> that the receivers were being overloaded. That drives them bananas... >> >> jack >> >> >> David E. Smith wrote: >>> Dennis Burgess - Linktechs.net wrote: >>> >>>> Yes you have to have a good processor, it does compression. I also >>>> believe it does MPPP as well, and larger frame sizes as well to get >>>> higher speeds. Hence, processor usage is key. >>>> >>> >>> When I was testing this - pretty informally, two radios set on the floor >>> of the office about a hundred feet apart - the speeds weren't that much >>> higher, and the latency was all weird. The RF link was pretty good (I >>> think there was 40-some-odd points of SNR), and when I used them in >>> regular AP/bridge mode, or basic WDS, I actually got better performance >>> than when I enabled polling and Nstreme and all the other Mikrotik >>> proprietary magic checkboxes. >>> >>> The throughput was pretty comparable, but when the link was even lightly >>> loaded, pings went bananas. Instead of being consistent, some would be >>> 3ms, some would be 100ms. I figured that was because my little ping >>> packets were being bundled up with other packets, then transmitted when >>> it was most efficient for the radio, as opposed to being sent on-demand. >>> >>> First, is that pretty close to accurate? Second, in the real world, when >>> you're trying to do something like VOIP or gaming that's sensitive to >>> latency, how noticeable is it? >>> >>> David Smith >>> MVN.net >>> >>> >>> -------------------------------------------------------------------------------- >>> WISPA Wants You! Join today! >>> http://signup.wispa.org/ >>> -------------------------------------------------------------------------------- >>> >>> WISPA Wireless List: [email protected] >>> >>> Subscribe/Unsubscribe: >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> Archives: http://lists.wispa.org/pipermail/wireless/ >>> >>> >>> >>> >> >> -- >> Jack Unger - President, Ask-Wi.Com, Inc. >> Serving the Broadband Wireless Industry Since 1993 >> Cisco Press Author - "Deploying License-Free Wireless WANs" >> WISPs - Do you know where your customers are? >> For wireless coverage mapping see http://www.ask-wi.com/mapping >> FCC Lic. #PG-12-25133 LinkedIn Profile >> <http://www.linkedin.com/in/jackunger> >> Phone 818-227-4220 Email <[email protected]> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: [email protected] >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > > -- > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.552 / Virus Database: 270.10.5/1884 - Release Date: 1/9/2009 > 8:38 AM > > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
