cancel
Showing results for 
Search instead for 
Did you mean: 

CODA-4582 - Open Issues for Investigation

RogersDave
Retired Support
Retired Support

*** This post was last edited May 2, 2017 ***

 

Good morning Community,

 

As I mentioned in a post two days ago, we have received the next firmware 2.0.10.20 from Hitron. We are currently running initial testing on this version and will push it out to participants in the firmware trial program as soon as it passes initial testing.

 

However, while running these tests, we discovered abnormal behavior with ICMP and are awaiting feedback from Hitron today to asses how this will be addressed. As soon as I this is confirmed, I’ll update the change log with the correct version information and start pushing it out.

 

In parallel, we are still working on the following high priority items. In some cases below, I requested affected customers to reach out to me via private message. If you do so, please include your modem MAC address in the subject line (even if we exchange messages daily) as there are a lot of you reaching out to me daily 🙂

 

UDP Packet Loss

The investigation for what has been reported as UDP packet loss is still ongoing. We have deployed a probe at one fellow forum member on both a CODA-4582 and a CGNM-3552 to collect additional data. We are actively working with Hitron and Intel on the results observed.

 

Based on what we know so far, in most instances UDP packet loss is coupled with higher uplink usage in the area. Although the impact is noticeable in specific logs (League of Legends), the root cause for the perceivable impact (while playing) is likely related to bufferbloat (see next issue).

 

 

Bufferbloat

When comparing the performance of a CODA-4582 to a CGNM-3552 in the same network conditions, the CODA-4582 consistently reports higher bufferbloat when tested on DSLReports.

 

Update April 12: The solution for this problem will come in two folds. It will require a change in software which will possibly be included in 2.0.10.27 but more likely in 2.0.10.28 and a change in network configuration.

 

The network configuration change is not compatible with the current firmware so this change will only come after a vast majority of the modems are running the new code. We are however looking at a way to make the change only for specific modems to support testing in the community.

 

Update April 22: This problem seems resolved in firmware 2.0.10.27

 

 

5 GHz WiFi Low range for channels 36 to 48

Lower WiFi channels on the modem have a much smaller range. This is due in part to the limit imposed by Industry Canada to maximum transmit power.

 

Furthermore, the current automatic channel selection (auto mode) tends to select the lower channels when in similar load conditions.

 

Workaround: manually select higher channels (149-153-157-161)

 

Update April 22: The channel selection algorithm has been improved in firmware 2.0.10.27

 

 

Loss of OFDM Channel Lock

Under some RF conditions, the modem fails to lock properly on the OFDM channel. This typically result in variable performance.

 

Update April 12: This problem is resolved in 2.0.10.26T2

 

 

List of connected device does not get fully populated

This is a known issue that has been tracked since firmware 2.0.10.13. We are making improvements at every firmware but it is not a perfect system.

 

The situation is worst after a reboot or firmware upgrade as the list gets reset and must be repopulated as devices renew their DHCP lease.

 

 

NAT Loopback not working for wired clients

When setting up port forwarding to an internal server, it is possible for a client on WiFi to reach the server using the external IP/port. If the client is on a wired interface, it doesn't work.

 

Update April 12: This problem is resolved in 2.0.10.26T2 (not confirmed)

 

 

LAN Counters not working

Some customers reported that LAN counters (especially in bridge mode) are reporting inaccurate values.

 

This problem has been reported to Hitron for investigation.

 

 

Unexpected modem reboot

Some customers reported their modem reboots unexpectedly. We have also seen this behavior in our lab.

 

Update April 12: This problem is resolved in 2.0.10.26T2

 

 

Missing SC-QAM Channels

After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 2.0.10.26T2 to address this behavior but it has not corrected all scenarios.

 

Investigation continues with Hitron.

 

 

WiFi Survey

The WiFi Survey functionality in firmware 2.0.10.26T2 (and possibly before) reports incorrect SSID names.

 

 

Guest Network

When connecting to the Guest Network, an error message is displayed "only allow DHCP client to use this wireless".  This has been reported in firmware 2.0.10.26T2.

 

Update April 22: This issue has been resolved in firmware 2.0.10.27

Update May 2: It seems this issue is not fully resolved and still experienced by some users


 

Future Planned Improvements

The following are items that we are working on in parallel of the above.

  • Improvement in WiFi speeds
  • Improvement in latency / bufferbloat

 

 

Dave

 

*Edited Labels*

2,620 REPLIES 2,620

Re: CODA-4582 - Open Issues for Investigation

