Jump to content

Nano PI NEO Core-2 install to eMMC vs sda1


Quanta

Recommended Posts

Greetings to all,

 

Preamble:

Thanks to all that have worked to make the Armbian project what it is today. It is greatly appreciated!

 

I have done numerous hours of reading and searching (due diligence). I know I could run a benchmarks and all but that means even more delay reaching the objective. Some brief guidance from those who have gone before would save a lot of time and would be greatly appreciated. Looking at the datasheets wasn't real helpful in guesstimating optimum performance configuration - especially since there are so many other factors that have an impact. 

 

Background: 
My objective is to achieve a reliable, long life system and avoid big performance hits along the way. The host is for home automation so the most of the storage activity will be logging and playing back canned sounds and serving up web pages consistent with HMI functions by my estimation. Other activity will be from Node-Red, MQTT broker, The automation web server, etc.  I also maintain a NAS in the house so logs backups and databases associated with the HA system will be copied or backed up there. 

 

I have done so much reading and a fair bit of testing  that I am a bit unsure as I write if Armbian supports logging to ramdisk or some such. If so, this would also be part of the picture for me. I would either sense the UPS power state or come up with a supercap or other power storage scheme and sense power loss and push ramdisk to NV storage... This is a little off topic but is relevant to the extent that I don't want to loose data that has been collected and the safest place for it is not in ram but in flash.

 

I am guessing that for this context with a limited number (15?) of devices connected to via browser such as tablets, phones, and PCs alongside a few dozen other devices that are I/O nodes, not a lot of disk I/O will be needed. Room for growth is important (I hope) as well as avoiding performance degradation as a consequence of it. It is troublesome to have to deal with 'users' noticing slowdowns!  Though of course I wouldn't consider hobbling the system now and loosening the reins later to deal with extra load... 

 

As I see it, if I use eMMC at all, I need to be using some kind of wear leveling (f2fs), minimize writes to it, and don’t fill it too full. A better option if performance will allow is to use sda1 instead for the root file system. I assume the M.2 device will have wear leveling and other features which along with much larger capacity (largely empty) in concert with brtfs file system is the best I can do to get performance and reliable operation over the M.2 /USB interface. Since M.2 is replaceable it is reasonable to expect that the system will not become permanently unusable due to flash wear failures in the near and mid term - I can simply restore to new M.2 device if it fails. Long term fiscal and technology issues are another matter.

 

Question 1:
Which would yield a more responsive system? The os residing on the eMMC or M.2? I see that the eMMC is using an 8 bit parallel interface (data and address must be using same path) vs the M.2 slot which is connected via a JMS567-LGBB1A chip. I read here https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350 that it at least has the potential to be a good performer. The context there was USB3 which is not used on the FA shield. The shield uses USB2 so there is still some question about how it will perform (there are other factors as well of course). 

 

Question 2:
If I end up using eMMC for root, and assuming logs are being written to m.2, what recommendations to monitor and make sure writes to eMMC are minimized? I would probably want to do some monitoring anyway later on for lots of reasons.

 

Pointers on how to set up brtfs (f2fs as well actually) for root to maintain speed and health in this context would also be appreciated.

 

Regards and thanks again to all that have and will contribute,

 

Q

Edited by Quanta
correct board reference in title
Link to comment
Share on other sites

With respect gentlemen, refer to the main product page at FA web site. I suspect if you check log in the other post Here (may be stuck in moderation still) you may find supporting evidence that I am correct. It may be that you are thinking emmc means something removable like this eMMC CARD . Not all EMMC chips are removable .  This is in fact the case for the NEO2.  The chips are directly soldered on the controller board. Hence my concern that I not wear it out by careless write activity. 

 

As far at USB 3 vs USB 2, Again reference the FA product wiki (schematic) here Wiki page (schematic in PDF at bottom) The schematic clearly shows the USB 3 port of the JMS567-LGBB1A as not connected and the USB2 port connected to the NEO2. 

 

At present I have the boot loader on the EMMC and Armbian /  on sda1 (the M.2 device) via the shield.  I boot with NO SD/TF card in system.

 

Thank you for your attention.

 

Q

Link to comment
Share on other sites

1 hour ago, Quanta said:

As far at USB 3 vs USB 2, Again reference the FA product wiki (schematic) here Wiki page (schematic in PDF at bottom) The schematic clearly shows the USB 3 port of the JMS567-LGBB1A as not connected and the USB2 port connected to the NEO2. 

 

With respect  - but in the title of this thread you did wrote "NanoPi NEO2 LTS" and the link to the shield is for the Neo Core(2) - thats a complete different board ;)

 

NanoPi NEO2-LTS

https://www.friendlyarm.com/index.php?route=product/product&product_id=180

 

NanoPi NEO Core2-LTS

https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=211

 

Thank you for your attention. :)

 

Link to comment
Share on other sites

  • Quanta changed the title to Nano PI NEO Core-2 install to eMMC vs sda1
7 hours ago, guidol said:

