As I indicated yesterday, you're going to have to ping the Rogers DNS IP. Just let that run once per second for a 24 hour time span and you might see a difference throughout the day in in fact there are congestion issues. Ideally you would simply ping the CMTS for a 24 hour period or longer, but, that's not possible with the 4582. Going beyond the CMTS also brings in the possibility of network issues and DNS loading as well. I haven't found those to be an issue but, it would be hard to distinguish between a local CMTS issue and a network and/or server issue. A large difference in response times, from very early morning to later in the evening I would consider to be a CMTS issue.
From my router:
--- 188.8.131.52 ping statistics --- 31 packets transmitted, 26 packets received, 16.1% packet loss round-trip min/avg/max/stddev = 10.911/15.791/32.113/4.668 ms
From the CODA modem:
--- 184.108.40.206 ping statistics --- 4 packets transmitted, 2 packets received, 50% packet loss round-trip min/avg/max = 10.000/10.000/10.000 ms =============Complete==============
I have lost my OFDM downstream lock again.
OK, I had been meaning to do this for a while. Enough with the pings. I set up an iperf3 instance in AWS and hit it from my pfSense router. (My router is a Celeron G3930 with an i340 network adapter and 8GB DDR4 memory)
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 761 KBytes 6.23 Mbits/sec 0 45.5 KBytes [ 5] 1.00-2.00 sec 1.10 MBytes 9.24 Mbits/sec 2 41.1 KBytes [ 5] 2.00-3.00 sec 1.27 MBytes 10.6 Mbits/sec 0 72.5 KBytes [ 5] 3.00-4.00 sec 2.23 MBytes 18.7 Mbits/sec 0 105 KBytes [ 5] 4.00-5.00 sec 1.97 MBytes 16.5 Mbits/sec 2 73.7 KBytes [ 5] 5.00-6.00 sec 2.10 MBytes 17.6 Mbits/sec 2 52.3 KBytes [ 5] 6.00-7.00 sec 1.41 MBytes 11.8 Mbits/sec 0 80.8 KBytes [ 5] 7.00-8.00 sec 1.32 MBytes 11.1 Mbits/sec 2 66.7 KBytes [ 5] 8.00-9.00 sec 1.64 MBytes 13.8 Mbits/sec 2 56.7 KBytes [ 5] 9.00-10.00 sec 1.30 MBytes 10.9 Mbits/sec 0 82.3 KBytes
Test Complete. Summary Results: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-15.00 sec 17.9 MBytes 10.0 Mbits/sec 0.000 ms 0/93745 (0%) sender [ 5] 0.00-15.00 sec 17.8 MBytes 9.96 Mbits/sec 0.200 ms 350/93731 (0.37%) receiver
There is a constant, persistent amount of dropped packets. I am going to re-run this at various times of day. I restricted the bandwidth to something modest like 10mbit too.
Compare with pfSense -> wired server, no surpirse:
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 15 second test, tos 0 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 207 KBytes <snip - all Retry are 0> [ 5] 14.00-15.00 sec 112 MBytes 942 Mbits/sec 0 207 KBytes
And for UDP I can move around 100,000 packets per second with no loss.
What version of iperf are you running. You need to run V3.17 or later, or you will see excessive losses which are false loss indications. Can you run iperf from the pfsense router itself? Very cool....
Looks like iperf 3.5 is the latest version:
I think you mean 3.1.7 yeah (not trying to be pedantic :D)
[2.4.2-RELEASE][admin@pfSense]/root: iperf3 -v iperf 3.2 (cJSON 1.5.2)
admin@server:~$ iperf3 -v iperf 3.1.3
Will update the server, but I only used it during the tests that actually showed no loss.
There is another way to do this for UDP testing, and that is to use DNS queries and Wireshark to record the data and plot the results. Wireshark also has the capability to filter the results in a DNS analysis tool to determine the results. If you're interested have a look at the following post which uses a DNS query application to run a continuous query to the Rogers DNS.
I run a continuous query with a script to run another application, collect the data with Wireshark and run the plot and analysis within Wireshark. I need to get around to writing a post to do all of this with Wireshark. That should help settle some of the arguments, is there packet loss or not?
Edit: Food for thought. If anyone was to run continuous UDP queries for response time and loss testing, or run an iperf test to a non-existent Rogers Iperf server, you would see that the losses within the Rogers network are substantially less than what you saw with the iperf test to the AWS. To come to any conclusion about UDP or ICMP or TCP/IP losses, anyone interested in testing for that needs a baseline set of numbers, what are the responses and losses in my ISP network and what happens when I test outside of the network. So, consider that for future testing. Are you able to run any type of script within pfsense to run a continuos DNS query to the DNS IP address of your choice? That would be a great test tool to have on hand.
I'm certainly not trying to discredit the other ways of testing.
But you show packetloss with ping, "oh, ping isn't reliable", so you show packetloss to the DNS, "oh, the DNS servers aren't designed to respond like that", so you hit AWS, and it's like "oh, it could be anything"
No, it's Rogers -- the modem, the cable, the CMTS, something.
While there may be MORE loss to AWS than elsewhere (assuming the elsewhere is reliable -- not sure about that right now), there's still an amount of loss that, regardless, is unacceptable. Rogers can say it is out of their control, but if someone 2km away from me doesn't see the problem at all, that's a big deal.
I'm also interested in having my friend run a server and have me hit it, again, 2 km away.
@daveinsurgent the only thing that I'm trying to point out the the possibility of incrementally higher losses outside of the ISP network, doesn't matter which ISP we're talking about. I suspect that end users would get some grief from tech support with any method of testing that doesn't match their scripts. Personal opinion, don't care about the scripts and I don't believe that the engineers would frown on ICMP / UDP / TCP/IP testing of any type. I haven't run into any negative reaction from the engineering staff since I started to run these type of tests on the modems. If you don't do this, you never see the idiosyncrasies of the modems, good or bad. Fwiw, this is exactly the type of testing which led the engineering staff to pursue the Puma 6 latency issue with Hitron and Intel. That's an ongoing issue worldwide and Intel is now in the middle of a class action law suit in the U.S. because of the latency issue. Rogers decided to push on with deployment of the Puma 7 CODA-4582 and since its release in Dec 2016, there have been a steady stream of updates for the modem. That doesn't necessarily mean that the updates have fixed everything, but, the modem has improved greatly since the initial release. Not trying to defend Rogers here at all, just pointing out the history, all due to simple ping tests by the end users. What is it they say, the pen is mightier than the ping? Something like that.
Could you elaborate what you mean by Engineering Staff?
I have had senior people from Ramkey come out who basically don't care at all about these kind of tests. Online chat is also pretty indifferent, they log in to the modem, run a ping test (and I'm like 60% sure that they don't even realize they're pinging the modems IP from the modem itself, so it's almost useless)
Engineering staff as in @RogersDave (now departed Rogers), @RogersKevin (gaming thread) and now @RogersBob and @RogersSyd, after Dave's departure. @RogersBob hasn't been in the forum much and I haven't seen @RogersSyd yet. I suspect that everyone is busy with the upcoming IPTV launch. As you indicated, the tech support staff isn't much help beyond their standard tests.