ARRIS/SURFboard → SB6190 Puma6 TCP/UDP Network Latency Issue Discussion

I wanted to create a new topic under the ARRIS Forum.. Ok going between the MSO's was getting a little painful saying the same thing..

xymox1 reported an ICMP latency issue, ARRIS\Intel has a engineering build that seems to have corrected that issue now lets move onto the UDP/TCP issue..

I am working on recreating what xymox1 reported and working with him to get the data together.. I will post when I have have things to say or respond to questions.. Please keep this discussion on topic SB6190 UDP/TCP Network Latency Issue

---- mod edit ----
* Detection tool - »/tools/puma6
* Search dslr hardware section for PUMA 6 chipset: »/tests ··· hardware
* Datalink has a more complete list of devices with the Puma 6 SOC

Here are just a few devices with PUMA 6 chipsets which tend to be associated with gigabit cable modems. Not all of these are confirmed with a problem - it is just likely at this point.

Arris SB6190
Arris TG1672G
Arris TM1602
Super Hub 3 (Arris TG2492LG) (commonly - virgin media)
Hitron CGN3 / CDA / CGNV series modems:
Hitron CDA-32372
Hitron CDE-32372
Hitron CDA3-35
Hitron CGNV4
Hitron CGNM-3552 (commonly - Rogers)
Hitron CGN3 (eg CGN3-ACSMR) 2013 link
Hitron CGNM-2250 (commonly - Shaw)
Linksys CM3024
Linksys CM3016
TP-Link CR7000
Netgear AC1750 C6300 AC1900
Netgear CM700
Telstra Gateway Max (Netgear AC1900 / C6300) (Australia) 2014 link.
Cisco DPC3848V (eg »High latency/ping to Shaw router? )
Cisco DPC3941B / DPC3941T (commonly - Comcast Xfinity XB3)
Cisco DPC3939
Compal CH7465-LG / Arris TG2492LG (commonly - Virgin Media Hub 3)
Samsung "Home Media Server"

----
Potentially more (Puma 6 + MaxLinear SOC):
»www.zcorum.com/wp-conten ··· port.pdf

Awesome. Great idea.

Could we by chance make this topic for all puma 6 modems/gateways Arris has? There is quite a few. once the 6190 is fixed I assume they are going to send the same fix to all other puma 6 modems/gateways.

For this topic I want to keep it local to the SB6190 and the UDP/TCP Latency..

Okay, that makes sense since the 6190 is the modem Arris is utilizing the beta and engineering tests on.

I just started pinging DSLReports.com using PingPlotter with an interval of 0.03 seconds and started seeing the spikes. I'll post the graph later, when it's run for a while.

SB6183 is known good. Ive tested it every way.. This is also avaliable to rent at Cox. Not sure about other ISPs. 16 channel.

Careful about pinging at a fast rate to things like google or dslreports. It causes thier servers to be unhappy and they might even lock you out as they might think of you as a attack. You can see the issue at .1. Even then .1 might look like a attack. Use your gateway at your ISP or DNS server or CMTS. Even then dont just leave it running for a long time, they might get angry too. Test and then stop. To look up your Gateway, DNS servers use google for your OS and see how to do that. If your using a router then the router will have that info and you need to google how to find that with your router make and model. To fidn your CMTS, look up how to do a trace route on your OS. Then its the first hop out that returns a ping. Usally the 3rd one down the list, maybe 2nd. Traceroute google.com..

But caution with high ping rates they may look like a attack. ISP have rules on that.

One more thing I want to make clear here.. I have not confirmed there is or is not an issue with SB6190 TCP/UDP on 9.1.N code.. I will be testing this today..

If anyone has seen issues with the SB6190 other then the ICMP issue please feel free to post it here.. I need to know how to recreate what issue your talking about, if I or others can not recreate it is hard to fix..

If your talking about ICMP we are done with that, if your talking about TCP/UDP your good..