@DeeNice you're misreading the Lost/Total datagrams.  The loss that is indicated is 96%, not 4 %.  The one problem here is that iperf 3.13 has a problem reporting losses which are beyond the real losses.  The only thing that version is really good for when testing UDP is to determine when the losses actually start, because any loss figure that it presents is above the real loss number.  The way to test this with V3.13 is to walk down the bandwidth so that you end up with 0% losses. That's for both directions.  Use the -R switch to set iperf to run as a receiver.  The loss levels will be different for up and down tests but you will know when those losses start with v3.13 

 

 

Fwiw, iperf 3.17 is out for linux and other systems.  The iperf.fr site still has 3.13 available for the windows version. 

 

From the github closes issues list #296 comes the following:

 

"We note that iperf 3.1.5 and newer contain a fix for UDP sending defaults (the old defaults resulted in a too-large packets needing to be fragmented at the IP layer). That can account for some of the problems seen in this thread. Closing for now, please re-open or file a new issue if this problem persists."

 

It looks like the defaults were changed in V3.14.  So, with V3.13, you should set the buffer length manualy so something like:  -l 1k  (-small L  1k)

 

Also fwiw, someone has compiled V3.16 to run on windows as indicated here:

 

https://www.neowin.net/forum/topic/1234695-iperf-316-windows-build/

 

For whatever reason, it would appear that the link for the download doesn't work.  I've sent an email to determine what the problem is. 

 

For a little historical background, UDP losses on the Puma chipsets are not new.  It would appear that the UDP loss situation has followed to the Puma 7 which is unfortunate, although, the Puma 7 is better than the Puma 6 chipset in terms of its overall performance including UDP losses.  This is just one of several problems with the Puma 6 and Puma 7 chipsets that Intel is working to resolve.

 

Re: CODA-4582 - Open Issues for Investigation

DeeNice
I plan to stick around

Is there another modem I can switch to? It looks like these UDP issues are now 5 months in. As it stands now I can't reliably use anything that needs UDP. 

Re: CODA-4582 - Open Issues for Investigation

@DeeNice the CODA-4582 with firmware version 2.0.10.27 is the best that you're going to see from any Puma 6 (CGN3xxx) or Puma 7 modem.  

 

Just to note the download links for the iperf downloads are working now:   https://www.neowin.net/forum/topic/1234695-iperf-316-windows-build/#comment-596631033

 

I haven't tried version 3.16 just yet, but, soon.  I expect to see a drop in the UDP losses, but, I don't expect the Puma 7 modem to match a Broadcom modem in terms of UDP losses, at least, not at this time. 

 

Are you trying to run a backup to a server with UDP, or gaming which requires UDP?  Fwiw, with that combination of 4582 and V2.0.10.27, you can run sessions with League of Legends and not have any UDP packet losses.  That observation comes from looking at my son's network logs. 

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

I wish the new gateaway is a broadcom, would be a dream!

Re: CODA-4582 - Open Issues for Investigation

DeeNice
I plan to stick around

@Datalink I run a variety of things on UDP (both as a client/server) so it's a bit broad, and unfortunately affecting the service quite a bit. I don't suppose flipping this into Gateway mode and attaching a router won't solve anything eh? 

Re: CODA-4582 - Open Issues for Investigation

Nope.  I run that combination and see the losses with UDP when I test with Iperf.  There was a test run in the last month or two at a customers home.  One observation that came out of that was that UDP losses were observed to be higher when the connected CMTS had upstream congestion.  So, part of the problem might be upstream congestion at the CMTS.  

 

Any chance you can flip any of those applications to TCP/IP?

 

Fwiw, the observations in the github site regarding excessive UDP losses were closed with the recent iperf updates, but, I still don't know if I trust it to see an accurate result.  There is NUTTCP as well, but, you need a cooperating server to run that:

 

https://www.nuttcp.net

 

Re: CODA-4582 - Open Issues for Investigation

jgamm
I'm here a lot
I'm not sure what to think bout this whole ordeal. Earlier I posted that with a VPN I get no packet loss but it was agreed that it's because it's not making out my bandwidth therefore not causing bufferbloat. However Ive actually done speedtests and get 100+ download on my vpn connection and I'm on 100u so it is actually indeed maxing out my bandwidth. I only see packet loss when I don't use a VPN and everything gets routed through Rogers hops. When I am on VPN I experience virtually no packet loss and get a stable 40 ms connection

Re: CODA-4582 - Open Issues for Investigation

DeeNice
I plan to stick around

The iperf issues you're referring to are only seen at 10GB or higher speeds (i believe, check the patch notes to verify).

 

I unfortunately can't flip my apps over to UDP, and more importantly shouldn't have to.

 

Seeing that this thread has 5 months of history is concerning. I'll ride it out for now, but I don't have much confidence in Rogers fixing this if they haven't been able to since January. They knew (after buying a ton) that the Puma 6 chips were trash, then they doubled down on puma 7 and only have 1 seriously flawed modem available?

Re: CODA-4582 - Open Issues for Investigation

