Frontier Cable vantage TV STB network speed

I was just playing with a new software tool called ping plotter that measures and graphs continuous ping times and noticed that the set top boxes that Frontier cable installed average ping times on the LAN in the teens. I have an access point router in the detached garage and the elk in my house that are in the low single digits as they should be but the STB's respond slowly.
 
Is this common? Does anyone here have Frontier cable and is willing to do a ping or two to let me know if they have similar results?
 
I suspect that my Netgear GS1116 switch could be a bottleneck. The Elk is a home run and does not go through the switch but I'm not sure about the access point in the garage.
 
Any ideas or comments?
 
Mike.

You should be getting single digit ping times. 
 
This would be fine tuning your STB clients to WAP's.  It's all about channels, antennas and wireless footprint and WAP's.
 
If your pictures are not pixelating or you do not notice it then it's probably not worth the effort.
 
I just deleted everything bad I had to write about relating to Frontier.

pete_c said:

You should be getting single digit ping times. 
 
This would be fine tuning your STB clients to WAP's.  It's all about channels, antennas and wireless footprint and WAP's.
 
If your pictures are not pixelating or you do not notice it then it's probably not worth the effort.
 
I just deleted everything bad I had to write about relating to Frontier.

Click to expand...

 
My set top boxes are all wired, no WAP. At this point I'm leaning towards blaming the 16 port switch being a bottleneck.
 
I didn't  choose Frontier Cable. My wife works for AT&T whose Uverse IPTV service was installed here many years ago and recently Frontier bought ATT Uverse. The content is still good but the service has been terrible. There is no pixelation but the resolution may be suffering if the stream is being compressed to avoid pixelation.
 
Mike.

Yeah with a switch that is 100Mb or 1000Mb and managed or not managed you should not be seeing extended ping times.
 
Sometimes the misconfiguration of a device subnet address / DNS address can do this.  Using DHCP though will not cause a misconfiguration.  That said too having two DHCP servers on network can cause issues.
 
Thinking you have the tools to do an end to end catxx test.  You can move the STB adjacent to the network switch and test ping times there.
 
I have never had a switch go bad but have had client network ports go bad or not being able to auto negociate.
 
Yeah here Frontier purchased all of the Verizon accounts.  It was a debacle (2 weeks downtime).  Once fixed canceled the Frontier account and went to Comcast. 

pete_c said:

Yeah here Frontier purchased all of the Verizon accounts.  It was a debacle (2 weeks downtime).  Once fixed canceled the Frontier account and went to Comcast. 

Click to expand...

 
we don't have RG cable in the house for cable network service.

Pete
 
There is a lot that I don't understand about networking and i struggle with it. My approach will be to look at one device at a time checking each end of the cable for proper termination. When I crimped each plug I used a cheap continuity type cable tester and never tested throughput speeds or ping time or any other thing.
 
I like your idea to move a stb near to the switch and see what that ping looks like. I don't understand what you mean by mis-configuration. The stb has nothing to configure and the switch has nothing to configure. The router is using dhcp for the stb's.
 
I'm not worried because I am kinda looking for a disease for a new procedure (ping plotter) in this case. the tv's all work fine as well as the rest of the network. Cameras, Elk, browsers. etc all work fine. I'm just curious about the long ping times on the stb's.
 
As I said earlier, the stb's may all go through the switch while the faster WAP and Elk may be home runs on the cat cable. I just haven't looked and cant remember what I did a few years ago. My lack of networking knowledge made me think that it may the the stb problem but I have no evidence to support that.
 
More snow is forecast for tomorrow but I if and when I get back to it I plan to unplug devices from the switch, see what I see and build out from there.
 
Mike.

I wouldn't worry about it unless you are actually experiencing issues with your TV watching.   ICMP  is not always a reliable measure as many devices treat it as 'best effort' since it is not required for them to function.    So they may not reply right away or at all.   You shouldn't use that as an indication  of an issue by itself.
 
If you are experiencing issues  then the next step is to look at  bandwidth and errors on the port.   But you aren't going to be able to do that with an unmanaged switch.   So you would be down to swapping, cables, ports, switches, etc.

Yes; as Wench mentions above; if you see no issues watching television then it not worth spending time to look for an issue.
 
A while back here switched my old analog cameras to IP POE cameras.  The old cameras were using baluns and the new ones cat5e poe connections.  I redid all of the terminations and there were mistakes from the old analog balun connections and I fixed them.
 
This morning your endeavor had me look at one of three managed switches here that have been running 24/7 now some 3-4 years.  You can do a lot.  Reason I purchased these switches is because they were cheap and small.  I have one inside of my Leviton 42" media panel.  They are quiet and have no fans.   Note too that here come from using only Cisco stuff in a commercial environment (aerospace) and really never had a choice.
 
Thinking I purchased each for over $150.  I see them on Amazon for $122 each.  Note that they only have a management web gui and no cli.
 
I do see an issue with one port on the switch.  It might be from me tinkering with the connections.  There is also software provided by TP-Link that manages all three switches.  I reset the counts and see no issues now with port #9.  Last week I did play a bit with one Kodi box.  I ran 4 network cables over to the family room TV here. 
 

 
I see compression / pixelation all of the time on satellite TV here.  It's always been like this.  Loss of signals happen when the dish gets snow on it and I do have to tap it sometimes.  Wife only looks at content though and not quality of signal. Never have seen this with FIOS or Cable TV.  Way long time ago with FIOS I separated the in house networks to FIOS TV and regular network at the FIOS box.  Note this was with first generation box.
 