Neo2 has also no USB3.0 but USB2.0 where in the silver NAS-Case

 

Also note that Neo2 - with the NAS case - there are two different versions based on the NEO2 version as the ethernet socket moves a bit with regard to how it's mounted on the Neo2 board.

 

WRT the Neo2 vs. Neo Core2 - the only advantage I see with eMMC vs. SD Card is that the storage is on board - it's just as easy to corrupt an eMMC as it is a uSD card, and more work to recover..

Link to comment
Share on other sites

4 hours ago, Quanta said:

The schematic clearly shows the USB 3 port of the JMS567-LGBB1A as not connected and the USB2 port connected to the NEO2. 

 

It's USB port 3, not USB 3.0 for the H5 based boards...

 

 

Link to comment
Share on other sites

Guidol,

 

It may be just as easy to corrupt eMMC but wouldn't it be far less likely to happen if the OS wasn't writing to it as a matter of course? Also, my stated concern was not corruption per se but wear that would render the memory useless and I think, the entire board because The eMMC contains the bootloader.  I also expect that I should be able to restrict write access as root and mark RO for the OS which would further protect it. If true that makes an even better case to use just the USB connected M.2 device for storage - equally easy to deal with as the TF card. Again, the only reason not to in this case would be because of a significant performance hit - that is the answer I am looking for.

 

Q

Link to comment
Share on other sites

On 1/6/2019 at 1:34 AM, Quanta said:

My objective is to achieve a reliable, long life system

Always make a backup.

 

  1. eMMC vs SDcard, depending on the bus it is attached. SDcard can easily be replaced if broken.
  2. Armbian writes only every 10min |  Log is in (Z)RAM | ZRAM is used for SWAP
  3. WiFi on these board is usually not so good, with regard to connect IoT
  4. I still wonder for what a HomeAutomation needs the speed - by the way, aren't HA system very chatty with regard to logging?

 

Edited by Tido
got ... good
Link to comment
Share on other sites

Tido

 

Thanks for your comments. 

Quote

...SDcard can easily be replaced if broken .

We agree. I also think you would agree that holds true for M.2. So the remaining question is, can eMMC be used easily and effectively in this context only as a RO store and does it offer any significant gains in terms of a "responsive" system. Also, in my book, reliability means in part, the system doesn't go down because of wearout that could have been detected (S.M.A.R.T.) or avoided altogether.

Quote

...only every 10min |  Log is in (Z)RAM...

While I need to understand this aspect more, I had read that RAM is used for logs. One of a number of reasons I decided to try Armbian. 

Quote

...not so got...

Assume you mean hot. You would not believe the amount of CAT5e in my house for this reason.  You can't ever beat wire when lots of devices need low latency relatively secure communicaton and power. A complex subject for another time...

Quote

wonder for what a HomeAutomation needs the speed... chatty...

My take on speed is that the higher the latency the greater the possibility that the user will end up sending multiple commands -not good, though good software design should handle this. Also, the lower the latency, and faster the processing the easier it is for example, to make things like IR remotes work transparently. Consider using a random IR remote set up to adjust "the volume" in a room.  Only the user and the HA system know the context - what system in the room is making sound.  In this context the HA relieves the user of the need to select the correct sound maker. HA tracks and translates transparently - how's that for alliteration? The less time I take from I to O for my HA is also more time that slow adapted devices can use and still allow me to achieve a near real time experience for the user.  Consider a 2 second delay in a video link. It is very challenging to make that conversation work without collisions. When one side of the conversation is actually a dumb computer and the other an impatient human it wont be pretty for the computer or the person that set up the computer! And I don't see a design in which all crashes happen in slow motion as a solution to the problem either:lol:

 

As far as chatty goes, while this can be eliminated it is of course better to handle in a way that is fast, doesn't compromise real time performance (write bottlenecks) or stability/reliability (flash wearout) so, best addressed at the beginning of the project.

 

Q

Link to comment
Share on other sites

On 1/7/2019 at 6:53 PM, Quanta said:

So the remaining question is, can eMMC be used as a RO store and does it offer any significant gains in terms of a "responsive" system.

If I remember correctly, it is not only about the eMMC or M.2, but the Bus that connects it with the SoC. Asus's tinker board for example: Micro SD, The slot is linked to the SoC with an SD 3.0 interface.

I don't know what the H5 offers in that regard.

 

On 1/7/2019 at 6:53 PM, Quanta said:

of wearout that could have been detected (S.M.A.R.T.)

Most of your "need for speed" question and reliability are @tkaiser favorite territory. I can only give you things to consider, like above.

 

On 1/7/2019 at 6:53 PM, Quanta said:

Assume you mean hot.

It should have said, not so good. Better take a well supported external WiFi dongle.

 

On 1/7/2019 at 6:53 PM, Quanta said:

The less time I take from I to O for my HA is also more time that slow adapted devices can use and still allow me to achieve a near real time experience for the user. 

Now I understand. Sounds like you need a real-time-kernel or for some functions calling an interrupt to get immediate attention or even a second SBC.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines