Talk:Sunxi devices as NAS

Jump to navigation Jump to search

I think this is something that quite a few people might be interested in (I've also seen related questions pop up on IRC from time to time). The available factual information seems sparse and/or scattered over many places. The key question probably is how to present / organize it without getting overly 'broad' on the subject, i.e. we need to keep some focus.

For example, I can imagine that the PMP stuff ("using port multipliers with sunxi devices") might be specific enough to justify putting it on a page of its own. -- NiteHawk (talk) 13:50, 20 June 2015 (CEST) (→ done, this is now covered in SATA#Port_multipliers)

Agreed. And due to the nature of a wiki we can also reorganise contents if it's too much stuff for one page. Tkaiser (talk) 15:34, 20 June 2015 (CEST)

Stuff to add:

  • performance warning when rootfs is on slow SD card (→ done)
  • reference to Optimizing_system_performance (→ done)
  • maybe Link to TCP/IP stack tuning
  • maybe details for Identifying bottlenecks
  • hint that application specific settings (eg. contents of smb.conf) are also important (→ done)
  • hint that due to the use of inappropriate benchmark tools like dd/hdparm many benchmark results found on the net for SBC are questionable (→ done)

There's a lot of further detailed stuff worth an explanation but the amount of contents is already too much IMO. -- Tkaiser (talk) 16:30, 30 June 2015 (CEST)

Since Igor Pečovnik's Debian build system / OS images now also include support for the pcDuino3 Nano (for all boards both 3.4/mainline kernel) and therefore only Hummingbird and the not yet available Banana Pi M1+ are missing from the list of recommended devices maybe it's a good idea to list Armbian as an alternative to manufacturer provided OS images? (→ done) -- Tkaiser (talk) 12:50, 2 July 2015 (CEST)

I would prefer if text sections (BOT vs. UASP) that describe the situation for over 99 percent of sunxi users accessing USB storage won't get deleted but instead being corrected (and performance figures provided when using CONFIG_USB_UAS=y) -- Tkaiser (talk) 14:02, 16 July 2015 (CEST)

I think the distinction is not very useful for most users, that's why I deleted it. But I'll try to find time to run some benchmarks soon with uas disabled vs enabled and report back when I have them. -- Silentcreek (talk) 17:16, 16 July 2015 (CEST)
4K record size, 960MHz/performance cpufreq, just sequential transfers in KB/sec in the following order: write, rewrite, read, reread. BOT: 31463, 30815, 30446, 32234, UASP: 35941, 38572, 38880, 39385. This is BOT vs. UASP. I didn't know that all that has to be changed is CONFIG_USB_UAS with mainline. And I don't know whether that's the maximum or not (since I own only UAS enabled USB devices that are normally blacklisted due to containing ASM1051/ASM1053). But I know that's for over 99 percent of sunxi users irrelevant because their distro uses either an outdated 3.4 kernel, or no UAS or they own devices that are blacklisted like mine. When testing with Random I/O UASP results might even be superiour. So please explain the stuff in USB -- Tkaiser (talk) 18:31, 16 July 2015 (CEST)
So, I ran a few tests with bonnie++. With my drive (Toshiba Stor.e Slim for Mac 500GB), the results don't show such a high impact: Squential write performance is the same (~34MB/s) whereas reads are a bit faster (UAS diasbled: 34-37MB/s; UAS enabled 38-39MB/s). Test size was twice the RAM size, so 2GB. I'll add some notes to the Wiki. -- Silentcreek (talk) 14:18, 19 July 2015 (CEST)
Oh, just saw you already updated the article. Thanks. -- Silentcreek (talk) 14:24, 19 July 2015 (CEST)
Don't trust in bonnie++ defaults on systems with just 1 GB RAM. Better use '-s8g -b' instead (otherwise you get test results that are way beyond what's physically possible since disk speeds are tampered with RAM/cache/buffer speeds: -- Tkaiser (talk) 22:01, 19 July 2015 (CEST)