Just for a point of clarification, are we talking about IPv4 ICMP only that we are done with? I ask because I have been running the engineering code since yesterday and while I see dramatic (almost miraculous) improvement in IPv4 ICMP ping stability, it doesn't appear anything changed while running IPv6 ICMP pings, I still see the same spikes there.

Let me check my logs before I comment.. I as well did both v4 and v6..

Moderator Action
The post that was here, has been moved to a new topic .. »[Equip] Comcast Modems

I just want to be very clear here. I have over a month now reported clear and repeatable tests anyone can do. You seem to be leaning towards "its not a issue" which I would then step up a few notches in making this issue even more clear for everyone. I would assume you can insall and run GRC's dns benchmark and try it on a 6183 and and a 6190 ? Yes or no ? And you, NeDog please run these and post your results ? Also I have been very clear on how to do UDP tests with pingplotter. If you have trouble using this tool I suggest you contact pingplotter support who has been watching this thread and ny use of it as I involved them weeks ago.

Why are you trying to recreate these ? Why is arris not using better tools in a lab ? Why is intel not using better tools in a lab ?

I'm getting annoyed.

Here's a capture of a continuous ping I've been running since the code upgrade. The first is my CMTS in IPv4, the second is the same CMTS in IPv6, the third is Google DNS IPv4 and the last is Google DNS IPv6. Its looks pretty obvious IPv6 was not fixed.

This is exactly the same situation that Rogers Communications arrived at back in Sept/Oct. IPV4 ICMP has been corrected, IPV6 ICMP has not. Neither has TCP/IP or UDP for IPV4 and IPV6. Unfortunately this doesn't come as a suprise. All that it points to is that Intel and Arris still have a lot of work ahead of them to resolve all of the protocol issues.

Im upset..

Ive got over a month of all my free time on this issue. I have been professional and nice up till now. I have repeated this issue every which way. I've used scientific method on this and its been peer reviewed. My results have been repeated by others. Using a number of different test methods. I would say mathematically I have proven the issue exists in TCP and UDP. And now others are proving a whole new issue exists, IPv6 issues. The ONLY thing that looks addressed is IPv4 ICMP. Which is the least used protocol and most useless thing to fix.

Its also EASY to recreate.

Ive documented it in 20 PAGES of thread. Ive got 40 images ive uploaded and even now a video.

Intel and Arris have been watching the threads DAILY. I have web logs from the pics showing they both are glued to the thread.

So... W T F is going on ??

So far ive been calm and very helpful rather then disruptive. That may change. I might get really upset and start really making a lot of noise.

Let me recap as we have started a new thread...

The 9.1.x firmware that was supposed to fix everything, it didn't. It almost looks like a emissions hiding plot like Volkswagon tried. "maybe if we make ICMP look nice they wont notice".. When the modem knows its under test ,"ICMP pinging", look wonderful.

There is a lot at stake here. ISPs are pissed, consumers are pissed.. WORLD WIDE.. Millions of units by at least 5 manufactures have products that are wacky with a LOT of models effected. This is a BIG story and maybe one of Intel's biggest mistakes in its history. There are slight indications of Intel VS AMD being recreated with Intel VS Broadcom in anti-trust. Intel is having issues and its stock is slipping. They are not in mobile and desperatly need a market to call thier own. So the Connected Home was born with the Puma 6. Intel really needs this to go well and its not.

SO.... Here is where we are.. You cant recreate any issues even tho users here are easily able to ? Seems odd. Arris and Intel are not using labs to recreate and solve this issue ? Poor Arris is out here all alone ?

So a recap of the easily repeatable current issues.

»www.youtube.com/watch?v= ··· J400yR_E

Perhaps you missed this post.

Lets try this.. Everybody reading this can run GRC's DNS benchmark. Go run it and look at tabular results. If you have a broadcom based device it will show all 100% under all the cached reliability columns. If you have a Intel Puma 6 based device it will show almost all of them being 91-99%.

Report back your make - model and result. A yes I see loss or No im 100%.

WELL OK, not everybody. You need a PC.

»www.grc.com/dns/benchmark.htm

We need some 100% ers to also report.

