Random fact- NAND flash endurance on recent Wifi 7 routers

[RMerlin]

Fun fact: some of the Wifi 7 (I only checked my RT-BE92U and RT-BE96U, it's possible they use it for many Wifi 7 models) use the MX30LF2G28AD SLC NAND flash, which can handle up to 60K erase cycles.

 

[Analog-1]

How many erase cycles can the average wifi 6 router handle ?

 

[Justinh]

Would that be the same as 60k hard resets?

 

[mellifluous]

That is a lot of firmware upgrades!!

 

[sfx2000]

Fun fact: some of the Wifi 7 (I only checked my RT-BE92U and RT-BE96U, it's possible they use it for many Wifi 7 models) use the MX30LF2G28AD SLC NAND flash, which can handle up to 60K erase cycles.

Keep in mind that every write cycle in NAND has to erase a entire block and then rewrite the data due to how NAND works... which is important for tasks that write to the flash - this likely would mean the third party scripts that do a fair amount of writes...

My most recent project used Winbond 32MB SPI-NOR - and it should be good for 100K write/erase cycles per their docs - and since it's NOR, it's only the specific addresses needed - even there, we kept writes to a minimum, storing config data only - logs were all in RAM... I think part of the endurance on these devices are because of automotive usage, where lifetime considerations are more than a couple of years...

 

[sfx2000]

Fun fact: some of the Wifi 7 (I only checked my RT-BE92U and RT-BE96U, it's possible they use it for many Wifi 7 models) use the MX30LF2G28AD SLC NAND flash, which can handle up to 60K erase cycles.

Should also mention that the NAND part @RMerlin mentions - this is an SLC part, which is the best that you can get for NAND - most of your SSD's now days are MLC (or more) - but they have over-provisioning and a flash controller to manage the wear...

NAND has a lot of performance advantages over NOR, but NOR has good things as well - always a tradeoff...

 

[RMerlin]

Would that be the same as 60k hard resets?

No. That would assume that each hard resets would overwrite the entire flash, which it doesn`t - your hard reset probably erases 4-5 MB out of the 64 MB available for nvram + jffs. And with wear leveling, future writes of that data will be in different memory cells within those 64 MB, so you don`t constantly wear out the same memory cells.

That means if you have 64 MB available for user storage and you write a 1 MB file over and over, you should be able to write 1 MB * 64 * 60,000 before you might start to experience nand failure. And if you add to the mix the 192 MB used by the dual firmware images, that's a pretty long life.

 

[RMerlin]

How many erase cycles can the average wifi 6 router handle ?

I don`t know, it might vary by model. I remember that some models back then used flash capable of 100K P/E cycles, but they had less flash (so, memory cells were reused more often).

 

[nagyimre1980]

You forget about the system log. The general log cannot be turned off. Especially the smartconnect function writes to it unnecessarily, and it can't be disabled. The flash storage wears out unnecessarily.

 

[Tech9]

More than enough for the expected service life of the product.

 

[RMerlin]

You forget about the system log. The general log cannot be turned off. Especially the smartconnect function writes to it unnecessarily, and it can't be disabled. The flash storage wears out unnecessarily.

These NANDs are frequently labelled as being suitable for log storage, as they have the necessary endurance for it. I remember it was specifically mentionned in the datasheet of some NAND used in the past among the intended usages for that particular NAND.

 

[sfx2000]

These NANDs are frequently labelled as being suitable for log storage, as they have the necessary endurance for it. I remember it was specifically mentionned in the datasheet of some NAND used in the past among the intended usages for that particular NAND.

These parts are generally good for the life of the device...

It's been rare that folks in the forum here have observed NAND flash failure...

 

[sfx2000]

You forget about the system log. The general log cannot be turned off. Especially the smartconnect function writes to it unnecessarily, and it can't be disabled. The flash storage wears out unnecessarily.

Are you sure about this with Stock firmware?

Busybox syslog is RAM based...

 

[nagyimre1980]

These NANDs are frequently labelled as being suitable for log storage, as they have the necessary endurance for it. I remember it was specifically mentionned in the datasheet of some NAND used in the past among the intended usages for that particular NAND.

It is a legitimate user demand to completely disable logging! And at this moment, it is impossible.

 

[ColinTaylor]

It is a legitimate user demand to completely disable logging! And at this moment, it is impossible.

Send a message to Asus asking them to add a switch for it. In the meantime, if you're using Merlin's firmware set System Log - General Log > Log only messages more urgent than = alert.

 

[RMerlin]

Are you sure about this with Stock firmware?

Busybox syslog is RAM based...

On the Broadcom side, Asus switched to persistent logging with the HND 5.04 SDK era (so, starting with the RT-AX86U_PRO, and newer models).

Mediatek and Qualcomm: it varies by model, some have persistent logging enabled, some don't. I'm not familiar enough with these models to tell if the change started with a certain SDK version, or based on the NAND used by the device.

 

[sfx2000]

On the Broadcom side, Asus switched to persistent logging with the HND 5.04 SDK era (so, starting with the RT-AX86U_PRO, and newer models).

Wonder why?

Mediatek and Qualcomm: it varies by model, some have persistent logging enabled, some don't. I'm not familiar enough with these models to tell if the change started with a certain SDK version, or based on the NAND used by the device.

Speaking for QSDK - the default is to write to either /var or /tmp mounted as ram based tmpfs on the newer releases - crashdumps can be configured to be persistent for development purposes over in /data which is ubifs or jffs on flash

Usually, for production, most will just use the busybox syslog tasklet and keep things in a rolling buffer, much like what openwrt does by default...

 

[Tech9]

I’m pretty sure the manufacturers figured it out. No one wants returned defective hardware. My gateways run few gigabytes Debian based OS on 16GB eMMC storage and read/write there constantly. Not going to worry about it in advance.