RT-AC88U wifi traffic throttle problem

[jtara]

I am going to make one more attempt to figure out what is going on with the WiFi traffic throttling on my RT-AC88U.

This has been off and on over a period of YEARS. It comes and goes. I have gone months with no problem. And then (as now) I get it several times a day. (Right now, I have to reboot like HOURLY.)

Router
----
- RT-AC88U
- Merlin 384.13
- No packages installed
- QOS disabled, as I've been suspicious, but I don't think in any way related
- CPU utilization low, 0-5% when idle, varies as expected with load (in failed state)
- RAM used 211MB free 301MB (in failed state) 41%

I mention CPU utilization because maybe a year ago I had a problem with high CPU that was solved with reboots, but that has not recurred since several firmware updates since then and does not occur now in failed state.

Temperature (currently, in failed state)
----
- 2.4gHz 49C
- 5gHz 49C
- CPU 78C

Environmental
----
- Just off flight path and < 2 miles from SAN (Lindbergh Field), so 5gHz channels are limited
- North edge of downtown San Diego. Many, many, many, many.... wifi signals. Starting with 6 floors of &^%$#@ WeWork a block away, hotels across the street, etc.

Switch
----
- D-Link Web Smart Switch DGS-1216T
- Physical VLAN "untrust" on port 6-7. This allows optionally monitoring inet traffic (with port 8)
- port 8 "tap". Can be configured to mirror any port, can be configured to monitor any physical VLAN (e.g. plug in laptop with WireShark, etc.)
- The other ports are physical VLAN for my local devices

Internet
----
- Webpass (Now Google-owned). 1Gbps symmetrical dual radio link to nearby fiber node.
- ~ 4mSec to backbone in L.A. (I am in San Diego)
- Shared by 85 apartments, but probably less than 1/2 lit, ($0 direct cost to me, HOA pays)
- Speedtest desktop consistently gets 900mbps+ at quiet times, never goes much below 800
- No problems with throughput to/from Internet

Symptom
----
- Appearance of throttling of traffic that passes between WiFi (2.4 or 5gHz) and either Internet or local devices.
- "spikey" start-stop, very obvious when using Speedtest and watching the "needle"
-
- CloudCheck Wi-Fi Sweet Spots shows no problem with traffic between wifi devices (iPad, iPhone) and the router. Just consistent high throughput at close to expected maximum bandwidth given bandwidth settings, etc.
- iperf3 shows same bad behavior with throughput to local Ethernet nodes as Speedtest shows to Internet (see below)

Additional observations
----
- no problem immediately after reboot, and then normal operation for a period of time between minutes and months
- once problem occurs, it continues until reboot
- problem has become much more often recently. Currently cannot get through a day or even half-day without problem recurring
- I have considered heat-related cause - it's been hot and humid, enough that I've had A/C on when present day and night, but indoor temp maintained at 76-78 when home

I'm ready to chuck the RT-AC88U and replace with a pfSense box and e.g. Google or Ubiquiti mesh router. Don't really need mesh in my 900sq. ft. condo, but I might want to extend the network to e.g. a nice outdoor deck that I can use one floor down, e.g. put a node in the window.

My best guess is a heat-related problem that affects some specific component in the path between the radios and internal switch? Bad solder job? Gunk buildup? I'll admit I haven't checked this.

