WireShark didn't show the broadcast storm like PingPlotter suggested it would. WireShark is pretty cool so I decided to trace my ethernet while I ran the speedtest from the client. Here's a snippet of it. No ICMP is sent from the client. Looks like HTTP for latency and TCP (maybe) for speeds. 123 is Apple. 120 is my computer. Those times seem bigger than they should. I don't really know when the client determines latency. On the ACK?
I sent a note to PingPlotter suggesting I don't see a broadcast storm and wondered if they had any other ideas. They suggested getting a laptop plugged in where the Apple box is and ping from it to my computer and see what I get.
I first issued the HTTP command 192.168.1.120:8089/speedtest and got the following terrible latency.
I then did a ping (after opening up my computer firewall to accept ICMPs) and got the following great latency.
So the question is why is the HTTP to Channels so bad when a ping to the computer is great? Are HTTP packets lower priority?
The mystery continues. All of a sudden this morning my <1ms latency is back! Yay!?
I had poor response for over a week, maybe 2 weeks. Here are 3 WireShark snippets at my computer when doing a speedtest with 100ms+ latency followed by a 4th snippet taken this morning with <1ms latency.
In the slow responses the ACK beats the OK every time and the OK is almost 200ms later. Not sure how that lines up with the client reported 100ms latency.
In the fast response the OK is almost immediate.
Doesn't that say there's something going on in my computer or in the Channels DVR for the OK to be so slow in the bad cases?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.