Jitter

[greg]

How important is jitter in moving data smoothly? I don't know that much about it. I installed a version of Ping Plotter and it indicated a red number on our main wireless backbone going west out of here. The first link was set to x2 and it went black when I took the cloaking off. The next hop is the strongest signal link in the system and it is consistently red (negative). Tried changing channels and other tweaks but still red. There are 8 hops to the end, all on war boards, and the average ping time is 9ms from here to the end. I'm not dropping packets at all but need someone to explain whether this is worth fussing over. The link where the jitter shows up is a w2 board, would that make any difference?

It gets progressively worse the further out you go. first link is +.75, then -1.17, -1.51, -2.43, -2.48, -2.99

[tog]

I'm not intimately familiar with the tool, you're saying the jitter is 3ms?

If so, that's not the least bit worrisome for real-world applications, even the most sensitive VoIP can handle 3ms jitter.

Large amounts of jitter (would also be referred to as ping spikes at that point) would have a detrimental effect on tcp throughput, VoIP, gaming, etc. but not such a small amount under 5ms which would be completely normal.

Nobody's VoIP or gaming will notice 5 - 10ms. If the jitter/spikes are any worse you'd likely be seeing ping spikes across your backbone end-to-end just by keeping a standard ping going. Only a larger amount of jitter would indicate a problem and would cause performance issues.

[greg]

I installed Pingplotter Pro, free eval for 30 days and a pretty slick tool. I upgraded to a newer version and it has a column for jitter which is something I know little about. It says if the number is red, that's not good. I've read some on it but am not sure what the magnitude of the displayed result is or what would cause the issue?

[go.fast]

I just looked through some Canopy archives and found a few Jitter references.
Seems that some guys are saying on a sm to ap shot that Jitter for them is good if under 6.

Not sure anything about Jitter, as I don't use any canopy.
I did how ever download that program and am measuring the Jitter across my network.

Al I can say is, if a canopy link is ok at 2-4 jitter and we are talking the same jitter here, then my systems smokes.

If you want to find out more about canopy jitter search the p-15.orgs moto archives.

George

[therealboss]

I would also like to add that StarOS supports QOS, so VOIP & Video whould work better than general surfing. I have run VOIP for months without any problems and I get the odd ping spike 30 or 40ms. I don't know how VOIP will work once I have 100 or so clients using it, only time will tell.

[richinuk]

Therealboss, what sort of load / how many users do you have on the AP where your VoIP is running smooth?

[oscarBravo]

A unit of measure sure would be nice when talking about jitter. If "6" means ±6ms, I can't see how that would be considered bad.

[therealboss]

I have a WAR4 with an omni & a sector + 2 backhauls, I connect to the sector with 31 other clients. The onmi also has about 30+ clients connected and I can run VOIP on both the sector and the onmi without any problems. I can ping a server back in the DC in about 20ms and most servers in my country between 20 & 50ms but get the odd ping of about 110ms but I do not notice any quality problems with VOIP even if I am downloading.

[richinuk]

Fantastic stats. I'm yet to do some tests in the lab to see how many small packets per second (ie; many voip users) effects overall performance of voip and other internet type traffic. Try to see where the comfort and danger zone limits are.

[therealboss]

If you run some tests, let us all know how you get on.

[richinuk]

Willdo. I'm a few weeks away from anything yet, but will post any results.

[mrmike]

And how do you set things up for QoS for VoIP? I have an appliatin for audio streaming that I would lke prioritized. Can this be done?

[therealboss]

As far as I know, there is nothing to setup, just run your VOIP and if the client and AP support QOS, bingo, it just works. As I understand it VOIP packets are marked as prioritized on any system running VOIP.

[tog]

If you're talking about straight WMM/WME prioritization, it's done using the ToS/DiffServ field in the IP header of each packet.

Most VoIP devices will set something like 0x68 for their RTP packets which will properly trigger absolute highest prioritization when any working and enabled WMM/WME implementation passes those packets.

Asterisk will set an appropriate ToS/DiffServ bit for its RTP packets and so will all Sipura/Linksys VoIP products. It's probably safe to assume most other modern VoIP devices do as well.

WMM/WME QoS is only enabled and working in the 1.2.0 beta series, it is not currently available in the 1.1.x stable series.

Also, the packets have to not be encapsulated inside anything else (such as vtun or IPSEC) in order to trigger the prioritization.