iPerf3 server on my Mac Mini, iperf3 client HE Network Tools on iPhone XSMax. This is in failed state. I will reboot and post in not failed state.

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.1.149, port 52277
[ 7] local 10.0.1.105 port 5201 connected to 10.0.1.149 port 52278
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.01 sec 1.31 MBytes 10.9 Mbits/sec
[ 7] 1.01-2.01 sec 1.50 MBytes 12.6 Mbits/sec
[ 7] 2.01-3.00 sec 2.20 MBytes 18.6 Mbits/sec
[ 7] 3.00-4.00 sec 6.06 MBytes 50.8 Mbits/sec
[ 7] 4.00-5.01 sec 5.40 MBytes 45.0 Mbits/sec
[ 7] 5.01-6.00 sec 2.65 MBytes 22.4 Mbits/sec
[ 7] 6.00-7.00 sec 4.28 MBytes 35.9 Mbits/sec
[ 7] 7.00-8.01 sec 2.34 MBytes 19.5 Mbits/sec
[ 7] 8.01-9.00 sec 2.82 MBytes 23.7 Mbits/sec
[ 7] 9.00-10.01 sec 3.10 MBytes 25.9 Mbits/sec
[ 7] 10.01-11.01 sec 1006 KBytes 8.22 Mbits/sec
[ 7] 11.01-12.01 sec 2.35 MBytes 19.8 Mbits/sec
[ 7] 12.01-13.01 sec 2.43 MBytes 20.4 Mbits/sec
[ 7] 13.01-14.01 sec 2.44 MBytes 20.5 Mbits/sec
[ 7] 14.01-15.01 sec 2.51 MBytes 21.0 Mbits/sec
[ 7] 15.01-16.01 sec 4.98 MBytes 41.9 Mbits/sec
[ 7] 16.01-17.00 sec 3.37 MBytes 28.5 Mbits/sec
[ 7] 17.00-18.01 sec 5.19 MBytes 43.2 Mbits/sec
[ 7] 18.01-19.00 sec 3.48 MBytes 29.4 Mbits/sec
[ 7] 19.00-20.01 sec 6.47 MBytes 53.9 Mbits/sec
[ 7] 20.01-21.00 sec 3.10 MBytes 26.2 Mbits/sec
[ 7] 21.00-22.01 sec 4.51 MBytes 37.5 Mbits/sec
[ 7] 22.01-23.01 sec 6.57 MBytes 55.1 Mbits/sec
[ 7] 23.01-24.01 sec 4.42 MBytes 37.1 Mbits/sec
[ 7] 24.01-25.01 sec 4.76 MBytes 40.0 Mbits/sec
[ 7] 25.01-26.01 sec 532 KBytes 4.36 Mbits/sec
[ 7] 26.01-27.01 sec 1.09 MBytes 9.09 Mbits/sec
[ 7] 27.01-28.01 sec 1.31 MBytes 11.0 Mbits/sec
[ 7] 28.01-29.00 sec 1.49 MBytes 12.6 Mbits/sec
[ 7] 29.00-30.01 sec 3.77 MBytes 31.4 Mbits/sec
[ 7] 30.01-30.10 sec 761 KBytes 68.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-30.10 sec 98.1 MBytes 27.3 Mbits/sec receiver

Immediately after reboot below. Note this would be much higher normally, but I've suspiciously set channel bandwidth to 20mHz. I will probably switch it back to 40 or 80, as this doesn't seem to be the problem.

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.1.149, port 52387
[ 7] local 10.0.1.105 port 5201 connected to 10.0.1.149 port 52388
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 16.0 MBytes 134 Mbits/sec
[ 7] 1.00-2.00 sec 16.8 MBytes 141 Mbits/sec
[ 7] 2.00-3.00 sec 16.8 MBytes 141 Mbits/sec
[ 7] 3.00-4.00 sec 14.4 MBytes 120 Mbits/sec
[ 7] 4.00-5.00 sec 14.2 MBytes 119 Mbits/sec
[ 7] 5.00-6.00 sec 13.1 MBytes 109 Mbits/sec
[ 7] 6.00-6.46 sec 6.60 MBytes 119 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-6.46 sec 97.7 MBytes 127 Mbits/sec receiver

I switched 5gHz back to 20/40/80 and about the same. I assume I will always have this limitation due to my location near the airport which gives me limited 5gHz channels. Not a problem, this is fine for browsing on an iPad!

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.1.149, port 52470
[ 7] local 10.0.1.105 port 5201 connected to 10.0.1.149 port 52471
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 15.7 MBytes 131 Mbits/sec
[ 7] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec
[ 7] 2.00-3.00 sec 16.5 MBytes 138 Mbits/sec
[ 7] 3.00-4.00 sec 16.4 MBytes 137 Mbits/sec
[ 7] 4.00-5.00 sec 16.3 MBytes 137 Mbits/sec
[ 7] 5.00-5.99 sec 16.6 MBytes 141 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-5.99 sec 97.7 MBytes 137 Mbits/sec receiver

 