I ran Iperf UDP tests tonight with V3.16.  UDP 40 Mb/s up with no losses.  I've hit 50 Mb/s up with 3.13 and no losses, so, I'm concluding that upstream congestion and time of day has a lot to do with this.  Download is terrible, only 500k UDP without any losses.  Thats with the modem in Bridge mode with an Asus RT-68U behind it.  So, the problem with Iperf UDP losses are seen in the 4582 at low data rates.  On my list of things to do is flip the modem back into Gateway mode and run the same test.  Maybe when DOCSIS 3.1 upstream is deployed, we might see some improvement with the UDP losses. 

 

As for Rogers fixing this?  This isn't a Rogers problem.  Its an Intel problem where Intel isn't saying anything publicly as to whether or not the Puma 6 modems can really be fixed.  And it looks like some issues such as UDP have migrated to the Puma 7.  There are millions of these modems in use around the world and each MSO is having to put up with the issues that the Puma 6 chipset has generated.  These modems were first introduced by Intel around 2012, and it wasn't until last summer that Rogers Engineering staff determined that there were problems that needed to be addressed and started working thru those issues.  Compared to a good many other MSOs around the world, Rogers is way, way ahead of the curve on the problems with these modems and has been working hard, in conjunction with Intel and Hitron to address those problems.  Other MSOs are still indicating to their customers that "nope, all is good here, must by your equipment".  Nothing can be further from the truth.  At the end of the day however, its up to Intel to modify the base code that allows the manufacturers to develop the final product.  Without those modifications, these issue go no where, and that's for all MSOs world wide, not just Rogers.

 

Fwiw, if you knew the history of the latency with the Puma 6, you would also know that the Puma 7 is much improved.  For some reason Rogers decided to incorporate the Puma 7 modem into the product line instead of a Broadcom based DOCSIS 3.0 32 channel / Docsis 3.1 modem.  Don't know the reason, I can only speculate that the modem cost factors into that decision, along with manufacturer support.  Maybe there are other reasons?  One can only speculate........

 

Re: CODA-4582 - Open Issues for Investigation

@DeeNice

 

In the UDP test you are running, you are pushing 1000 Mbps from a server on the Internet down to your modem and you receive 96% of the packets. This is actually a really good result.

 

The reality is that no matter what you do, the LAN interface has some overhead and it will virtually max out at about 950-960 Mbps.

 

If you retry your test lowering the bandwidth to 900 Mbps for example, I would expect you would get better results.

 

Dave

Re: CODA-4582 - Open Issues for Investigation

As of yesterday, we have promoted firmware 2.0.10.27 on the CODA-4582 to production.

 

This means that everybody is eligible to receive it with a simple reboot of their modem. We will resume the trial program as soon as I receive the next firmware (2.0.10.29).

 

Dave

Re: CODA-4582 - Open Issues for Investigation

dallasdinatake
I plan to stick around
When is .29 coming

Re: CODA-4582 - Open Issues for Investigation


@dallasdinatake wrote:
When is .29 coming

Target date for Rogers to receive the code is currently mid June. Now I typically take a few days to slowly push it to a couple of trial participants at first to ensure that it does not contain major issues.

Re: CODA-4582 - Open Issues for Investigation

Let me interpret the results as posted by @DeeNice:

 

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 0.198 ms 750666/783248 (96%)
[ 4] Sent 783248 datagrams

iperf Done.

 

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

Thanks for the update @RogersDave 

 

I am willing to test .29 as soon as you have it available.

 

@Datalink I have a feeling that D3.1 on upstream will really improve things overall including UDP, It's summer in 1 month, I wonder if they will start to deploy it in Ontario at least, god know we might only get it at the end of Summer in NB 😛

Re: CODA-4582 - Open Issues for Investigation


Datalink wrote: 

Thanks Datalink, sorry it's still early and I work too hard trying to make your Internet better 🙂

Re: CODA-4582 - Open Issues for Investigation

DeeNice
I plan to stick around

@RogersDave @Datalink

 

Fair enough. Good observation, this is why i'm in Systems and not Networking... UDP packet loss is apparently that much harder to track than TCP. My concern is that anything that requires UDP is essentially useless in my house and there's no hard time to resolution. 

 

Moving on, if you can give me an exact command to run I can post results. Additionally, if you're looking for a guinea pig, I've got Windows and Linux VM's at home running 24/7 if you need a reporting agent installed somewhere. 

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@DeeNice do you have a VPN that you can try to shuttle your UDP traffic over?

Re: CODA-4582 - Open Issues for Investigation

DeeNice
I plan to stick around

No VPN, That might work actually, but i'm not paying for a second account, it shouldn't be necessary to tunnel to another provider to have proper UDP traffic flowing. 

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@DeeNice wrote:

No VPN, That might work actually, but i'm not paying for a second account, it shouldn't be necessary to tunnel to another provider to have proper UDP traffic flowing. 


Well, yeah, but it is what it is. If a $3/mo VPN fixes your problem, that's far cheaper than anything else that you could possibly do to fix it.

Re: CODA-4582 - Open Issues for Investigation

After this mornings discussion I ran a few Iperf tests with Iperf 3.16, running with a direct connection to the modem with the modem in Bridge mode.  Rather interesting results to say the least, repeatable 50 Mb/s up  590 MB/s down.  So, it can be done, but there is more to running a high speed Iperf UDP test than meets the eye.  I had to use the iperf -w option to set the Socket Buffer Size and eventually pretty well maxed out the buffer size.  I stopped at 500Mb.  The limit is around 530Mb.  Without that Socket Buffer Size set, this test would be dead in the water. From what I can see, anyone wanting to run high speed receive UDP would have to employ a very fast processor and a router/firewall that is much more than your ordinary consumer firewall.  I think that concurrent traffic thru the router also has a lot to do with poor UDP performance that is normally observed.  It looks like the modem can do rather well with v2.0.10.27 loaded.  It might in fact be able to run faster downloads but with my processor, I hit 91% CPU utilization at 590 Mb/s.  This is on an Ivy Bridge-Extreme which is an Intel HexaCore Core i7-4930K, 3400 MHz on an Asus P9X79 Pro motherboard with 16 Gb ram. So, the 4930 is no slouch but I haven't overclocked the processor.  There are some notes on the github site regarding processor allocation, but I don't know if the windows version can do anything with that, possibly that only applies to the linux versions.  @DeeNice you were wondering about Gateway mode versus Bride mode.  My opinion at this point is that the modem can do much much better in Bridge mode than Gateway mode.  The requirement as I have indicated is a fast router/firewall.  Something like a Microtick 36 or 72 core, or possibly a pfsense built on a multi-core processor.  Just to note, on my ASUS RT-AC68U, I had to reduce the bandwidth to 500M to see both received and server bandwidth end up with the same numbers, so, with no other traffic through the router this does work, but, when you throw in gaming and Discord and twitch, that Iperf test result can go down to single or double digit data rates.

 

When you look at the results below, there are two sections ,the received data and the server transmitted data. Watching Iperf run, a couple of things will happen, Iperf either runs as expected, or, Iperf indicates a slower than expected receive value such as the following.  You can see the receive data rate at 300 Mb/s, while the server data rate is up at 500 Mb/s.   I don't know why it cycles from a good run to a bad run, but it does. No explanation at this point.

 

Received Bandwidth at ~300 Mb/s

 

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 37.3 MBytes 313 Mbits/sec 0.007 ms 22879/61054 (37%)
[ 4] 1.00-2.00 sec 28.7 MBytes 241 Mbits/sec 0.006 ms 32012/61391 (52%)
[ 4] 2.00-3.00 sec 34.7 MBytes 291 Mbits/sec 0.006 ms 25254/60830 (42%)
[ 4] 3.00-4.00 sec 38.9 MBytes 326 Mbits/sec 0.008 ms 21195/61040 (35%)
[ 4] 4.00-5.00 sec 37.4 MBytes 313 Mbits/sec 0.008 ms 22811/61077 (37%)
[ 4] 5.00-6.00 sec 15.1 MBytes 127 Mbits/sec 0.040 ms 44941/60398 (74%)
[ 4] 6.00-7.00 sec 28.9 MBytes 242 Mbits/sec 0.007 ms 31902/61493 (52%)
[ 4] 7.00-8.00 sec 38.8 MBytes 325 Mbits/sec 0.007 ms 21660/61383 (35%)

Server Transmitted data:  Bandwidth at 500 Mb/s

 