Ive done this on wifi behind a router and still gotten 100% on all, BUT, you should be wired to the modem directly if possible.

He only said this AFTER we posted results. This was NEVER said up until I caught them in TCP/UDP gate.

In Arris' defence. Thsi effects A LOT more then Arris. Im glad they stepped up to help. But its time to target all the other mfgrs as well. Make them aware of the issues. The CM700 is a issue and popular.

I removed the dead servers.



8. 8. 4. 4 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.009 | 0.012 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
google-public-dns-b.google.com
GOOGLE - Google Inc., US

8. 8. 8. 8 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.009 | 0.012 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
google-public-dns-a.google.com
GOOGLE - Google Inc., US

208. 67.220.123 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.009 | 0.014 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
resolver2-fs.opendns.com
OPENDNS - OpenDNS, LLC, US

208. 67.220.222 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.008 | 0.009 | 0.012 | 0.001 | 96.0 |
------+-------+-------+-------+-------+-------+
resolver4.opendns.com
OPENDNS - OpenDNS, LLC, US

129.250. 35.251 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.008 | 0.010 | 0.017 | 0.002 | 100.0 |
------+-------+-------+-------+-------+-------+
y.ns.gin.ntt.net
NTT-COMMUNICATIONS-2914 - NTT America, Inc., US

129.250. 35.250 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.008 | 0.010 | 0.013 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
x.ns.gin.ntt.net
NTT-COMMUNICATIONS-2914 - NTT America, Inc., US

156.154. 71. 22 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.008 | 0.010 | 0.015 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
··· no official Internet DNS name ···
ULTRADNS - NeuStar, Inc., US

208. 67.220.220 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.008 | 0.010 | 0.017 | 0.002 | 96.0 |
------+-------+-------+-------+-------+-------+
resolver2.opendns.com
OPENDNS - OpenDNS, LLC, US

208. 67.222.222 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.010 | 0.015 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
resolver1.opendns.com
OPENDNS - OpenDNS, LLC, US

208. 67.222.220 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.010 | 0.018 | 0.002 | 98.0 |
------+-------+-------+-------+-------+-------+
resolver3.opendns.com
OPENDNS - OpenDNS, LLC, US

208. 67.222.123 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.010 | 0.017 | 0.002 | 94.0 |
------+-------+-------+-------+-------+-------+
resolver1-fs.opendns.com
OPENDNS - OpenDNS, LLC, US

75. 75. 75. 75 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.009 | 0.013 | 0.045 | 0.005 | 100.0 |
------+-------+-------+-------+-------+-------+
cdns01.comcast.net
COMCAST-7922 - Comcast Cable Communications, LLC, US

64. 81. 79. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.027 | 0.029 | 0.032 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
dns.sfo1.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

66. 93. 87. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.027 | 0.029 | 0.037 | 0.002 | 98.0 |
------+-------+-------+-------+-------+-------+
dns.sea1.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

204.117.214. 10 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.032 | 0.034 | 0.036 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
ns1.sprintlink.net
SPRINTLINK - Sprint, US

156.154. 70. 22 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.027 | 0.034 | 0.041 | 0.003 | 100.0 |
------+-------+-------+-------+-------+-------+
··· no official Internet DNS name ···
ULTRADNS - NeuStar, Inc., US

204.194.234.200 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.033 | 0.034 | 0.042 | 0.001 | 96.0 |
------+-------+-------+-------+-------+-------+
··· no official Internet DNS name ···
302-DIRECT-MEDIA-ASN - 302 Direct Media LLC, US

204.194.232.200 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.033 | 0.034 | 0.039 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
··· no official Internet DNS name ···
302-DIRECT-MEDIA-ASN - 302 Direct Media LLC, US

204. 97.212. 10 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.033 | 0.035 | 0.041 | 0.002 | 100.0 |
------+-------+-------+-------+-------+-------+
ns3.sprintlink.net
SPRINTLINK - Sprint, US

199. 2.252. 10 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.035 | 0.037 | 0.040 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
ns2.sprintlink.net
SPRINTLINK - Sprint, US

