NAS upgrades: Proprietary lockouts and surmounts

A speedier LAN “freeway” is of no benefit if “vehicles” on it are still molasses slow. Fortunately, this engineer’s curiosity is matched by upgrades both available used and already in inventory.

As part of my pending infrastructure upgrade, one of the key LAN clients that I want to make sure is accessible as speedily as possible, as well as generally performing as optimally as possible, is my longstanding-use quad-HDD QNAP TS-453Be NAS:

The TS-453Be has dual integrated 1 GbE wired interfaces, only one of which I’m currently using due to my current switch’s available port count limitations.

That said, I’ve long been tempted to add an active splitter to the mix, as the NAS’s Linux O/S foundation supports two different multi-LAN interface merging options: specialized Port Trunking, i.e., LACP (Link Aggregation Control Protocol), which necessitates the use of a high-end managed switch, and the more general-purpose SMB Multichannel alternative approach.

However, since I was planning on more broadly moving to a primary switch that included multiple 10G SFP+ cages, each optionally configurable as a 10 GbE port via an Ethernet adapter module, I decided to instead “go for the gusto” and use a PCIe add-in board to upgrade the TS-453Be to use a single 10 GbE interface. QNAP sells such a card, the QXG10G1T, which has a $139 MSRP although, due to supply constraints, many retailers currently sell it for $200 or more (AQUANTIA, the board’s network controller supplier, was acquired by Marvell seven years ago).

Bracket barrier

Instead, however, and after stumbling across an encouraging Reddit thread, I (at least initially) decided to alternatively go with a much less expensive generic AQUANTIA AQC107-based add-in card sourced from Walmart’s website.

The Reddit thread discussion suggested that there was no difference between ones like it and the pricier branded card, at least from a software driver standpoint. QNAP hadn’t hard-coded a specific identifier code into the card’s firmware, for example, and therefore hadn’t customized the Linux build it was using to recognize only that code as valid. This was a refreshing change from the usual norm taken by some SFP-supportive networking equipment suppliers, for example.

But when the board arrived, I realized that I still couldn’t let QNAP off the “proprietary” hook scot-free. The earlier QXG10G1T stock photos showed the board with only its preinstalled low-profile bracket, variants of which I’d also come across in the past with low-profile graphics cards, for example.

 

The QNAP product page also mentioned the inclusion of a full-height conventional bracket. And it further referenced an also-bundled “specialized (for selected QNAP NAS) bracket”, photos of all of which I happened to find included with a used-board eBay listing I came across.

The latter bracket, unfortunately, is the one that the QNAP TS-453Be calls for. Unsurprisingly, it was not included with the generic AQC107-based add-in card I’d bought, or any other I could find.

I also couldn’t find any means of purchasing the proprietary flat low-profile bracket from QNAP directly. Perhaps obviously, I assume that the company would prefer that I instead buy the entire kit from it.

Investigation prior to capitulation

I could hack away at the standard low-profile bracket to jerry-rig it into place, as I belatedly realized upon re-read that the original Reddit thread originator had done (I’d originally misinterpreted that he’d only had the full-height bracket in his possession). Or, I suppose, I could 3D-print one. What I confess I just ended up doing instead was bailing and buying that used board I’d found on eBay, which thankfully works fine and still saved me a notable amount of coin versus the MSRP, not to mention the subsequent (and current) further marked-up prices (the screenshot still reports 1 GbE connectivity because of the legacy switch on the other cable end).

I’ve kept the generic add-in card, too, for use in adding 10 GbE support to future Macs, Hackintoshes and/or PCs, along with any more amenable NASs that might come into my possession in the future. And, prior to settling on the used QNAP-branded card, I temporarily installed the generic one in the NAS after first removing its mounting bracket entirely, to personally confirm what I’d already read re its claimed software compatibility.

Here’s where the add-in card goes.

Cue irony; the dimple on the included standard low-profile bracket’s 90° bent end exactly matches the location of the drilled hole in the (flat) cover plate, suggestive of a likely chassis location match were I to drill a hole at the dimple, too. The problem, of course, is that even if I could cleanly un-bend that end, it’d still protrude beyond the remainder of the bracket’s edge. It wouldn’t fit in the chassis unless I also hacksawed or otherwise dealt with the bracket excess.

Absent the bracket, the add-in card is fully functional, albeit tenuously so from a mechanical stability (therefore also electrical connectivity) perspective.

The only quirk I came across, which ironically also affects the QNAP-branded board, is that the front panel LED only activity-illuminates when the integrated 1 GbE facilities are in use, not those of the 10 GbE add-in card.

Other networking options

