Nighthawk RAXE300 vs TP-Link Archer AX6000 vs TP-Link Deco P9

After my previous post where I compared the TP-Link Archer AX6000, MSI RadiX AXE6600, and TP-Link Deco P9, I decided to sell the MSI RadiX AXE6000. I was happy with the Archer AX6000, but sometimes our Samsung Galaxy S22 and S24 devices lost their connection, while 30 other devices on the same network were fine. Even the Galaxy A13/A15 phones were fine. After troubleshooting, I could not figure out it. With the age of the AX6000, I didn't expect a firmware update would help, so on eBay I bought a Netgear Nighthawk RAXE300 6e on a good deal. It was newer, so I expected better compatability.

Attribute	Netgear RAXE300	TP-Link AX6000	TP-Link Deco P9
Brand	Netgear	TP-Link	TP-Link
Model	RAXE300	AX6000	Deco P9
Paid Price	$92.46 in 2024, eBay used	$63.49 in 2024, eBay used	$250.00 in 2020, new
Wi-Fi Generation	6E	6	5
Beamforming	Yes	Yes	Yes
Streams	2/4/2	4/4/0	MU-MIMO
Antennas	6	8	2
2.5 Gbps LAN Ports	1	1	0 per unit
1 Gbps LAN Ports	5	8	2 per unit

Testing Setup

All tests were conducted using iperf3, connected to an OpenWRT router over 1 Gbps ethernet. I ran iperf3 on the OpenWRT router as the server, and two client devices (a Galaxy S24 and a Dell Precision 3570) at different locations. I repeated most test three times and averaged the results, though some were two or four times. I chose iperf3 to avoid confounding effects of WAN performance. In iperf3 terminology, the normal mode, which I call forward, uploads from the client to the server, and reverse mode downloads from server to client. I did all tests November 2024.

Close range

Close range testing gives us information about ideal connections, not worrying about distance or barriers like walls and floors. It sets a benchmark for tests at farther distances.

Access Point	Client	Band	Ping Jitter (ms)	Ping Avg (ms)	iperf Forward (Mbps)	iperf Reverse (Mbps)
Nighthawk RAXE300	Galaxy S24	6 GHz	7.8	18.3	811	831
Nighthawk RAXE300	Galaxy S24	5 GHz	10.3	21.7	556	738
Nighthawk RAXE300	Galaxy S24	2.4 GHz	20.0	29.7	56	64
TP-Link Archer AX6000	Galaxy S24	5 GHz	8.0	14.7	503	752
TP-Link Archer AX6000	Galaxy S24	2.4 GHz	18.5	28.0	78	75
TP-Link Deco P9	Galaxy S24	5 GHz	8.5	17.5	243	389
TP-Link Deco P9	Galaxy S24	2.4 GHz	36.5	48.5	13	16
Nighthawk RAXE300	Dell Precision 3570	5 GHz		8.0	331	320
TP-Link Archer AX6000	Dell Precision 3570	5 GHz		3.0	500	377
TP-Link Deco P9	Dell Precision 3570	5 GHz		4.0	306	296

• Nighthawk RAXE300 Leads on 6 GHz: The Nighthawk RAXE300 demonstrated the highest average throughput with the Galaxy S24 in both forward (811 Mbps) and reverse (831 Mbps) directions when connected to the 6 GHz band. This highlights the potential of the newer 6 GHz technology for close-range, high-bandwidth applications. However, even in 2025, few of my devices support 6 GHz.
• Competitive 5 GHz Performance: 5 GHz performance is the most significant because that's the primary band for most of my non-IOT devices. Both the Nighthawk RAXE300 and the TP-Link Archer AX6000 showed strong performance on the 5 GHz band. However, the Galaxy S24 exhibited concerningly higher average ping times with the Nighthawk RAXE300 (21.7 ms) and TP-Link Deco P9 (17.5 ms) compared to the Archer AX6000 (14.7 ms). This echoes a pattern I've observed previously, where Galaxy S24 devices seem to have poor ping times (see this Reddit thread). When focusing on ping times for the Dell laptop, which better represents ping for most devices, the Nighthawk had a worse average ping (8ms) than the other two APs (3 ms for Archer AX6000 and 4 ms for Deco P9). In terms of throughput on 5 GHz, the Archer AX6000 averaged 503 Mbps forward and 752 Mbps reverse with the Galaxy S24, compared to the RAXE300's 556 Mbps forward and 738 Mbps reverse. With the Dell laptop, the Archer AX6000 had better throughput than the RAXE300.
• Deco P9 Lagging on 5 GHz: The TP-Link Deco P9 showed noticeably lower average throughput on the 5 GHz band (243 Mbps forward, 389 Mbps reverse with the Galaxy S24; 306 Mbps forward, 296 Mbps reverse with the Dell Precision 3570) compared to the other two access points.
• Lower 2.4 GHz Performance Across the Board: As expected, all three access points exhibited significantly lower throughput on the 2.4 GHz band compared to the 5 GHz and 6 GHz bands. The TP-Link Deco P9 had the lowest performance on 2.4 GHz among the three with the Galaxy S24.