75. 75. 76. 76 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.041 | 0.044 | 0.073 | 0.005 | 96.0 |
------+-------+-------+-------+-------+-------+
cdns02.comcast.net
COMCAST-7922 - Comcast Cable Communications, LLC, US

64. 81. 45. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.039 | 0.044 | 0.058 | 0.005 | 98.0 |
------+-------+-------+-------+-------+-------+
dns.lax1.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

64. 81.159. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.054 | 0.058 | 0.060 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
dns.chi1.speakeasy.net
MEGAPATH8-US - MegaPath Corporation, US

64. 81.127. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.057 | 0.059 | 0.065 | 0.001 | 100.0 |
------+-------+-------+-------+-------+-------+
dns.dfw1.speakeasy.net
MEGAPATH8-US - MegaPath Corporation, US

216.231. 41. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.069 | 0.071 | 0.074 | 0.001 | 94.0 |
------+-------+-------+-------+-------+-------+
ns-legacy.speakeasy.net
MEGAPATH8-US - MegaPath Corporation, US

66. 92.224. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.074 | 0.076 | 0.080 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
phl.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

209. 55. 0.110 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.075 | 0.076 | 0.078 | 0.001 | 96.0 |
------+-------+-------+-------+-------+-------+
nsa.ibbsonline.com
MOMENTUM - SinglePipe LLC, US

209. 55. 1.220 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.075 | 0.077 | 0.080 | 0.001 | 96.0 |
------+-------+-------+-------+-------+-------+
··· no official Internet DNS name ···
MOMENTUM - SinglePipe LLC, US

66. 92. 64. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.075 | 0.077 | 0.082 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
bos.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

216.254. 95. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.087 | 0.089 | 0.094 | 0.001 | 90.0 |
------+-------+-------+-------+-------+-------+
dns.nyc1.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

216. 27.175. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.099 | 0.101 | 0.107 | 0.002 | 98.0 |
------+-------+-------+-------+-------+-------+
dns.atl1.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

66. 92.159. 2 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.099 | 0.101 | 0.106 | 0.001 | 98.0 |
------+-------+-------+-------+-------+-------+
dns.wdc1.speakeasy.net
MEGAPATH5-US - MegaPath Corporation, US

In defense of the code warriors trying to fix this, Don't be so upset or bothered by the process. Cool down and let the powers at play do the work and do the work right. Arris and Intel may have chosen to use a staged fix process to resolve each protocol that is exhibiting this problem instead of all at once. There maybe issues with each protocol that may not necessarily fix all across the board. Also any fixes may impact other areas so I see some reason why they chose to fix one problem protocol at a time and test it out to make sure it works fully and doesn't break something else. They have all the info and seems to be working on it. LET THEM do there work now. Don't fly off the handle and be bothered by the process. BE MORE PATIENT! They understand everyone's frustrations and concerns. I'm sure they fully appreciate the hard work you put into printing this to light as well. Don't be pushy. Besides you and others have the ability to use non-effected modems until the SB6190 is fully fixed.

If you feel that other Mfrs need to be made aware of this by all means go there forums and post about it. See if other Mfrs will follow in Arris foot steps to get the problem fixed on there products. Talking about it here won't help them and there customers out any. Maybe Intel will start communicating between them as well.

This was my bad, I have known about a UDP issue but could never recreate the issue.. For this issue I wanted to see if the Engineering build would fix everything but if it didn't I would start working on the next issue..

Once again I can't confirm any other issues other then the ICMP Latency.. ARRIS and Intel are both looking at recreating what people have found..

I need to see the data and how to recreate what is perceived to be an issue.. So we can recreate it, confirm it, and so we can look at ways to correct whatever is broken..