[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 55.6 MBytes 466 Mbits/sec 56885
[ 5] 1.00-2.00 sec 60.0 MBytes 503 Mbits/sec 61408
[ 5] 2.00-3.00 sec 59.4 MBytes 498 Mbits/sec 60827
[ 5] 3.00-4.00 sec 59.6 MBytes 500 Mbits/sec 61023
[ 5] 4.00-5.00 sec 59.7 MBytes 501 Mbits/sec 61105
[ 5] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec 60985
[ 5] 6.00-7.00 sec 59.4 MBytes 499 Mbits/sec 60872

 

 

Here are the command lines with the results shown below:

 

Receive at 590 Mb/s.  Note the maxed out socket buffer size  -w 500M:

 

iperf3 -c iperf.he.net -p 5201 -u -l 1k -b 590000k -w 500M -t 30 -i 1 -R -f -k -V --get-server-output

 

Transmit:

 

iperf3 -c iperf.he.net -p 5201 -u -l 1k -b 50000k -w 20M -t 30 -i 1 -f -k -V --get-server-output

 

 

I think going beyond 590 Mb/s down will take some research.  At this point I don't know why UDP receive would be more demanding than a straight TCP speedtest which runs up to 950 Mb/s.   I know that a speedtest on this modem does not run as a clean test.  You can see that if you monitor the speedtest with Wireshark.  There are numerous errors scattered throughout the test.  Maybe Iperf does some amount of packet reconstruction, don't know? Is 590 Mb/s a modem limit with the 1k buffer length or is this a CPU limit or ethernet port limit?  Also don't have that answer.

 

 

Edit:  After additional testing today with the modem in Gateway mode, I've come to the conclusion that pure IPV4 UDP performance is an issue for the 4582.  For some reason that I don't know of yet, it looks like IPV4 NAT is doing a number on UDP performance.  I ended dropping down to 1 Mb/s on the receive side to get to a point where there were no errors.  I then kicked the modem into Dual Stack mode and ran Iperf, which ran in IPV6 mode on its own.  With IPV6, Iperf ran 40 Mb/s up without errors and 500 Mb/s down without errors.  I would guess that later tonight I'd see 50 Mb/s up without errors.  So, that leaves users in a conundrum when it comes to gaming and using the modem in Gateway mode.  If your game runs UDP on IPV4 only, then I would expect you to have problems.  If your game runs IPV6 then for the most part I would expect your gaming to be trouble free, given the no error data rates that I saw in testing.  This is probably most problematic for XBox One users running a peer to peer game versus one that goes thru a server, so, it might be a point to match the modem operating mode, IPV4, IPV6 or Dual stack to the specific XBox game that you are running.  Fwiw .....

 

 

 

Receive UDP test at 590 Mb/s:

 

C:\temp\iperf>iperf3 -c iperf.he.net -p 5201 -u -l 1k -b 590000k -w 500M -t 30 -i 1 -R -f -k -V --get-server-output
iperf 3.1.6
CYGWIN_NT-10.0 CC2 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64
Control connection MSS 0
warning: Warning: UDP block size 1024 exceeds TCP MSS 0, may result in fragmentation / drops
Time: Wed, 24 May 2017 14:25:57 GMT
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending
Cookie: CC2.
[ 4] local 2607:xxxx:xxx:xx:xx:xxxx:xxxx:xxxx port 62903 connected to 2001:470:0:238::2 port 5201
Starting Test: protocol: UDP, 1 streams, 1024 byte blocks, omitting 0 seconds, 30 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 64.7 MBytes 542 Mbits/sec 0.055 ms 0/66229 (0%)
[ 4] 1.00-2.00 sec 69.5 MBytes 583 Mbits/sec 0.009 ms 0/71206 (0%)
[ 4] 2.00-3.00 sec 69.1 MBytes 580 Mbits/sec 0.008 ms 0/70759 (0%)
[ 4] 3.00-4.00 sec 68.6 MBytes 576 Mbits/sec 0.037 ms 0/70287 (0%)
[ 4] 4.00-5.00 sec 57.1 MBytes 479 Mbits/sec 0.009 ms 0/58478 (0%)
[ 4] 5.00-6.00 sec 69.9 MBytes 586 Mbits/sec 0.008 ms 0/71528 (0%)
[ 4] 6.00-7.00 sec 69.6 MBytes 584 Mbits/sec 0.006 ms 0/71269 (0%)
[ 4] 7.00-8.00 sec 69.6 MBytes 584 Mbits/sec 0.006 ms 0/71272 (0%)
[ 4] 8.00-9.00 sec 69.8 MBytes 585 Mbits/sec 0.171 ms 0/71424 (0%)
[ 4] 9.00-10.00 sec 63.2 MBytes 530 Mbits/sec 0.007 ms 0/64713 (0%)
[ 4] 10.00-11.00 sec 69.7 MBytes 585 Mbits/sec 0.009 ms 0/71417 (0%)
[ 4] 11.00-12.00 sec 69.7 MBytes 584 Mbits/sec 0.009 ms 0/71334 (0%)
[ 4] 12.00-13.00 sec 69.5 MBytes 583 Mbits/sec 0.009 ms 0/71210 (0%)
[ 4] 13.00-14.00 sec 68.5 MBytes 574 Mbits/sec 0.009 ms 0/70103 (0%)
[ 4] 14.00-15.00 sec 66.5 MBytes 557 Mbits/sec 0.009 ms 0/68052 (0%)
[ 4] 15.00-16.00 sec 69.8 MBytes 586 Mbits/sec 0.009 ms 0/71506 (0%)
[ 4] 16.00-17.00 sec 67.9 MBytes 570 Mbits/sec 0.150 ms 0/69550 (0%)
[ 4] 17.00-18.00 sec 69.1 MBytes 580 Mbits/sec 0.010 ms 0/70738 (0%)
[ 4] 18.00-19.00 sec 67.7 MBytes 568 Mbits/sec 0.009 ms 0/69372 (0%)
[ 4] 19.00-20.00 sec 64.8 MBytes 543 Mbits/sec 0.008 ms 0/66343 (0%)
[ 4] 20.00-21.00 sec 65.3 MBytes 548 Mbits/sec 0.009 ms 0/66837 (0%)
[ 4] 21.00-22.00 sec 65.1 MBytes 546 Mbits/sec 0.009 ms 0/66646 (0%)
[ 4] 22.00-23.00 sec 65.2 MBytes 547 Mbits/sec 0.010 ms 0/66811 (0%)
[ 4] 23.00-24.00 sec 69.0 MBytes 579 Mbits/sec 0.009 ms 0/70645 (0%)
[ 4] 24.00-25.00 sec 69.2 MBytes 580 Mbits/sec 0.009 ms 0/70842 (0%)
[ 4] 25.00-26.00 sec 69.3 MBytes 581 Mbits/sec 0.009 ms 0/70925 (0%)
[ 4] 26.00-27.00 sec 66.1 MBytes 554 Mbits/sec 0.009 ms 0/67647 (0%)
[ 4] 27.00-28.00 sec 68.1 MBytes 571 Mbits/sec 0.009 ms 0/69738 (0%)
[ 4] 28.00-29.00 sec 69.2 MBytes 580 Mbits/sec 0.010 ms 0/70816 (0%)
[ 4] 29.00-30.00 sec 65.4 MBytes 549 Mbits/sec 0.010 ms 0/66978 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-30.00 sec 2.07 GBytes 591 Mbits/sec 0.009 ms 0/2080428 (0%)
[ 4] Sent 2080428 datagrams
CPU Utilization: local/receiver 91.4% (32.6%u/58.8%s), remote/sender 32.7% (7.4%u/25.3%s)

Server output:
iperf 3.0.7
-----------------------------------------------------------
Time: Wed, 24 May 2017 14:25:55 GMT
Accepted connection from 2607:xxxx:xxx:xx:xx:xxxx:xxxx:xxxx, port 60915
Cookie: CC2.
[ 5] local 2001:470:0:238::2 port 5201 connected to 2607:xxxx:xxx:xx:xx:xxxx:xxxx:xxxx port 62903
Starting Test: protocol: UDP, 1 streams, 1024 byte blocks, omitting 0 seconds, 30 second test
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 66.2 MBytes 556 Mbits/sec 67827
[ 5] 1.00-2.00 sec 70.5 MBytes 592 Mbits/sec 72208
[ 5] 2.00-3.00 sec 70.0 MBytes 588 Mbits/sec 71722
[ 5] 3.00-4.00 sec 70.4 MBytes 590 Mbits/sec 72050
[ 5] 4.00-5.00 sec 70.6 MBytes 592 Mbits/sec 72274
[ 5] 5.00-6.00 sec 70.1 MBytes 588 Mbits/sec 71746
[ 5] 6.00-7.00 sec 70.4 MBytes 590 Mbits/sec 72065
[ 5] 7.00-8.00 sec 70.6 MBytes 593 Mbits/sec 72333
[ 5] 8.00-9.00 sec 70.0 MBytes 587 Mbits/sec 71659
[ 5] 9.00-10.00 sec 70.4 MBytes 591 Mbits/sec 72106
[ 5] 10.00-11.00 sec 70.6 MBytes 592 Mbits/sec 72268
[ 5] 11.00-12.00 sec 70.0 MBytes 587 Mbits/sec 71644
[ 5] 12.00-13.00 sec 70.4 MBytes 591 Mbits/sec 72115
[ 5] 13.00-14.00 sec 70.4 MBytes 591 Mbits/sec 72085
[ 5] 14.00-15.00 sec 70.0 MBytes 588 Mbits/sec 71719
[ 5] 15.00-16.00 sec 70.5 MBytes 591 Mbits/sec 72151
[ 5] 16.00-17.00 sec 70.5 MBytes 591 Mbits/sec 72190
[ 5] 17.00-18.00 sec 70.1 MBytes 588 Mbits/sec 71766
[ 5] 18.00-19.00 sec 70.4 MBytes 591 Mbits/sec 72086
[ 5] 19.00-20.00 sec 70.6 MBytes 592 Mbits/sec 72259
[ 5] 20.00-21.00 sec 70.1 MBytes 588 Mbits/sec 71763
[ 5] 21.00-22.00 sec 70.4 MBytes 590 Mbits/sec 72063
[ 5] 22.00-23.00 sec 70.6 MBytes 592 Mbits/sec 72272
[ 5] 23.00-24.00 sec 70.0 MBytes 587 Mbits/sec 71708
[ 5] 24.00-25.00 sec 70.4 MBytes 590 Mbits/sec 72079
[ 5] 25.00-26.00 sec 70.5 MBytes 592 Mbits/sec 72223
[ 5] 26.00-27.00 sec 70.1 MBytes 588 Mbits/sec 71781
[ 5] 27.00-28.00 sec 70.3 MBytes 590 Mbits/sec 72019
[ 5] 28.00-29.00 sec 70.6 MBytes 592 Mbits/sec 72268
[ 5] 29.00-30.00 sec 70.1 MBytes 588 Mbits/sec 71771


iperf Done.

 

 

Transmit test at 50 Mb/s:

 

C:\temp\iperf>iperf3 -c iperf.he.net -p 5201 -u -l 1k -b 50000k -w 20M -t 30 -i 1 -f -k -V --get-server-output
iperf 3.1.6
CYGWIN_NT-10.0 CC2 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64
Control connection MSS 0
warning: Warning: UDP block size 1024 exceeds TCP MSS 0, may result in fragmentation / drops
Time: Wed, 24 May 2017 13:51:50 GMT
Connecting to host iperf.he.net, port 5201
Cookie: CC2.
[ 4] local 2607:xxxx:xxx:xx:xx:xxxx:xxxx:xxxx port 52214 connected to 2001:470:0:238::2 port 5201
Starting Test: protocol: UDP, 1 streams, 1024 byte blocks, omitting 0 seconds, 30 second test
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.01 sec 5.56 MBytes 46.4 Mbits/sec 5693
[ 4] 1.01-2.01 sec 5.96 MBytes 50.0 Mbits/sec 6103
[ 4] 2.01-3.01 sec 5.95 MBytes 49.9 Mbits/sec 6096
[ 4] 3.01-4.01 sec 5.95 MBytes 49.9 Mbits/sec 6097
[ 4] 4.01-5.01 sec 5.96 MBytes 50.0 Mbits/sec 6100
[ 4] 5.01-6.01 sec 5.98 MBytes 50.2 Mbits/sec 6124
[ 4] 6.01-7.01 sec 5.95 MBytes 49.9 Mbits/sec 6089
[ 4] 7.01-8.01 sec 5.98 MBytes 50.1 Mbits/sec 6119
[ 4] 8.01-9.01 sec 5.95 MBytes 49.9 Mbits/sec 6088
[ 4] 9.01-10.01 sec 5.98 MBytes 50.1 Mbits/sec 6119
[ 4] 10.01-11.01 sec 5.94 MBytes 49.9 Mbits/sec 6087
[ 4] 11.01-12.01 sec 5.96 MBytes 50.0 Mbits/sec 6104
[ 4] 12.01-13.01 sec 5.96 MBytes 50.0 Mbits/sec 6107
[ 4] 13.01-14.01 sec 5.96 MBytes 50.0 Mbits/sec 6104
[ 4] 14.01-15.01 sec 5.96 MBytes 50.0 Mbits/sec 6105
[ 4] 15.01-16.01 sec 5.96 MBytes 50.0 Mbits/sec 6100
[ 4] 16.01-17.01 sec 5.97 MBytes 50.1 Mbits/sec 6112
[ 4] 17.01-18.01 sec 5.95 MBytes 49.9 Mbits/sec 6096
[ 4] 18.01-19.01 sec 5.97 MBytes 50.1 Mbits/sec 6116
[ 4] 19.01-20.01 sec 5.95 MBytes 49.9 Mbits/sec 6092
[ 4] 20.01-21.01 sec 5.96 MBytes 50.0 Mbits/sec 6106
[ 4] 21.01-22.01 sec 5.96 MBytes 50.0 Mbits/sec 6104
[ 4] 22.01-23.01 sec 5.97 MBytes 50.1 Mbits/sec 6115
[ 4] 23.01-24.01 sec 5.96 MBytes 50.0 Mbits/sec 6099
[ 4] 24.01-25.01 sec 5.96 MBytes 50.0 Mbits/sec 6098
[ 4] 25.01-26.01 sec 5.96 MBytes 50.0 Mbits/sec 6105
[ 4] 26.01-27.01 sec 5.96 MBytes 50.0 Mbits/sec 6103
[ 4] 27.01-28.01 sec 5.96 MBytes 50.0 Mbits/sec 6101
[ 4] 28.01-29.01 sec 5.96 MBytes 50.0 Mbits/sec 6106
[ 4] 29.01-30.01 sec 5.96 MBytes 50.0 Mbits/sec 6103
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-30.01 sec 178 MBytes 49.9 Mbits/sec 0.159 ms 0/182501 (0%)
[ 4] Sent 182501 datagrams
CPU Utilization: local/sender 9.3% (2.6%u/6.7%s), remote/receiver 5.1% (1.2%u/3.9%s)

Server output:
iperf 3.0.7
-----------------------------------------------------------
Time: Wed, 24 May 2017 13:51:48 GMT
Accepted connection from 2607:xxxx:xxx:xx:xx:xxxx:xxxx:xxxx, port 60848
Cookie: CC2.
[ 5] local 2001:470:0:238::2 port 5201 connected to 2607:xxxx:xxx:xx:xx:xxxx:xxxx:xxxx port 52214
Starting Test: protocol: UDP, 1 streams, 1024 byte blocks, omitting 0 seconds, 30 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 4.69 MBytes 39.4 Mbits/sec 0.152 ms 0/4806 (0%)
[ 5] 1.00-2.00 sec 6.00 MBytes 50.3 Mbits/sec 0.131 ms 0/6139 (0%)
[ 5] 2.00-3.00 sec 5.94 MBytes 49.8 Mbits/sec 0.140 ms 0/6080 (0%)
[ 5] 3.00-4.00 sec 5.99 MBytes 50.3 Mbits/sec 0.126 ms 0/6138 (0%)
[ 5] 4.00-5.00 sec 5.94 MBytes 49.8 Mbits/sec 0.142 ms 0/6079 (0%)
[ 5] 5.00-6.00 sec 6.03 MBytes 50.6 Mbits/sec 0.118 ms 0/6171 (0%)
[ 5] 6.00-7.00 sec 5.90 MBytes 49.5 Mbits/sec 0.112 ms 0/6044 (0%)
[ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 0.139 ms 0/6104 (0%)
[ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 0.128 ms 0/6107 (0%)
[ 5] 9.00-10.00 sec 5.98 MBytes 50.2 Mbits/sec 0.125 ms 0/6128 (0%)
[ 5] 10.00-11.00 sec 6.00 MBytes 50.3 Mbits/sec 0.188 ms 0/6146 (0%)
[ 5] 11.00-12.00 sec 5.89 MBytes 49.4 Mbits/sec 0.168 ms 0/6033 (0%)
[ 5] 12.00-13.00 sec 5.96 MBytes 50.0 Mbits/sec 0.120 ms 0/6102 (0%)
[ 5] 13.00-14.00 sec 5.92 MBytes 49.6 Mbits/sec 0.149 ms 0/6057 (0%)
[ 5] 14.00-15.00 sec 6.05 MBytes 50.7 Mbits/sec 0.159 ms 0/6194 (0%)
[ 5] 15.00-16.00 sec 5.91 MBytes 49.5 Mbits/sec 0.115 ms 0/6047 (0%)
[ 5] 16.00-17.00 sec 5.95 MBytes 49.9 Mbits/sec 0.126 ms 0/6091 (0%)
[ 5] 17.00-18.00 sec 5.97 MBytes 50.1 Mbits/sec 0.126 ms 0/6113 (0%)
[ 5] 18.00-19.00 sec 5.98 MBytes 50.1 Mbits/sec 0.128 ms 0/6119 (0%)
[ 5] 19.00-20.00 sec 5.94 MBytes 49.8 Mbits/sec 0.126 ms 0/6083 (0%)
[ 5] 20.00-21.00 sec 5.92 MBytes 49.7 Mbits/sec 0.123 ms 0/6063 (0%)
[ 5] 21.00-22.00 sec 6.01 MBytes 50.4 Mbits/sec 0.130 ms 0/6154 (0%)
[ 5] 22.00-23.00 sec 5.98 MBytes 50.2 Mbits/sec 0.122 ms 0/6122 (0%)
[ 5] 23.00-24.00 sec 5.97 MBytes 50.1 Mbits/sec 0.151 ms 0/6115 (0%)
[ 5] 24.00-25.00 sec 5.89 MBytes 49.4 Mbits/sec 0.123 ms 0/6035 (0%)
[ 5] 25.00-26.00 sec 5.98 MBytes 50.1 Mbits/sec 0.131 ms 0/6119 (0%)
[ 5] 26.00-27.00 sec 5.98 MBytes 50.1 Mbits/sec 0.126 ms 0/6120 (0%)
[ 5] 27.00-28.00 sec 5.93 MBytes 49.7 Mbits/sec 0.129 ms 0/6069 (0%)
[ 5] 28.00-29.00 sec 5.99 MBytes 50.3 Mbits/sec 0.116 ms 0/6136 (0%)
[ 5] 29.00-30.00 sec 5.99 MBytes 50.3 Mbits/sec 0.124 ms 0/6138 (0%)


iperf Done.