What about the NAS’s five integrated USB 3.2 Gen 1 (5 Gbps) ports (one front, four back)? Instead of using a full-blown add-in card, could I instead connect up one or even a few (for multi-LAN interface merging purposes) 2.5 GbE or 5 GbE USB adapters? Yes, it turns out, but with some qualifiers. QNAP once sold a branded 5 GbE adapter, the QNA-UC5G1T, based on an AQUANTIA-now-Marvell AQC111U controller.

But per the QNAP website, it’s discontinued, with retailer stock also depleted. It also only works with Intel x86-based QNAP NASs, not Arm-based models such as my TS-231K and TS-328 (as a backup plan, they both at least also have dual integrated 1 GbE ports). There’s no O/S support for Port Trunking multi-port merging, only for SMB Multichannel. And the only third-party AQC111U-based adapters I’ve come across, from Sabrent, Startech and TRENDnet, are also discontinued.

Things are a bit more encouraging on the 2.5 GbE front, however. QNAP doesn’t (and as far as I can tell, never did) sell a branded one, but I’ve successfully tested several third-party adapters based on Realtek RTL8156 network controllers (LAN-disconnected in the following image, albeit still system-recognized, which was my point in including the screenshot in the first place).

Again, the compatibility is x86-only; whatever Arm-compiled Linux build QNAP is using doesn’t seem to bundle the necessary driver support. And per Reddit chatter, it seems to be somewhat hit-and-miss as to whether a given adapter can be reliably powered from a given NAS directly versus requiring a powered-hub intermediary. But for those of you out there with x86-based NASs (or potentially even Arm-based NASs from other manufacturers using other operating system foundations) that don’t have add-in card support, it’s potentially better than nothing.

Volatile and nonvolatile memory enhancements

Another TS-453Be update I’ve recently done wasn’t motivated by network upgrades, per se. Instead, it was predominantly fueled by fundamental curiosity. As I’d mentioned back in late 2020, the NAS arrived with 2 GBytes of DDR3 SDRAM installed as a single SoDIMM, which I promptly updated to 8 GBytes total, albeit not at the highest possible hardware-supported speed bin given that I’d used two spare SoDIMMs I already had on-hand versus buying others.

I mentioned at the time that “some users report being able to run up to 16 GBytes total, but success is seemingly hit-and-miss, as is longevity, and since I don’t want to deal with stored data corruption I “passed” on this experiment.” Well, even though the Celeron J3455 isn’t (officially, at least) Windows 11-compatible, not to mention the lack of a system TPM (trusted platform module), Microsoft has now extended Windows 10 support for a second straight year, so far.

I suspect this may not be the final end-of support postponement, considering stubbornly high replacement-system building block prices. I’m already running Roon Server using Docker, with other containerized apps possible in the future. And with support extended, I may put virtualized Win10 back on the TS-453Be, too. My earlier test-drive had been successful albeit slow; I later uninstalled it due to the sizeable necessary HDD “footprint”. Doubling onboard memory should help performance in all these cases, due to resultant decreased virtual memory thrash. So while the NAS was open, I also dropped two 8 GByte SoDIMMs in. All’s stable so far, I’m happy to say.

And speaking of overall performance, while the four HDDs inside the NAS are enterprise 7,200 RPM variants (Hitachi Global Storage Technologies’, now Western Digital’s, Ultrastar 7K4000 HUS724040ALE640), they are HDDs. Even configured as RAID 5, I suspect their inherent random access latencies will become increasingly intolerable once the network-access latency between them and the LAN client(s) they’re communicating with are diminished as potential bottlenecks.

To wit, I have another QNAP add-in card on order, which I plan to at least temporarily in-system exchange for the currently installed QXG10G1T. It’s the QM2-2P10G1TB, which also comes with three bracket options (at least I hope this used one does, otherwise I’ll ship it back posthaste).

Versus the QM2-2P-244A I’d mentioned back in late 2020, this one includes support for dual M.2 NVMe SSDs and 10 GbE connectivity, as noted in the following conceptual cutaway.

To clarify upfront, I won’t be using the flash memory modules as “raw” storage. Instead, I’ll leverage QTier to harness them as a read/write cache. You can tell that the associated QNAP technology page is dated because it claims you can “take advantage of declining SSD prices.” Fortunately, I still have a few M.2 NVMe spares lying around from the pre-constraint days.

To be clear upfront, I’m not expecting anything dramatic improvement-wise from a performance perspective. Although the add-in card has a PCIe Gen3 x8 interface, the NAS connector I’ll be plugging it into only implements PCIe Gen2 x2, traffic-shared between the network controller and two SSDs, all factors leading to yet another potential bottleneck. Still, the comparative results should be interesting.

Once I get both the QNAP NAS and its supportive LAN infrastructure upgraded, I’ll run some benchmark tests and report back the results. Until then, I as-always welcome your thoughts in the comments on what I’ve discussed thus far!

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

The post NAS upgrades: Proprietary lockouts and surmounts appeared first on EDN.

Not all diodes use electrons