Agree that it is unreasonable to expect it all to be fixed in one fell swoop in just a couple of days. However I am concerned that Datalink has reported that this is essentially as far as they got, back in September/October, when the issue was raised on Rogers. I feel like xymox1 and others are right to be wary that they don't just optimize ICMPv4 to make it look like everything is peachy while not addressing all the issues. I also wonder if this issue would have received the traction is now seemingly has without someone like xymox1 cranking up the heat on them. Vigilance and reasonable patience are the orders of the day.You lose me here. I *don't* have the ability to go back to use non-affected modems until it is fixed because I don't have another modem, and I sure as heck am not going to go out and buy one because Arris is selling defective modems that nobody knew about. This statement is simply not reasonable in my opinion.

Is there a *free* tool out there that one can use to do TCP/UDP pinging/testing? I know PingPlotter Pro can do it but I'm not really interested in buying it just to prove a modem problem that almost certainly exists. I want to be helpful but if its going to involve spending money I'd rather just go get a modem from somebody else that actually works properly.

So with that in mind we have people using my instructions to recreate the issue above. A real UDP issue effecting DNS. I just ran a test. On bad wifi with a bad router on a public hotspot and and got all 100%. The Intel Puma 6 NEVER gets 100%. Not even close. Pretty much EVERY server is 2-10% UDP packet loss.

The above GRC DNS Benchmark clearly, for multiple people, under different conditions, is showing the Intel Puma 6 issue. This is a test anyone can run. ANyone with a PC.. Might even work virtually on a Apple.

Pretty much you have to be able to reproduce the issue using this program as everyone else can.

Im kinda tired of trying to reproduce the issue. Its time to move on to fixing the issue. Intel and Arris need to use a lab and real test setups. They have these. If there is any issue im sure a call to Cablelabs and any one of their engineers could help setup a test jig for doing this if Arris/Intel dont have the engineering skills in house. It does seem as tho they do not from these bugs and these on going discussions of trying to reproduce the issue.

Im sure TheRegister might have some people who could help. Maybe we need a new story that Arris and Intel cant do basic networking tests ?

Lets move on from issue denial to issue resolution.

Im sorry, but, this is just ludicrous that this issue exists in the first place. That it has gone on this long. That even after 20 PAGES of thread and news reports on it Arris and Intel still cant reproduce the issue that myself, a noob networking hobbyist, found on my first try. The whole thing is just plainly ludicrous.

Lest move on to fixing it. OR. Admitting there is a unfixable issue as thats what its looking more like with all this issue denial.

Ive never gotten even a courtesy email back from anyone. I believe press reporters have also been stonewalled. This ALL looks suspicious. Like maybe there is a hardware issue thats not fixable and might exist in the Puma 7 too. I cant imagine why they would only fast track ICMP ?!

I will now take a deep breath... ( Innnnnn /// Out...... ) ohmmmmmmmmmmmm...

I could be wholly wrong. i could be flying off the handle for no reason. Im open to that being possible.

So... Lets see results. No more, can you help me recreate it. We did that. I did that.

Im sorry for being upset. My personal life suffer working on this, my work suffered working on this. Im annoyed.

»www.youtube.com/watch?v= ··· nqvadurg

Bill, yes I agree, there's alot going on and alot of data and information that the Mfrs needs to sift thru and fully understand and then reproduce and then find the fix. I presume this is why there doing staged fix process and taking things gradually. This entire issue has been on recorder for over a year now. Ya It took zymox1 to get the fires going with Arris and Intel. I applaud his dedication and vigilance to the his details and his testing. I know how that goes. It consume horrendous amounts of time when testing. I presume the issue should have been caught sooner however the past is past. Due diligence has been received. Lets let the coders have some professional patient while they work on ALL items at hand.

Then your on the hook until Arris/Intel fixes the entire problem at hand. I made the statement to Xymox1 in regards to patience and having the ability to use a non-effected modem. We all understand that not everyone has a back up modem. You might consider having one on hand. This shows a need for one just in case. I have one on had for my ISP. It's not expensive to keep on on back up. If you chose too. Purely up to users in regards to this.

An easy way to test the UDP issue is to set up a site to site IPsec VPN tunnel over a 6190 modem. Wait a few hours and you'll see the slow throughput over the VPN. Reboot the modem, and it is fast again.

IPsec VPNs run on UDP packets, so it is a good way to test.