[OzarkEdge]

I am going to make one more attempt to figure out what is going on with the WiFi traffic throttling on my RT-AC88U.

This has been off and on over a period of YEARS. It comes and goes. I have gone months with no problem. And then (as now) I get it several times a day. (Right now, I have to reboot like HOURLY.)

Router
----
- RT-AC88U
- Merlin 384.13
- No packages installed
- QOS disabled, as I've been suspicious, but I don't think in any way related
- CPU utilization low, 0-5% when idle, varies as expected with load (in failed state)
- RAM used 211MB free 301MB (in failed state) 41%

I mention CPU utilization because maybe a year ago I had a problem with high CPU that was solved with reboots, but that has not recurred since several firmware updates since then and does not occur now in failed state.

Temperature (currently, in failed state)
----
- 2.4gHz 49C
- 5gHz 49C
- CPU 78C

Environmental
----
- Just off flight path and < 2 miles from SAN (Lindbergh Field), so 5gHz channels are limited
- North edge of downtown San Diego. Many, many, many, many.... wifi signals. Starting with 6 floors of &^%$#@ WeWork a block away, hotels across the street, etc.

Switch
----
- D-Link Web Smart Switch DGS-1216T
- Physical VLAN "untrust" on port 6-7. This allows optionally monitoring inet traffic (with port 8)
- port 8 "tap". Can be configured to mirror any port, can be configured to monitor any physical VLAN (e.g. plug in laptop with WireShark, etc.)
- The other ports are physical VLAN for my local devices

Internet
----
- Webpass (Now Google-owned). 1Gbps symmetrical dual radio link to nearby fiber node.
- ~ 4mSec to backbone in L.A. (I am in San Diego)
- Shared by 85 apartments, but probably less than 1/2 lit, ($0 direct cost to me, HOA pays)
- Speedtest desktop consistently gets 900mbps+ at quiet times, never goes much below 800
- No problems with throughput to/from Internet

Symptom
----
- Appearance of throttling of traffic that passes between WiFi (2.4 or 5gHz) and either Internet or local devices.
- "spikey" start-stop, very obvious when using Speedtest and watching the "needle"
-
- CloudCheck Wi-Fi Sweet Spots shows no problem with traffic between wifi devices (iPad, iPhone) and the router. Just consistent high throughput at close to expected maximum bandwidth given bandwidth settings, etc.
- iperf3 shows same bad behavior with throughput to local Ethernet nodes as Speedtest shows to Internet (see below)

Additional observations
----
- no problem immediately after reboot, and then normal operation for a period of time between minutes and months
- once problem occurs, it continues until reboot
- problem has become much more often recently. Currently cannot get through a day or even half-day without problem recurring
- I have considered heat-related cause - it's been hot and humid, enough that I've had A/C on when present day and night, but indoor temp maintained at 76-78 when home

I'm ready to chuck the RT-AC88U and replace with a pfSense box and e.g. Google or Ubiquiti mesh router. Don't really need mesh in my 900sq. ft. condo, but I might want to extend the network to e.g. a nice outdoor deck that I can use one floor down, e.g. put a node in the window.

My best guess is a heat-related problem that affects some specific component in the path between the radios and internal switch? Bad solder job? Gunk buildup? I'll admit I haven't checked this.

