Daily - OTA updates - Jetson Nano SOM - have any issues ( i,e degrade the SOM)

Dear Friends,

We are using auto update logics based via OTA - on daily basis ( once in a time daily ) to upgrade the system consists of Jetson Nano + Carrier board combination kits .
Will this above functionality will degrade the Jetson Nano SOm performance.

Please advise .

Best Regards,
Ramesh

Not quite understand your question, why you want to do the OTA everyday?

Hi,
Thanks for your response,
Please find below requirements for daily OTA -update,
1.Whenever new patches (exe.) updated then system(kit) will triggered automatically for self auto update, shutdown and restarting to make this latest update effective.
2.To remove the temporary (cache files) executed in the system (Kit).
3.To remove the dump files generated in the system (kit).

My concern is to know that frequent update , shutdown and restarting the kit will degrade the OS and SOM performance.

Thanks ,
Regards,
Ramesh.

Hi,

Really has no point to do this everyday… just do this when we have jetpack release should be sufficient.

I assume you are using the module’s internal EMMC as storage.

All flash storage (EMMC is one of them) is divided into block. Each block has a finite and limited number of erase/write cycles. These can rangle from 100000 cycles for SLC flash (each flash cell holds one bit) to 10000 for MLC (each flash cell holds two bits) to 5000 for TLC (each cell holds three bits) to maby 2000-3000 for QLC (each cell holds four bits). MLC and TLC are the most common types for EMMC.

You must consider this fact and see the modules as a consumable item with a finite useful lifespan. You should avoid excessive write cycles and use RAM disks (tmpfs) for temporary data, or use external storage like a SD card (less reliable then EMMC but can be easily swapped and thrown away when broken) or NVME SSD (much larger capacity, therefore much more erase/write cycles, much better controller).

This problem is not a theoretical one! Tesla had problems in some car models where controller units would fail after a couple of years due to excessive write/erase cycled because to many log files got written to the EMMC. When the controller failed the cars would not start. They solved the problem by using a bigger EMMC and reducing the amount of data being logged.

On the other hand I don’t think that daily package updates add many write cycles to the EMMC.

Orin Nano boards don’t have this problem since they don’t have an internal EMMC at all. You must use an SSD, which is an replaceble part.

I suppose you could either disable logging, or simply change the log level to something less verbose. If you have plenty of RAM (not likely), and don’t need logs to persist, then you could use a RAM-based disk mounted on “/var/log”. There are limitations on solid state memory (@fchkjwlsq had a nice description) that you cannot get around if you choose to write a lot. All you can do is write less (thus the suggestion of lowering log levels or disabling logging). Note that the reboot itself won’t do much writing.

Incidentally, the concept (for the case where you have sufficient RAM) of a RAM-based partition mounted on “/var/log” also applies to locations like “/var/cache/apt/archives” (you’d have to be very careful to not do this with actual package database meta files).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.