Network - Wireless & Wired Connections

Help & troubleshooting for network issues, including connecting your device to your home Wi-Fi network, connecting to public networks, troubleshooting wireless issues & ethernet connections, and optimizing streaming performance.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 8

Can someone explain the "glitch/sec" parameter in diagnostics?

I have a Roku Express+, and recently I've noticed that at times my wifi streaming performance (esp. on Netflix) will deteriorate for no clear reason. Even during these periods, my wired PC has plenty of download speed (based on and other tests), and the Netflix built-in diagnostics and speed test still show a good result (using the app on the Roku), but streaming becomes very erratic and doesn't maintain HD-quality video. Using the wifi screen, my signal strength seems fine and the noise floor appears low, so I'm usually well over 20 dB of clear signal. The only stat which seems out of spec is that I often have a high "glitch/sec" value, well up into the hundreds/sec at times. I've tried changing wifi channels but it has not been a consistent fix. I've also tried relocating the Roku, which sometimes seems to help, but the problem usually comes back after a little while.

I'd be grateful if someone could explain what a high "glitch/sec" count really means--is it a measurement of wifi interference that is different from "noise", or does it suggest some kind of hardware or video processing error in the Roku? Is there a way to minimize it?  Thanks for any insight.

Labels (2)
0 Kudos
3 Replies
Level 13

Re: Can someone explain the "glitch/sec" parameter in diagnostics?

I think you might be overly focused on the wrong statistic.

The IEEE 802.11 specification which is the basis of most Wifi networks allows for data to be transmitted in a series of packets were each packet can be 2300+ bytes which comes out to over 18,000 bits per packet.  Because of the nature of digital radio communications (of which signal strength and noise are just a couple of the issues), it is not uncommon for a bit to get flipped in transmission.  The IEEE considered this problem and addressed it in the design by putting a CRC (Cyclic Redundancy Check) at the end of the 802.11 packet.  This can detect if bits have been flipped and in most cases can correct the issue.  If CRC can't correct the issue, I believe the error count should go up which is the value you really should be looking at for Wifi issues.  This is all taking place before the data is handed to the H.264 video decoder and is not related to that.

To put some perspective on the a couple hundred glitches per second, Netflix recommends having a connection that support 5 megabits per second for HD quality video which would mean 1000 glitches per second would be 0.02% of the traffic being CRC corrected.

If you really feel the need to make the glitch/sec count appear smaller, there are some thing *could* try (but I am not saying you *should* bother doing them):

(1) Try bringing the Roku as close to the Wifi access point as possible
(2) Make sure your Wifi access point is 802.11n or 802.11ac (not an older 802.11g)
(3) Try using a wifi access point made by a different manufacturer
(4) Try using a wifi access point that does 802.11ac with 5Ghz support and switching to a Roku Streaming Stick
Things you *should* try doing to troubleshoot the erratic/poor video playback:

(A) Try playing back the same exact Netflix video in Google Chrome on your wired PC
(B) Try playing back the same exact Netflix video on a wifi connected laptop/phone/tablet (preferably one that only does 2.4Ghz 802.11n and doesn't do 5Ghz or has it disabled)

As a side note to Roku ...

Providing Wifi glitch/sec statistics is of limited use!  Please expose the information from /proc/net/snmp and /proc/net/netstat as the information from the TCP stack gives a better indicator of issues going on from end to end with streaming.  Monitoring the TCP retry and SACK counts can be a quick easy way to rule out the Wifi, ISP and other network issues (or to confirm one of those are likely at fault).  Not only can I not find the TCP statistics in any secret menu, it seems like Brightscript is design to prohibit access despite there should be no security issue with accessing these read-only virtual files.
Level 8

Re: Can someone explain the "glitch/sec" parameter in diagnostics?

Thanks for the detailed response. Despite having searched, I hadn't found anything else online which explained that the Roku's "glitch" statistic was a measure of wifi packet corruption.

Part of my concern on the "glitch" parameter may be due to how the Roku wireless screen provides a "color coding" to indicate the status or quality of the connection. The glitch/sec indicator bar turns from green to orange or red at a relatively low glitch rate, so mine often shows as a long red bar (as opposed to the "green=OK" theme for the other signal information).
0 Kudos
Level 8

Re: Can someone explain the "glitch/sec" parameter in diagnostics?

I have a similar problem with my Roku Stick+.  I first had it on an 802.11ac network, with a down load speed of 70 megabits.  The network and the STICK+ were in the same room 12 feet apart.  No joy. I then downgraded to 802.11n, still no changes 400 “glitches” per second.  Signal to noise ratio ranged from 26 to 32, well in the green.  I then powered the wireless router off.  Obviously, Rx and Tx numbers were zero, but the glitches continued at up to 400 per second.  Temps on the stick continued to hover around 99c.  Nothing happening but something was Burning up the processor driving MHz up to 1000.

Tomorrow, I will turn everything off, hopefully clearing any buffers that might be in the stick and see if the glitches reappear, attempting to rectify CRC errors.  Shouldn’t occur but my suspicions seem to lead me to a very poorly written network app which I hope ROKU will localize and fix.  I sincerely hope it is not a chip level embedded problem.