iPerf3 server on my Mac Mini, iperf3 client HE Network Tools on iPhone XSMax. This is in failed state. I will reboot and post in not failed state.

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.1.149, port 52277
[ 7] local 10.0.1.105 port 5201 connected to 10.0.1.149 port 52278
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.01 sec 1.31 MBytes 10.9 Mbits/sec
[ 7] 1.01-2.01 sec 1.50 MBytes 12.6 Mbits/sec
[ 7] 2.01-3.00 sec 2.20 MBytes 18.6 Mbits/sec
[ 7] 3.00-4.00 sec 6.06 MBytes 50.8 Mbits/sec
[ 7] 4.00-5.01 sec 5.40 MBytes 45.0 Mbits/sec
[ 7] 5.01-6.00 sec 2.65 MBytes 22.4 Mbits/sec
[ 7] 6.00-7.00 sec 4.28 MBytes 35.9 Mbits/sec
[ 7] 7.00-8.01 sec 2.34 MBytes 19.5 Mbits/sec
[ 7] 8.01-9.00 sec 2.82 MBytes 23.7 Mbits/sec
[ 7] 9.00-10.01 sec 3.10 MBytes 25.9 Mbits/sec
[ 7] 10.01-11.01 sec 1006 KBytes 8.22 Mbits/sec
[ 7] 11.01-12.01 sec 2.35 MBytes 19.8 Mbits/sec
[ 7] 12.01-13.01 sec 2.43 MBytes 20.4 Mbits/sec
[ 7] 13.01-14.01 sec 2.44 MBytes 20.5 Mbits/sec
[ 7] 14.01-15.01 sec 2.51 MBytes 21.0 Mbits/sec
[ 7] 15.01-16.01 sec 4.98 MBytes 41.9 Mbits/sec
[ 7] 16.01-17.00 sec 3.37 MBytes 28.5 Mbits/sec
[ 7] 17.00-18.01 sec 5.19 MBytes 43.2 Mbits/sec
[ 7] 18.01-19.00 sec 3.48 MBytes 29.4 Mbits/sec
[ 7] 19.00-20.01 sec 6.47 MBytes 53.9 Mbits/sec
[ 7] 20.01-21.00 sec 3.10 MBytes 26.2 Mbits/sec
[ 7] 21.00-22.01 sec 4.51 MBytes 37.5 Mbits/sec
[ 7] 22.01-23.01 sec 6.57 MBytes 55.1 Mbits/sec
[ 7] 23.01-24.01 sec 4.42 MBytes 37.1 Mbits/sec
[ 7] 24.01-25.01 sec 4.76 MBytes 40.0 Mbits/sec
[ 7] 25.01-26.01 sec 532 KBytes 4.36 Mbits/sec
[ 7] 26.01-27.01 sec 1.09 MBytes 9.09 Mbits/sec
[ 7] 27.01-28.01 sec 1.31 MBytes 11.0 Mbits/sec
[ 7] 28.01-29.00 sec 1.49 MBytes 12.6 Mbits/sec
[ 7] 29.00-30.01 sec 3.77 MBytes 31.4 Mbits/sec
[ 7] 30.01-30.10 sec 761 KBytes 68.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-30.10 sec 98.1 MBytes 27.3 Mbits/sec receiver

Immediately after reboot below. Note this would be much higher normally, but I've suspiciously set channel bandwidth to 20mHz. I will probably switch it back to 40 or 80, as this doesn't seem to be the problem.

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.1.149, port 52387
[ 7] local 10.0.1.105 port 5201 connected to 10.0.1.149 port 52388
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 16.0 MBytes 134 Mbits/sec
[ 7] 1.00-2.00 sec 16.8 MBytes 141 Mbits/sec
[ 7] 2.00-3.00 sec 16.8 MBytes 141 Mbits/sec
[ 7] 3.00-4.00 sec 14.4 MBytes 120 Mbits/sec
[ 7] 4.00-5.00 sec 14.2 MBytes 119 Mbits/sec
[ 7] 5.00-6.00 sec 13.1 MBytes 109 Mbits/sec
[ 7] 6.00-6.46 sec 6.60 MBytes 119 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-6.46 sec 97.7 MBytes 127 Mbits/sec receiver

I switched 5gHz back to 20/40/80 and about the same. I assume I will always have this limitation due to my location near the airport which gives me limited 5gHz channels. Not a problem, this is fine for browsing on an iPad!

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.1.149, port 52470
[ 7] local 10.0.1.105 port 5201 connected to 10.0.1.149 port 52471
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 15.7 MBytes 131 Mbits/sec
[ 7] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec
[ 7] 2.00-3.00 sec 16.5 MBytes 138 Mbits/sec
[ 7] 3.00-4.00 sec 16.4 MBytes 137 Mbits/sec
[ 7] 4.00-5.00 sec 16.3 MBytes 137 Mbits/sec
[ 7] 5.00-5.99 sec 16.6 MBytes 141 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-5.99 sec 97.7 MBytes 137 Mbits/sec receiver