Corner in basement

The following table summarizes the performance in a corner of my basement where my son has his PC, but it's where wi-fi has a poor signal.

```html

Performance Testing Results - Basement NE Corner (Nov 3, 2024)

Access Point	Band	Avg Ping (ms)	iperf Forward (Mbps)	iperf Reverse (Mbps)
Nighthawk RAXE300	6 GHz	49.3	15	104
Nighthawk RAXE300	5 GHz	23.3	211	279
TP-Link Archer AX6000	5 GHz	17.4	146	288
TP-Link Deco P9	5 GHz	18.5	87	143

• Of all the APs, the Nighthawk suffered the most ping performance compared to close range. Also at the same locaiton, the Nighthawk had the worse ping, especially on 6GHz.
• Likewise, performance on the 6 GHz suffered the most in the basement compared to close range.
• Performance on 5 GHz was acceptable on the Nighthawk and Archer.

Access Point	Band	Avg Ping (ms)	iperf Forward (Mbps)	iperf Reverse (Mbps)
Nighthawk RAXE300	2.4 GHz	38.4	22.74	28.66
TP-Link Archer AX6000	2.4 GHz	33.2	38.55	44.8714
TP-Link Deco P9	2.4 GHz	56.75	12.95	11.515

• Compared to close range at 2.4 GHz, all metrics suffered, as expected because of the physical barriers.
• The Archer AX6000 suffered the least lost compared to close range at 2.4 GHz.
• Both the Nighthawk and Archer had acceptable performance when tested on the driveway.

Conclusion

These tests gave me the data to finally say goodbye to my Deco P9, which I sold for a good price on Nextdoor. It makes me wonder in general the value of any mesh network. If you have wi-fi issues, don't count on a mesh network to fix them.

While the newer Netgear Nighthawk did not consistently outperform the Archer, I gave the Archer to a family member who moved into a new place. Her phone did not have the comptability issues I had with the Archer. I've been using the Netgear Nighthawk AXE600 for over six months, and I am pleased with it.

Get HTML of iframes in Microsoft Playwright

Playwright is a powerful framework for web testing and automation. This article demonstrates how to extract the HTML content of child IFRAMEs within a webpage using Python and Playwright.

Installation

To use Playwright in your Python project, you'll need to install it using pip:

pip install playwright
playwright install

Python Code

Here's the Python code:

import asyncio
from playwright.async_api import async_playwright, Frame

async def main():
  """
  This function retrieves the HTML content of each child iframe on a webpage.
  """
  async with async_playwright() as p:
    browser = await p.chromium.launch(headless=False)
    page = await browser.new_page()
    url = "https://interactive-examples.mdn.mozilla.net/pages/tabbed/iframe.html"
    await page.goto(url)

    # Wait for page to load and iframes to be rendered
    await page.wait_for_load_state("networkidle")

    for frame in page.frames:
      if not frame.url.startswith("http"):
        # May start with "about:"
        print(f'{frame.url}: Not a valid URL')
        continue
      if frame.url == url:
        print(f'{frame.url}: Skipping parent')
        continue
      print(f'{frame.url}: content below')
      print('*' * 80)
      content = await frame.content()
      print(content)
      print('*' * 80)

    await browser.close()

asyncio.run(main())

Snowflake SQL error: NULL result in a non-nullable column

Troubleshooting Snowflake SQL Error : NULL result in a non-nullable column

When working with Snowflake, you might encounter the error message:

SQL Error [100072] [22000]: NULL result in a non-nullable column

This error can be misleading at first glance. Let's walk through a common scenario that triggers this error and how to resolve it.

Scenario

Consider the following SQL script:

-- Create the test table
CREATE TABLE set_test (
    id INT NOT NULL,
    is_deleted CHAR(1) NOT NULL,
    foo FLOAT NULL
);

-- Insert a few records
INSERT INTO set_test (id, is_deleted, foo) VALUES
(1, 'F', 10.5),
(2, 'F', 20.0),
(3, 'F', 30.75);

-- Update one record to set is_deleted to 'T' and foo to NULL
UPDATE set_test
SET is_deleted = 'T' and foo = NULL
WHERE id = 2;

When you run the UPDATE statement, Snowflake returns the error message:

SQL Error [100072] [22000]: NULL result in a non-nullable column

Understanding the Error

The error message indicates that there is an attempt to insert a NULL value into a column that does not allow NULL values. However, in this case, the error is not due to the NULL value itself but rather a syntax issue in the UPDATE statement.

Resolving the Error

The issue lies in the UPDATE statement:

UPDATE set_test
SET is_deleted = 'T' and foo = NULL
WHERE id = 2;

In SQL, the SET clause should use commas to separate multiple column assignments, not the AND keyword. The correct UPDATE statement should be:

UPDATE set_test
SET is_deleted = 'T', foo = NULL
WHERE id = 2;

By replacing and with a comma, the UPDATE statement will execute without errors:

UPDATE set_test
SET is_deleted = 'T', foo = NULL
WHERE id = 2;

Conclusion

When you encounter the "NULL result in a non-nullable column" error in Snowflake, double-check the syntax of your UPDATE statement. Ensure that you are using commas to separate column assignments in the SET clause. This simple fix can save you time and prevent confusion when troubleshooting SQL errors.

If this does not help, see also Snowflake KB Inserting or loading data in table fails with error "NULL result in a non-nullable column".

TP-Link Archer AX6000 vs MSI RadiX AXE6600 vs TP Link Deco P9

I had my TP Link Deco P9 (Wi-Fi 5 from 2019) system with three mesh nodes since 2020, but I was not thrilled with its performance. In 2022, I complained to TP Link support, but they did not help, so now I compared the Deco P9 to a MSI RadiX AXE6600 (Wi-Fi 6e from 2023) and TP-Link Archer AX6000 (Wi-Fi 6 from 2018). In 2020, I paid $250 for the Deco. In 2024, I bought the MSI used for $133.89 and the Archer for $63.49. Do not confuse the RadiX AXE6600 (Wi-Fi 6e) with AX6000 (Wi-FI 6): even Google Search mixes them up.

Attribute	MSI RadiX AXE6600	TP-Link AX6000	TP-Link Deco P9
Brand	MSI	TP-Link	TP-Link
Model	RadiX AXE6600	AX6000	Deco P9
Paid Price	$133.89 in 2024, Amazon used	$63.49 in 2024, ebay	$250.00 in 2020, new
Wi-Fi Generation	6E	6	5
Beamforming	Yes	Yes	Yes
Streams	2/2/4	4/4/0	MU-MIMO
Antennas	6	8	2
2.5 Gbps LAN Ports	1	1	0 per unit
1 Gbps LAN Ports	4	8	2 per unit

For preformance testing, the Wi-Fi systems were set to AP mode and hard wired over 1 Gbps Ethernet to a Belkin RT3200 running OpenWRT, functioning as an iperf3 server to test LAN performance not confounded by an ISP. The MSI was set to 80 MHz on the 5 GHz band (the maximum) and 160 MHz on the 6 GHz band. The Archer was set to 80 MHz on the 5 GHz band. The Archer can do 160 MHz, though the setting was hard to find, and in other testing, it did not make a big difference at close range.

With iperf3 in default mode, the client sends (i.e., uploads): I call this forward mode. In reverse mode, the client receives (i.e., downloads). I used the PingTools Android app for iperf3 and PingMon app for ICMP ping.

The network client was usually a Samsung Galaxy S24 (Wi-Fi 6e) smartphone, but a few tests were done with a Galaxy A15 (Wi-Fi 5), which is a much cheaper phone.

Performance at close range

I began by testing at close range, which represents the ideal scenario for Wi-Fi. In this test, the Deco P9 was a satellite hard-wired to the primary Deco.

Here the MSI RadiX AXE6600 outperformed the others on the 5 GHz band, and as you would expect, the MSI performance on the 6 GHz band was even better than the MSI on 5 GHz.

Strangely, the cheaper Galaxy A15 had much better latency than the Galaxy S24, though the Galaxy S24 performed better than the Galaxy A15 on bandwidth tests, which is expected because the Galaxy S24 supports a newer generation of Wi-Fi.

Access Point	Band	Client	Ping avg ms	iperf forward Mbps<	iperf reverse Mbps
MSI RadiX AXE6600	6 GHz	Galaxy S24	16	777	909
MSI RadiX AXE6600	5 GHz	Galaxy S24	18	578	716
TP-Link Archer AX6000	5 GHz	Galaxy S24	17	617	760
MSI RadiX AXE6600	5 GHz	Galaxy a15	3	314	338
TP-Link Archer AX6000	5 GHz	Galaxy a15	4	334	312
Deco P9	5 GHz	Galaxy a15	4	277	289
Deco P9	5 GHz	Galaxy S24	16	307	472

Indoors, far away

Next, I tested with the phones in a part of the house with poor network coverage. I limited testing to 5 GHz because this location has a desktop computer that uses only 5 GHz.

In a reversal from the close-range testing, the TP-Link Archer outperformed the other access points.

Access Point	Band	Ping Avg MS	Iperf Forward (Mbps)	Iperf Reverse (Mbps)
MSI RadiX AXE6600	6 GHz	27	78	199
MSI RadiX AXE6600	5 GHz	37	30	34
TP-Link Archer AX6000	5 GHz	18	94	318
TP-Link Deco P9	5 GHz	19	41	70

Outdoor

My final test was outdoors where I use a 2.4 GHz camera and 5 GHz phones, so I tested all bands.

I was surprised the 6 GHz worked outside, and it was still fast. The Archer outperformed the other APs on the 2.4 GHz band, and like in the last test, also on the 5 GHz band.

Access Point	Band	Ping Avg MS	iperf Forward (Mbps)	iperf Reverse (Mbps)
MSI RadiX AXE6600	6 GHz		261	558
MSI RadiX AXE6600	5 GHz	67	38	228
TP-Link Archer AX6000	5 GHz	20	303	431
MSI RadiX AXE6600	2.4 GHz	36	6	21
TP-Link Archer AX6000	2.4 GHz	38	28	22
TP-Link Deco P9	2.4 GHz	37	8	17

Other thoughts

The MSI RadiX AXE6600 has a good web interface for viewing system information and changing settings, but the MSI app never logged in for me. When my netmask was 255.0.0.0 the MSI would go into a loop, using all memory, and invoking the OOM killer, so I changed the netmask as a workaround. The MSI made 172800 DNS queries per day, which is excessive.

The Archer's Tether app is spartan with little information and few settings. The Archer has much more info and settings available through its web interface than the Tether app. While the Deco app is the better than Tether, I was annoyed by the slow refresh rates and the lack of a time series display for the network usage.

The MSI 6 GHz band performed well outside and throughout the house, so it makes a credible use case as a high-performance backhaul for Wi-Fi 6e mesh systems.

Achieving gigabit performance on these Wi-Fi systems was rare, so it makes a case against paying for high speed ISPs faster than gigabit. Devices like the Galaxy A13 could not even use half of a gigabit Internet plan.

Conclusion

Despite its age, I decided to keep the TP-Link Archer and sell the Deco P9 and MSI RadiX because the Archer performed best throughout the house and outdoors. It was a surprise that a single device, the Archer, could outperform the three units of the Deco's mesh system, and the Archer was also the oldest, outperforming the newest, which was the MSI. For me, consistent performance across my house and outdoors was more important than fastest speeds at close range. I discounted performance on the 6 GHz band (MSI) because few of my devices have a 6 GHz band: many of my devices are IoT devices that support only 2.4 GHz, while other devices are Wi-Fi 4 and Wi-Fi 5 on 5 GHz. The Archer has more than enough bandwidth to support my DSL ISP.

I bought a dashcam from Temu for $6.31 January 2024, and here is sample footage that includes three scenes: daytime, dusk, and daytime.

Product benefits

• Easy mounting with suction cup
• Easy power with 12V cigarette plug adapter
• Battery lasts a few moments after car turns off
• MicroSD card included
• Cheap price

Problems

• Cheap quality
• Terrible video quality (despite product description)
• Narrow field of view (despite product description)

Notes

• It was a weird choice for it record in .avi instead of .mp4 container.
• The product was discontinued on Temu.

Model (box): Y320
Manufacturer (box): shenzhen Hengxin Weiye Digital Co., LTD
Product title (Temu):
Dash Camera For Cars With 32G Memory Cards Wide Angle Full 1080P Driving Record...

Below is the product menu (PDF on Temu):
Intelligent voice reminder, built-in multinational voice pronunciation, no need to worry about language barriers 1080P highdefinition night vision, even in the weak light environment, can also shoot clearly Loop recording, no missing seconds, segmented storage, automatic monitoring of sto rage space, when the memory is full, automatically delete the earliest recorded video and save the new video Builtin gravity sensor, when a sudden brake or collision is sensed, the current video is instantly locked to prevent overwriting important files during loop recording Supported languages: English, French, German, Russian, Japanese, etc.

Timestamp precision in Snowflake

Timestamps in Snowflake have precisions 0 to 9 with a default of 9, which is a nanosecond, but the Snowflake documentation is not clear on precisions 0 to 8.

Storage difference

I did an empircal test by creating tables. Each table had one million rows and one column with random timestamps. The values have an original precison of one nanosecond, and I used random values because otherwise Snowflake would compress down any number of rows with the same values to a few KB.

create or replace table zzz_timestamp9 as
select dateadd(nanosecond, uniform(1,3e17, random()), current_timestamp())::timestamp(9) as time1
from TABLE(GENERATOR(ROWCOUNT => 1e6))
;
create or replace table zzz_timestamp0 as
select dateadd(nanosecond, uniform(1,3e17, random()), current_timestamp())::timestamp(0) as time1
from TABLE(GENERATOR(ROWCOUNT => 1e6))
;

The storage difference for 1 million rows was 3.5MB vs 7.0MB.

Precision difference

Again, I generated random rows and then copied the value into columns with varied precisions.

select
    dateadd(nanosecond, uniform(1,3e17, random()), current_timestamp())::timestamp(9) as "precision 9",
    "precision 9"::timestamp(3) as "precision 3",
    "precision 9"::timestamp(2) as "precision 2",
    "precision 9"::timestamp(1) as "precision 1",
    "precision 9"::timestamp(0) as "precision 0",
    datediff(ms, "precision 3", "precision 9") as "Precisions 9 vs 3 in milliseconds", /* alwayz zero */
    datediff(second, "precision 0", "precision 9") as "Precisions 9 vs 0 in seconds" /* alwayz zero */
from TABLE(GENERATOR(ROWCOUNT => 10))

Precision 0 is 1 second, precision 1 is 100 ms, precision 2 is 10 ms, precision 3 is 1 ms, etc.

openwrt ssh connection refused

Symptom

Normal connection attempt

$ ssh root@192.168.1.1
Connection to 192.168.1.1 closed.

End of log with verbose ssh

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/z/.ssh/id_ed25519 ED25519 SHA256:XX//XX/XX agent
debug1: Server accepts key: /home/z/.ssh/id_ed25519 ED25519 SHA256:XX//XX/XX agent
Authenticated to 192.168.1.1 ([192.168.1.1]:22) using "publickey".
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.1.1 closed.
Transferred: sent 2488, received 1012 bytes, in 0.0 seconds
Bytes per second: sent 346691.3, received 141017.5
debug1: Exit status 1

System log snippet in OpenWRT's luci interface

Sat May 20 23:02:33 2023 authpriv.notice dropbear[7690]: Pubkey auth succeeded for 'root' with ssh-ed25519 key SHA256:XX//XX/XX from 192.168.1.X:X
Sat May 20 23:02:33 2023 authpriv.info dropbear[7691]: Exit (root) from <192.168.1.X:X>: Child failed
Sat May 20 23:02:33 2023 authpriv.info dropbear[7690]: Exit (root) from <192.168.1.X:X>: Disconnect received

Background

A few weeks ago, I installed OpenWRT 22.03.3 on my Belkin RT3200. SSH and everything else was working fine until I updated it to OpenWRT 22.03.5, and then immedietly SSH refused to connect.

Solution

I read a GitHub conversation about a similar problem. In their case, zsh was missing, and I remembered that earlier I installed Bash. I reinstalled it via LuCI, and then SSH worked again.