cancel
Showing results for 
Search instead for 
Did you mean: 

Suffering Packet loss

pandemic
I've Been Around

Hello, I have contacted tech support a few times and techs have come out to check my cables. The techs say that the signal strength is good and I do receive the advertised speeds 100/10, but I suffer packet loss. I also get dropped from Skype calls at the same times I am lagging on League.... I am not sure what the issue maybe, any advice?

 

Stats from the modem, it is in gateway mode and I am on a desktop connect through ethernet.
 
Ping statistics for 104.160.131.1:
Packets: Sent = 1000, Received = 870, Lost = 130 (13% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 146ms, Average = 31ms
 
Downstream Overview
Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Signal noise ratio (dB)
1 651000000 256QAM -8.700 10 37.356
2 591000000 256QAM -6.100 1 38.605
3 597000000 256QAM -7.000 2 38.605
4 603000000 256QAM -6.400 3 38.983
5 609000000 256QAM -6.800 4 38.605
6 615000000 256QAM -6.900 5 38.983
7 621000000 256QAM -7.400 6 38.605
8 633000000 256QAM -8.200 7 37.636
9 639000000 256QAM -7.600 8 37.636
10 645000000 256QAM -8.900 9 37.636
11 657000000 256QAM -9.300 11 37.356
12 663000000 256QAM -9.400 12 37.356
13 669000000 256QAM -9.400 13 35.084
14 675000000 256QAM -9.400 14 36.387
15 681000000 256QAM -9.600 15 37.356
16 687000000 256QAM -9.800 16 36.610
17 693000000 256QAM -9.800 17 36.610
18 699000000 256QAM -10.900 18 36.387
19 705000000 256QAM -10.200 19 36.610
20 711000000 256QAM -10.600 20 36.610
Upstream Overview
Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID BandWidth
1 23700000 ATDMA - 64QAM 40.250 7 6400000
2 30596000 ATDMA - 64QAM 40.250 6 6400000
3 38596000 ATDMA - 64QAM 40.250 5 3200000
201 REPLIES 201

Re: Suffering Packet loss

daveinsurgent
I Plan to Stick Around

Had my modem replaced. No improvements.

 

I still don't understand what my traceroute is showing me:

 

traceroute to google.ca (172.217.1.3), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.428 ms * *
2 174.115.204.1 (174.115.204.1) 27.136 ms 27.209 ms 28.657 ms
3 69.63.255.181 (69.63.255.181) 30.013 ms 30.112 ms 30.215 ms
<snip>
9 yyz10s14-in-f3.1e100.net (172.217.1.3) 41.716 ms 40.608 ms 40.526 ms

 

This 174.115.204.1 IP -- someone from Rogers said it's the modem in bridge mode. Other technician says no, that's not the modem IP (and I believe them - I can ping 192.168.100.1 and it's fine) they have no idea and no way to find out what that IP address is. It's the first hop after my router. It was hitting 18% packetloss during an mtr run this evening, and during my speed test that Rogers asked me to run, it spiked to 11,000 ms latency. Pinging the modem (192.168.100.1) during speed tests shows an occasional spike from 1 ms up to 13ms but no loss and nothing as insane as 11,000.

 

Pinging 174.115.204.1 without even doing anything else on the internet, it spikes to 180ms.

 

I believe this ^ IP address is some node in Rogers network upstream from me (is this the "CMTS"?) and it's having issues, with either a hardware fault or congestion or something. But nobody at Rogers that I can get in touch with can tell me anything.

 

 

Re: Suffering Packet loss

zeny12
I Plan to Stick Around

Hello me again.

 

I had the issue happen again even using ipv4 only. I was so sick of it I called Rogers and they sent a tech.

 

The tech noticed the problem, and decided to cut my cables and then put new heads on them. The problem persisted so he switched the splitter in the basement. The problem still persisted and he noticed the spikes to the CMTS. He also cut the cables somewhere in the back of my house, but the problem was still there. He didn't know what to do and he advised me to call technical support and ask about the CMTS. 

 

I decided to go out and buy a router at staples. I bought a AC1900 router D-Link 878, because I heard good things about it. I have 30 days to return it, and I am testing. 

 

I discovered it lowered my MS by quite a bit running it on bridge mode, however the CMTS is still showing spikes which make me rage really hard in competitive games. 

 

Any advice? I hate calling support because I am on hold waiting for them to pick up...

 

In other news the router is pretty good, and pretty happy with the purchase. 

Re: Suffering Packet loss

Hello @zeny12 and @daveinsurgent,

 

While I'm happy that you were both able to have technicians visit, I'm sorry to see that you still have persistent issues. 

 

Perhaps @Datalink or @gp-se have a suggestion to share before we look into sending someone back out to you?

 

RogersShaun

Re: Suffering Packet loss

@zeny12 run a ping test to Rogers DNS 64.71.255.204.  If you are running a CODA-4582 modem (the big white modem) you will see ping spikes from the CMTS.  Thats a modem issue.  The question is, do you see ping spikes when you ping the DNS?  You shouldn't, but, having said that, depending on your neighborhood and the load on the CMTS, you could see an average that is above a normal 13 to 15 ms range with much higher spikes.  

 

Can you confirm for me that you're running the CODA-4582 modem at the present time.  If so, can you log in and have a look at the STATUS .... DOCSIS WAN tab and see if one of the OFDM Downstream channels is active, which indicates that the modem is running DOCSIS 3.1.   If it is, one channel will be active and the other will be inactive.  The upstream OFDM channels will be inactive as Rogers does not have 3.1 upstream running yet. 

 

It might be time to call on the services of @RogersBob to weigh in here and have a look at everything from the modem to the CMTS and provide any direction that he can in order to solve the problem. 

 

Edit:  if you're running Pingplotter, drop the interval time down to 0.02 seconds and let that run for about 5 min.  You have to override the interval time selection in the upper right hand corner.  Plotting the results on a 1 min plot will show if you're seeing any ping spikes beyond the CMTS.  If you run a ping test to the CMTS, with a 4582 modem, that should definitely produce ping spikes on the plot.  Its just a question of whether or not you're seeing the same behavior beyond the CMTS, and if so, there's a problem somewhere in the path and my guess is at the CMTS. 



Re: Suffering Packet loss

zeny12
I Plan to Stick Around

Hello Datalink. @Datalink

Ok I am doing the ping to the DNS server at the moment, and yes I am now using the CODA modem. As a few seconds running it I've seen a a few 40MS ones and a 71MS.

I cannot login to the Status window anymore because it takes me to the D-Link web browser instead now. I remember seeing a OFDM downstream before though.

 

Edit: Not using pingplotter at the moment I am using the CMD. I can download pingplotter if needed.

Re: Suffering Packet loss

zeny12
I Plan to Stick Around

Ping statistics for 64.71.255.204:
Packets: Sent = 543, Received = 543, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 88ms, Average = 16ms

Re: Suffering Packet loss

Ok, the best way to do this is to run a 24 hour ping test and plot the results.  Running Pingplotter does work, but, Pingplotter averages the results on the plot.  Wireshark is a freebie program that is used for data analysis and to a degree, network analysis.  If you download and install Wireshark, I can give you the Display Filter settings to plot the data.  Another thought here is to run Hrping, which allows you to run ping interval times below 1 second.  

 

Hrping is found here:  https://www.cfos.de/en/ping/ping.htm

 

Wireshark is found here:  https://www.wireshark.org/

 

Hrping is a command line application.  The command to run a sub-minute ping test is:

 

hrping -t -s 20 -F c:\temp\HRPingdata.txt 64.71.255.204      where:

 

-t runs the test until stopped with Control^C

-s 20 runs the test with 20 ms intervals.  This time is in milli-seconds, so you could bump that up to something like 250 ms just to cut down on the amount of data.

-F c:\temp\HRPingdata.txt  dumps the data to a text file in the C:\temp directory, assuming of course that you have a c:\temp directory

64.71.255.204 is one of the Rogers DNS 

 

Note that in order to plot the data on with Wireshark using a 1 second interval plot, you need the ping interval to be low enough to result in at least two sample points per second, ergo, the use of Hrping.  If you're happy with a 10 second plot time, you can run the normal command line ping and Wireshark will plot the max, min and average time in that 10 second interval time, using the 1 second sampling points.  A 10 second plot works pretty well if you let the data collection run for 24 hours. 

 

That final plot will demonstrate if there is a continuous problem throughout the day or if its restricted to evenings during the week and during the day and evening on the weekends.  In both cases, your neighbors are home, gaming, streaming, etc, etc, resulting in a heavier upload condition at the CMTS.  That results in problems for everyone on your CMTS. 

 

Edit:  If you decide to go the Wireshark route, after running Wireshark for a period of time, stop the recording by hitting the red stop button on the Wireshark menu bar.  Go File .... Save, or File .... Save as to save the data to a file somewhere.  I have a directory set up to collect data, divided into further sub-directories for each day that I run a test of some sort.  You might be at this for a little while, so, it might be an idea to follow a similer route in order to preserve the data and give you a basis of comparison from day to day or week to week.  When the data is saved, then you can run the Statics IO Graph to plot the results.  Running a slow ping test, Wireshark will be able to keep up with the plot, but for high speed tests, it can't.  I don't believe that it was necessarily built to run real time data analysis for high speed runs.  At high speeds, as in low interval times, you well see errors on the plot, and in the case of ICMP, from what I remember there is an outstanding bug that requires attention in terms of how Wireshark processes the data.  Post processing the data will avoid any errors and misconceptions of the data that is being plotted. 

 

Edit 2:  Pingplotter will plot the actual results when you use a low plot time, 1 or 5 minutes.  As you move up in plot time, up to 12 hours, 24 hours, Pingplotter averages the data that it plots.  Basically it looks at the data in a given horizontal pixel range and averages the data for presentation purposes instead of preserving the max and min values.  As you drop the ping interval, that problem get worse as you have more data per horizontal pixel range.  So, for something like a 24 hour plot presentation, the plot looks pretty good as all of the data is averaged and the ping spikes no longer exist.  It would take a pretty remarkable rise in ping time over a longer period of time to actually move the data vertically on the longer timeframe plots. Wireshark will plot the max, min and average data as selected by the user, and in accordance with the Data Display Filter settings that I can give you, so, you will see the worst case ping times throughout the day on the plot.  So, no hiding of ping spikes on the plot.

 

Edit 3:  To access the modem thru the router, with the modem in Bridge mode, use 192.168.100.1 as the modem's login page address.  That address can also be used when you have a direct connection to the modem, when the modem is either in Gateway or Bridge mode.



Re: Suffering Packet loss

daveinsurgent
I Plan to Stick Around

Hi @Datalink - I don't want to steal from @zeny12's attention but I would like to essentially run the same set of tests as we are both experiencing what seems like something very similar.

 

I am currently using the CODA-4582 in Gateway mode.

 

I ran `ping -i 0.2 64.71.255.204`

 

--- 64.71.255.204 ping statistics ---
501 packets transmitted, 415 received, 17% packet loss, time 100538ms
rtt min/avg/max/mdev = 10.381/25.383/135.322/17.301 ms

 

 

Here's an `mtr -i 0.2 64.71.255.204` note I am doing 0.2 not 0.02 as you suggested in both these tests:

 

Screen Shot 2018-01-27 at 6.18.16 PM.png

 

 

Here's `sudo ping -i 0.02 64.71.255.204`

 

--- 64.71.255.204 ping statistics ---
511 packets transmitted, 400 received, 21% packet loss, time 10953ms
rtt min/avg/max/mdev = 10.415/21.359/129.178/14.595 ms, pipe 6

 

 

The modem and whatever that gateway address seem to abhor being aggressively pinged; I can see up to 18% paketloss to the 174...1 address with a regular 1s interval and spikes to 180ms. You seem to suggest that's normal? Like its' an issue-but-not-an-issue-only-when-running-ping?

 

 

 Screen Shot 2018-01-27 at 6.21.10 PM.png

Re: Suffering Packet loss

Nope, that packet loss is definitely not normal.  Packet loss to the CMTS or DNS should be down below 1%, so, there's an issue in the system somewhere.  What I can't figure out is why you have a 174.xxx.xxx.xxx address showing up in the trace.  Here's a trace from my pc to google.ca:

 

Tracing route to www.google.ca [172.217.0.227]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.asus.com [10.0.0.1]
2 13 ms 17 ms 11 ms 99.239.xxx.xxx
3 14 ms 14 ms 14 ms 67.231.221.73
4 12 ms 15 ms 16 ms 209.148.231.73
5 19 ms 25 ms 21 ms 209.148.229.225
6 23 ms 18 ms 17 ms 209.148.230.14
7 * * * Request timed out.
8 16 ms 25 ms 23 ms 108.170.250.225
9 18 ms 18 ms 17 ms 108.170.226.219
10 21 ms 20 ms 22 ms yyz10s03-in-f3.1e100.net [172.217.0.227]

Trace complete.

 

I removed part of Hop #2's address, but, the address is valid.  Typically we see a 99.xxx.xxx.xxx address as the second hop which is the CMTS.  So, I've been wondering why you're seeing a 174 address show up in the trace. 

 

Running a 4582, you will see ping spikes to the CMTS which is a processing problem with the modem itself and not with the data.  End result, one has to ping the DNS in order to see if there is an issue in terms of latency thru the modem or latency thru the Rogers network.  Running a day long ping test, ICMP, TCP/IP or UDP, I usually see one or two wacky ping spikes per day for which I have no explanation.  Depending on the type of test that is running, ICMP, TCP/IP or UDP, I'll usually see somewhere around the low tens of ms up to around 20 ms, depending on how long I run the test.   

 

Can you outline for me your current network setup:  4582 in Bridge mode with a router behind it running in full router mode?  Model of router?

 



Re: Suffering Packet loss

daveinsurgent
I Plan to Stick Around

Thanks for the quick response.

 

My current configuration is the 4582 in Gateway mode, with a TP-Link SG-3210 switch and my PC(s) connected to that. I've also tried using a Netgear R7000, or a Netgear X4S with the 4582 in bridge mode, my PC connected to either of those (never chaining or double-NAT), as well as my PC connected directly to the 4582 in bridge mode (so no other switch or any kind of  NAT device within my network) - the behavior is always the same. Packetloss and ping spikes.

 

The 174. address always shows up, and it's always in the same pattern of first two octets are the same, second octet is one less, and fourth octet is 1.

 

For example, if my whatismyip.com address is "5.4.5.5" (just making that up obviously), I will have a 2nd hop after my gateway as 5.4.4.1. If my IP was 9.9.9.9, I would have 9.9.8.1. This happens regardless of whether or not the modem is in bridge mode or gateway mode.

Re: Suffering Packet loss

@daveinsurgent going to have to think about this, you've exchanged the modem already?



Re: Suffering Packet loss

daveinsurgent
I Plan to Stick Around

Yes, I have. The modem that was taken away was running the latest beta firmware, this one as replaced is 2.0.10.28T2 -- though the issue remains the same.

 

Re: Suffering Packet loss

zeny12
I Plan to Stick Around

@Datalink 

 

My 2nd hop is also a 174.xxx.xxx.xxx address... Are you near me @daveinsurgent ? Ottawa ON?

Re: Suffering Packet loss

daveinsurgent
I Plan to Stick Around

Kitchener!

Re: Suffering Packet loss

zeny12
I Plan to Stick Around

Strange. 

 

Is a 174.xxx.xxx.xxx address not normal for a CMTS I wonder?

 

In other news I am trying to install wireshark atm. Can I still use the pc and play games while its running or no? @Datalink

Re: Suffering Packet loss

You can still use the pc for other applications, just remember that Wireshark will record all inbound and outbound traffic, including passwords.  It would be an interesting test, to run Wireshark while you're gaming.  I would back off on the ping intervals, maybe just run it at 1 per second while you're gaming.  Thats just to keep the CPU load down while you're gaming.  If you let that data recording run overnight, you will be able to look at the difference in latency, from now, thru the early morning hours when the CMTS upstream load decreases. 



Re: Suffering Packet loss

zeny12
I Plan to Stick Around

@Datalink How do I run Wireshark exactly?

 

Just run the program, make sure its recording the data and go play? 

Re: Suffering Packet loss

When you start Wireshark, it will ask you for an interface to record from.  That will be the ethernet interface.  If there are no interfaces shown, close the program and restart it in Admin mode.  You will see the ethernet interface available to record from.  Remember that you will also need the ping test running, as that is the data that will be used to generate the plot.  

 

To stop the recording, hit the red square button.  Then use the File .... Save function to save the data.  To start or restart recording, go, Capture .... Start.  You might get a warning asking if you want to proceed without saving the data that is already held in its temp file.  Proceed as you would prefer, dump the data or save it first.  From then, its the same routine, stop the data recording when you prefer and save the file or not.  Just depends if you want to keep it for later analysis. Once the recording is stopped, you can bring up the Statistics I/O Graph.  I have one item to confirm before I post the Display Filter settings which will allow you to plot the data. 



Re: Suffering Packet loss

@zeny12, here are the display filter settings for Wireshark for an ICMP ping test to Rogers 64.71.255.204 DNS. When you bring up the Statistics I/O Graph, there will be a couple of filters already present in the lower filter area. Disable those filters. Then using the bottom left "+" button, select that function to add a filer line. The filter titles and first line are as follows:

 

Name                                                   Display Filter

 

MAX ICMP to Rogers .204 DNS     icmp.type==0 && ip.addr==64.71.255.204 && icmp.resp_to

 

 

Color      Style            Y Axis                     Y Field                         Smoothing

Red         Line            MAX (Field)            icmp.resptime           none

 

The complete Display Filter above is:

 

icmp.type==0 && ip.addr==64.71.255.204 && icmp.resp_to

 

 

When that line is entered and Wireshark is happy with it, close the I/O Graph and bring it up again. Then select that filled in line and use the clone button, third button in from the bottom left. Clone that line twice. The changes to those cloned lines are the Name, Color, and Y Axis for the Min line, and Name, Color, Style, Y Axis and smoothing for the AVG line:

 

Name                                                   Display Filter

MIN ICMP to Rogers .204 DNS       icmp.type==0 && ip.addr==64.71.255.204 && icmp.resp_to

 

Color      Style            Y Axis                     Y Field                         Smoothing

Green     Line             MIN (Field)            icmp.resptime           none

 

 

Name                                                   Display Filter
AVG ICMP to Rogers .204 DNS      icmp.type==0 && ip.addr==64.71.255.204 && icmp.resp_to

 

Color      Style            Y Axis                     Y Field                         Smoothing

Black      Dot              AVG (Field)           icmp.resptime           1000 interval SMA

 

 

Add one more line and set it to read the following:


Name                                                                                  Display Filter

 

Missing ICMP Response fm Rogers .204 DNS         icmp && ip.dst==64.71.255.204 && icmp.resp_not_found

 

 

Color      Style            Y Axis                     Y Field                                Smoothing

Black       Dot             Packets                   icmp.resp_not_found     none

 

The complete Display Filter setting above is:

 

icmp && ip.dst==64.71.255.204 && icmp.resp_not_found


You should be able to simply copy the Display filter and Y Field sections and paste those into the entry windows. If you have any trouble, Wireshark has its own built in menu for those sections. When you type in an initial entry, such as icmp, and type in the "." immediataly after, a drop down menu will appear that contains all of the entries that start with the entered item, so you can simply scroll down to the required item and select it. You will know that you have the filter items set correctly as the filter entry window background colour will turn green, indicating that the entry it correct. When all is said and done, close the I/O Graph plot using the close button on the lower right and open it again. I've found Wireshark to be a little quirky when it comes to saving the entered filter parameters, so, closing it, opening it and checking the filter items after opening the I/O Graph should ensure that the filters are save and that they are correct.

 

The line names and colors used are suggested choices, set those as you prefer.  I've found that the line and dot selections for the plotted data turn out as acceptable choices for the plotted results.  On the bottom of the chart area are a drop down menu for the plot time and selection for the time of day.  For whatever ping interval time you use, you will need to be one level up in terms of the plot intervals.  So, if you are using two or more pings per second, then you can use one second as the lowest plot interval.  If you use 1 second as the ping interval, then you need to use 10 seconds as the lowest plot interval in order to see the Min and Max time seperated in two distinct areas on the plot.  When you play around with the plot time, you will see the effect that the various selections have on the plotted results.  There's no right or wrong answer here, just a matter of preference in what you want to see.  The bottom Time of Day has to be checked in order to plot the result with a real time scale, otherwise, the sample numbers are plotted. 

 

When the collected data has been saved, open the I/O Graph and enable the desired plot items by checking the enable/disable check box on the left hand side. You will probably find that enabling the MAX and MIN filters first will suffice as the chart scaling will be set to accomodate the higher MAX time values, so the AVG and Missing Response indications will be buried at the bottom of the plot. To scale down into the chart, use the Y key. Scaling out, use Shift Y. To scale in horizontally, use the X key, scaling out, Shift X. If you right click on the chart area, the chart control menu will be displayed.

Ok, that should do it for now, just a matter of waiting to collect the data, saving it and then displaying the results.

 

If you want to save the plot as a pdf or jpg, etc, hit the bottom "Save as".  That will bring up an entry window that defaults to a pdf file.  If you want to post it, you will have to change the file type to jpg.  Same for any subsequent plots that you want to save as a jpg.  



Re: Suffering Packet loss

@daveinsurgent, looking back on an ICMP test run from Saturday Nov 18th, 2017, the run time was 27 hours with a total of 481,992 pings.  Hrping indicated 23 lost responses, Wireshark indicated 30 lost responses.  So, doing the math with 30 lost responses, thats 0.0062%.  That's the type of result that I would expect anyone to see.  Running UDP, I would expect to see losses in the 0.05% range if not better.  

 

Having said that, looking at the plot itself, yep, it gets ugly, but it looks worse than it is due to the horizontal compression, squeezing 27 hours of data so that it can be seen on one plot.  The average time is around 11 ms from pc to Rogers DNS and back again.  The usual max values are around 20 ms, but the instantaneous times can range up to 200 ms.  That's partly a reflection of whats going on in the LAN and what is going on within the Rogers network.  Its pretty clear when there is very little traffic in the LAN and in the Rogers network as the max times range from 13 to 24 ms for several hours until traffic starts to pick up again around 9 am.  

 

So, one recommendation I would make is to run a ping test to the Rogers DNS (64.71.255.204) for at least 24 hours, to collect the data and then plot that data to see what happens throughout the day.  The packet loss is another matter altogether that requires resolution and may require the services of @RogersBob to check everything from the modem to the CMTS.



Re: Suffering Packet loss

daveinsurgent
I Plan to Stick Around

I had an open ticket with Live Chat to have a network engineer look in to things, and they have now said they can't find any problems. I received the phone call today to contact support "if the issue is still occurring" which of course it is.

 

Live Chat is refusing to send a tech back out again because they can't "see something on the line".

 

I noticed that to the little box thing on my house, there's a Bell line, and then there's two what look like coax lines going in to it and then going in to my house. In my utility room, I have a whole bunch of different coax leads, with only one in use. Some of course go upstairs, but I wonder if one of them is a second run out from outside. I don't know why that would exist..

 

As a laymen in terms of cable networking, it seems reasonable to me to have someone come out and perform a cable integrity test from the 'little box' in to my utility room, as well as from the 'little box' out to the road-side box. (and if there is a second cable coming through, see if one is better than the other). Also, that road-side box front panel is open a few inches and exposed to the elements and who knows what else. The technician that visited the first time said it's "not the worst he's seen" and left. He also did not know what ping was..

 

The technician that first visited noted that my modem was the only one in the neighborhood that was not responding to his remote diagnostics. The modem has been replaced, but now Live Chat is saying:

 

3:04 PM Evelyn
It is telling me your modem is not on
 
But I am chatting to them and typing this through said modem.
 
They're also telling me that the network engineer ticket was opened for 'intermittent signal', not packetloss.
 
This is incredibly frustrating. I have done so much troubleshooting on this issue, far beyond what any normal end-user  could be expected to do, and each time I do, I have to re-start with someone copy-pasting a "how to forward ports" tutorial to me just because I said the word "game". And then what I hear is that I can't even trust that my reports/complaints are being recorded correctly meaning I can't have any faith in the "all clear" investigation.
 
I don't want to be "that guy" but I do need to take this to the CCTS or some other body/agency? This has consumed an enormous amount of time and a non-trivial amount of money from me.
 
Edit:

The Live Chat tech 'send a command to my modem' and had me power cycle it. They now say they can see it, I noticed since I captuerd the screen last time, since they've had me power cycle, now it looks like this:
 
Screen Shot 2018-01-28 at 3.23.44 PM.png
 
Receiver 1 now says 4K -- etc instead of N/A -- what's up with that?
 
Ah, less than 30 minutes later it is back to NO/NA:
 
Screen Shot 2018-01-28 at 3.53.17 PM.png