You say you want to figure it out... that could require circuit debugging.

Given a reboot clears it for awhile and you've had the issue for years, I would just try/buy another router and expect to be done with the problem.

OE

 

[jtara]

So, my 2012 Mac Mini SSD failed totally recently (I'd long ago replaced the Fusion Drive), I decided to re-thermal paste it, since replacing the drive required that I remove the MB from the case anyway. I did some research, and used Thermal Grizzly Kryonaut. Geez, Apple goops so much compound, and it was rock hard! The results were impressive - I hardly ever hear the fan now, and when I do it ramps back down quickly.

So, inspired by that, I decided to re-do my RT-AC88U as well.

Results were equally impressive!

My temps from earlier in this thread:

- 2.4gHz 49C
- 5gHz 49C
- CPU 78C

Current temps, after an hour of operation - with ALL services that I'd disabled in a vain attempt to lower temps now re-enabled (QOS, traffic analysis, etc.):

- 2.4gHz 43C
- 5gHz 49C
- CPU 67C

Sorry, I didn't take any pictures.... If you do this, find a video or two on how to open the case - it is a b**th, and you will need a supply of spudgers. I say a SUPPLY, because you will bend the heck out of the spudger in the process and need at least a second fresh one to complete opening the case. You have to go around and pop all the clips, and you really need to study photos/videos to see where they are. The pattern is different between front/back/sides.

The CPU assembly had a pad down the center going the long way of the rectangular package. The radios both had 3 pads, one larger one near top/middle, and two smaller ones below - again with quite a bit of surface area uncovered. The pads did not seem dried-out.

It was not practical to use the Kryonaut, because of cost (I would have cost something like $100!) and because of risk of inauthentic product. Reading reviews, the larger sizes of the Kryonaut are very often knockoff goods. (Understandable, given the price.) For the Mac Mini I only needed one of the tiny 1g tubes, which I got from Amazon "sold and shipped by Amazon". I just did not trust the Marketplace sellers because of too many reviews indicating fake goods.

So, I used Arctic MX-4 2019 edition. I bought two large 20g tubes. (I have other projects...) It took nearly one whole tube! I did have to buy on Amazon Marketplace, and I posted a negative review, because of "suspicious packaging". The vendor had covered QR and bar codes on the boxes with their own sticker that you can't remove without obscuring the underlying codes. Arctic is running a lottery where you might win $1000. I suspect the vendor scans them then covers the contest QR code (and other codes) with the sticker to avoid detection when some customer tries to claim an already-won prize. Or it's just fake.

Why did it take nearly a whole 20g tube? Because the mounting standoffs were designed for the pads. The heatsinks to NOT touch the metal surfaces of the modules. I briefly considered grinding them down with a dremel, but considered too much risk of creating a short with metal fragments, and/or crushing some internal components in the packages.

I cleaned the sinks and packages thoroughly with 99.7% isopropyl, "pre-loaded" the heatsinks by spreading some compound and then wiping off with Kimwipes. You can clearly see the fill of the fairly rough surface of the pads after wiping off. I marked off the area on the heatsinks where the flat surface does NOT contact the packages, and avoided spreading compound there. I used the spreading to spread a pretty thick, even coating, and then put some piles in the middle of where the pads had been. After placing the heatsinks down, I "wiggled" the a bit, and made sure there was adhesion. (Not enough goop, and they will just lift right off with no compound sticking to the heatsinks, due to the height of the mounting standoffs.)

So, I had to make-do with a thick goop of compound! I know this is not ideal - the compound is meant to fill tiny flaws and application should be as thin as practical. But these packages do not have the polished surfaces of Intel CPU chips - they are all multi-chip modules, and you can actually see bulges in the (soldered-on) covers, as well! I don't know what the thermal design is inside the package - whether for example there are internal pads that I can't do anything about without desoldering the caps, for which I do not have the equipment.

I realize there are multiple posts that suggest that my original temperatures are fine. But also some that suggest that while it may be find for the radio/CPU packages themselves, maybe not for surrounding components.

As far as pads/vs compound, I've come across some reviews of some of the very latest pads that state that they "work nearly as well as low-end compound". So, even if there wasn't any issue with drying-out of the pads, still one should expect compound (especially high-end) to do a better job. And certainly ASUS didn't use high-end pads, and couldn't have used pads that have only come on the market in the past couple of years.

IMPORTANT: Do not use metallic compound such as Arctic Silver! Use only a non-conductive, non-capacitive compound! You WILL inevitably get some on the board, nearby contacts, etc. There is too much covered up with the heat sinks and you will not be able to see what has happened underneath with squeezed-out compound!

I will report back after a few days. If it doesn't go into it's squirrely bandwidth-limited mode, the operation will have been a success!

My best guess is overheating some some component in the vicinity of the CPU/CPU heatsink. The radios aren't that much cooler than they were (5gHz is the same, but 2.4 is notably cooler).

The failure mode I'd been experiencing is odd indeed. Throttling of both radios, yet never seen any problem at all with throughput between wired LAN and WAN.

Really did not want to buy a new router right now. Would like to stretch this one a bit more. I really would like to go with a pfSense box for the WAN, along with some tasteful-looking multi-node setup that are getting more popular. AX is just too new right now, do not want to spend the bug bucks on some early AX router that looks like a kids gaming rig.

 

[follower]

So, my 2012 Mac Mini SSD failed totally recently (I'd long ago replaced the Fusion Drive), I decided to re-thermal paste it, since replacing the drive required that I remove the MB from the case anyway. I did some research, and used Thermal Grizzly Kryonaut. Geez, Apple goops so much compound, and it was rock hard! The results were impressive - I hardly ever hear the fan now, and when I do it ramps back down quickly.

So, inspired by that, I decided to re-do my RT-AC88U as well.

Results were equally impressive!

My temps from earlier in this thread:

- 2.4gHz 49C
- 5gHz 49C
- CPU 78C

Current temps, after an hour of operation - with ALL services that I'd disabled in a vain attempt to lower temps now re-enabled (QOS, traffic analysis, etc.):

- 2.4gHz 43C
- 5gHz 49C
- CPU 67C

Sorry, I didn't take any pictures.... If you do this, find a video or two on how to open the case - it is a b**th, and you will need a supply of spudgers. I say a SUPPLY, because you will bend the heck out of the spudger in the process and need at least a second fresh one to complete opening the case. You have to go around and pop all the clips, and you really need to study photos/videos to see where they are. The pattern is different between front/back/sides.

The CPU assembly had a pad down the center going the long way of the rectangular package. The radios both had 3 pads, one larger one near top/middle, and two smaller ones below - again with quite a bit of surface area uncovered. The pads did not seem dried-out.

It was not practical to use the Kryonaut, because of cost (I would have cost something like $100!) and because of risk of inauthentic product. Reading reviews, the larger sizes of the Kryonaut are very often knockoff goods. (Understandable, given the price.) For the Mac Mini I only needed one of the tiny 1g tubes, which I got from Amazon "sold and shipped by Amazon". I just did not trust the Marketplace sellers because of too many reviews indicating fake goods.

So, I used Arctic MX-4 2019 edition. I bought two large 20g tubes. (I have other projects...) It took nearly one whole tube! I did have to buy on Amazon Marketplace, and I posted a negative review, because of "suspicious packaging". The vendor had covered QR and bar codes on the boxes with their own sticker that you can't remove without obscuring the underlying codes. Arctic is running a lottery where you might win $1000. I suspect the vendor scans them then covers the contest QR code (and other codes) with the sticker to avoid detection when some customer tries to claim an already-won prize. Or it's just fake.

Why did it take nearly a whole 20g tube? Because the mounting standoffs were designed for the pads. The heatsinks to NOT touch the metal surfaces of the modules. I briefly considered grinding them down with a dremel, but considered too much risk of creating a short with metal fragments, and/or crushing some internal components in the packages.

I cleaned the sinks and packages thoroughly with 99.7% isopropyl, "pre-loaded" the heatsinks by spreading some compound and then wiping off with Kimwipes. You can clearly see the fill of the fairly rough surface of the pads after wiping off. I marked off the area on the heatsinks where the flat surface does NOT contact the packages, and avoided spreading compound there. I used the spreading to spread a pretty thick, even coating, and then put some piles in the middle of where the pads had been. After placing the heatsinks down, I "wiggled" the a bit, and made sure there was adhesion. (Not enough goop, and they will just lift right off with no compound sticking to the heatsinks, due to the height of the mounting standoffs.)

So, I had to make-do with a thick goop of compound! I know this is not ideal - the compound is meant to fill tiny flaws and application should be as thin as practical. But these packages do not have the polished surfaces of Intel CPU chips - they are all multi-chip modules, and you can actually see bulges in the (soldered-on) covers, as well! I don't know what the thermal design is inside the package - whether for example there are internal pads that I can't do anything about without desoldering the caps, for which I do not have the equipment.

I realize there are multiple posts that suggest that my original temperatures are fine. But also some that suggest that while it may be find for the radio/CPU packages themselves, maybe not for surrounding components.

As far as pads/vs compound, I've come across some reviews of some of the very latest pads that state that they "work nearly as well as low-end compound". So, even if there wasn't any issue with drying-out of the pads, still one should expect compound (especially high-end) to do a better job. And certainly ASUS didn't use high-end pads, and couldn't have used pads that have only come on the market in the past couple of years.

IMPORTANT: Do not use metallic compound such as Arctic Silver! Use only a non-conductive, non-capacitive compound! You WILL inevitably get some on the board, nearby contacts, etc. There is too much covered up with the heat sinks and you will not be able to see what has happened underneath with squeezed-out compound!

I will report back after a few days. If it doesn't go into it's squirrely bandwidth-limited mode, the operation will have been a success!

My best guess is overheating some some component in the vicinity of the CPU/CPU heatsink. The radios aren't that much cooler than they were (5gHz is the same, but 2.4 is notably cooler).

The failure mode I'd been experiencing is odd indeed. Throttling of both radios, yet never seen any problem at all with throughput between wired LAN and WAN.

Really did not want to buy a new router right now. Would like to stretch this one a bit more. I really would like to go with a pfSense box for the WAN, along with some tasteful-looking multi-node setup that are getting more popular. AX is just too new right now, do not want to spend the bug bucks on some early AX router that looks like a kids gaming rig.

Why don't you use cooling fans? I think cooling fans are enough.

 

[jtara]

Why don't you use cooling fans? I think cooling fans are enough.

Because I wouldn't want to listen to it.

The router is in an elevated position about two feet from my right ear and at the same height as I sit. And that's my GOOD ear! I also wouldn't want others to have to listen to it on teleconferences.

Plus, I don't like using "redneck repairs" unless I have exhausted more proper solution. If some maintenance will fix it, I'd prefer to leave the duct tape in the toolbox.

Temperatures have remained stable overnight - 43/49/66 and no throttling has occurred.

If it goes a week, I will deem the problem solved, as it was getting so bad it would go without the throttling for more than a couple hours.

Genuine or not, the MX-4 is clearly keeping the CPU and 2.4gHz radio cooler than the pads. Curious about 5gHz at the same temp. The radios are in separate cans, and as no assembly operation is perfect, likely at slightly different heights. Maybe even more goop needed on the 5gHz.

Maybe somebody who stumbles through here will try a "grind the top off of the mounting studs" hack, so that such a thick application is not needed.

BTW, I asked a friend who is a materials scientist about the limited coverage of the pads. (Only down the center on the CPU, and 3 pads I assume over heat-generating components on the radios). He's worked in electronics packaging (for Kyocera, and others), and is an expert on metal-ceramic interfaces. (I once picked up an odd item in his spare-bedroom office bathroom, that had a tile saw in the tub. I asked him what it was. It was an experimental Space Shuttle tile!) I asked him if he thought there was any NEGATIVE to full coverage, vs selective coverage. I had a thought that perhaps Asus avoided full coverage because they didn't want the pad conducting heat across to some other part of the package surface. He suggested that the lack of full coverage was just a cost-saving measure, pads come in standard sizes, avoid an extra manufacturing step punching out a custom shape, etc.