1 - FIOS box ==> RG6 ==> moca STBs with IP addresses
2 - FIOS box ==> ethernet ==> personal firewall ==> rest of house network
 
I do not put the DTV STBs on the network today and continue to utilize RG6.  That said I do see tickles here from the Roku on the TV when watching movies anyhow from DTV or KODI so it does see what's coming in to the HDMI port on the TV these days.
 
Here with the managed switches and firewall I tinker with separate virtual network and real networks.  PFSense has two WAN connections and 4 LAN connections.  I can do VLANs on the LAN connections and using the managed switches.
 
Here is an example of streaming (look at the rate here) from the HDHomerun box over to my laptop.  Works fine at the rate you see.  With HDHomerun you can stream to just about any device you have on the network these days.
 

wuench said:

I wouldn't worry about it unless you are actually experiencing issues with your TV watching.   ICMP  is not always a reliable measure as many devices treat it as 'best effort' since it is not required for them to function.    So they may not reply right away or at all.   You shouldn't use that as an indication  of an issue by itself.

Click to expand...

 
Thanks for that. I get no pixelation on any TV but I have read that some transfer protocols will compress the data based on throughput. I'm concerned that maybe I could get better resolution if the communication was faster. In other words I am led to believe that instead of pixelation you may just get a lower resolution picture due to slow transfer rate.
 

wuench said:

If you are experiencing issues  then the next step is to look at  bandwidth and errors on the port.   But you aren't going to be able to do that with an unmanaged switch.   So you would be down to swapping, cables, ports, switches, etc.

Click to expand...

 
I do have a software that tests throughput by writing and reading a test file on network computers but I don't know if it will work with a stb hard drive. I'll have to give it a try.
 
Mike.

I agree that good is good enough, the picture is good and I'm not worried about it. This is also about learning what I can from you guys. I like to poke around in an effort to understand a little better how things work.
 
Mike.

Here are some stats relating to streaming a movie from the NAS to my laptop. 
 
Never pay attention as the picture looks fine to me when watching it on the TV in the family room from the NAS box.
 
This a a Kodi stream capture and save.  I did not notice those 7 frames missed in the stats below. 
 
Note here my KODI boxes are primary STB's.  Tiny boxes and they can do anything these days.
 

Let me explain it  this way, no switch or router is going to hold onto a packet for that long so it will drop if there is congestion or errors.   ICMP is not a reliable protocol, meaning it's dumb, so you will see each and every drop.   If you are not seeing any drops then you have a clean path.  Hardware and cables are fine.  The latency you are seeing is due to the end device's response time.
 
ICMP/Ping measures latency.  What your are talking about is throughput, not latency.   If you want to measure throrughput you need something that will graph your utilization somewhere in the line.   If you are getting a couple Mbps throughput or greater that will be sufficient for even the worst case streaming.   Everything is compressed.   Uncompressed 1080p is around 25Mbps or greater  and  they aren't  going to push that.

wuench said:

Let me explain it  this way, no switch or router is going to hold onto a packet for that long so it will drop if there is congestion or errors.   ICMP is not a reliable protocol, meaning it's dumb, so you will see each and every drop.   If you are not seeing any drops then you have a clean path.  Hardware and cables are fine.  The latency you are seeing is due to the end device's response time.

Click to expand...

 
This brings us back to my original post and confirms my suspicion that the stb is the cause of the latency or slow response to the ping. The ping plotter software that I am using reports no packet loss and as I said the video is good. I also ran a transfer test on a desktop PC on the LAN and saw 9k bytes/sec reading and 10K bytes/sec writing to a 50MB file. I don't know if this pc goes through the switch or not. Are these good numbers?
 

wuench said:

ICMP/Ping measures latency.  What your are talking about is throughput, not latency.   If you want to measure throrughput you need something that will graph your utilization somewhere in the line.   If you are getting a couple Mbps throughput or greater that will be sufficient for even the worst case streaming.   Everything is compressed.   Uncompressed 1080p is around 25Mbps or greater  and  they aren't  going to push that.

Click to expand...

Everything is compressed but not all compression methods are equal. Do the set top boxes use one and only one compression method or do they vary based on the transfer rates like HBOGO and other online streaming sites do.
 
Mike.

I am not familiar with all the ins and outs of what compression they use.  I know Netflix will adjust quality on the fly.  I think the things to look for are dark areas in the video,  compression artifacts will be blocky.   And if it is  so bad you have  trouble seeing details in dark movies  then it is a problem.   That's just been my experience.   Like I said it is all majorly compressed (like 90%), so you will see some blockiness  no matter what.    And buffering or stuttering would be an indicator as well.
 
9/10KBps is really lousy.   Windows/SMB is not really a good measure,  it is very inefficent, but those numbers are bad even for that.   Are you sure you didn't mean MBps?     For example I get 27MBps (216Mbps) file transfer via Wifi (802.11N) on Windows 10 from my NAS.

wuench said:

9/10KBps is really lousy.   Windows/SMB is not really a good measure,  it is very inefficent, but those numbers are bad even for that.   Are you sure you didn't mean MBps?    FTP or NFS are better.    Bittorrent would be ideal as a test.

Click to expand...

 
Sorry my mistake, it was MBps.