• [翻译] 树莓派的各种问题


    最近看到一篇写树莓派缺点的文章,感觉挺不错,就来翻译下(原文链接

    [翻译] 树莓派的各种问题

    February 2, 2019 | by nachoparker

    img

    树莓派价格低廉、应用丰富、扩展性强、社区活跃,所以广受欢迎。到处都是爱好者的作品和褒奖的声音,大多数人就没去关注它的弱点。直到某一天这些缺陷让他们卡关了,然后这些信息才出现在了论坛上。

    我在这总结一些我遇到过的问题,大概其他人也有一样的感觉,不过大部分人不去在意罢了。在一部分应用里,我不推荐树莓派,尤其是 NAS 的服务,像是 NextCloudPi 和 Open Media Vault 这样的。我会在后面给出原因。希望这些内容能节省我的时间,省的我来回在论坛里说。

    我当初买了好多树莓派,也用了好多年了。树莓派第一版在 2012 年发布,成了爱好者 SBC 市场的里程碑。当时市场上已经有一些很不错的板卡,像 Beagleboard 、Odroid ,不过这些板卡又难上手,又贵的要命,只有最硬核的爱好者才能玩,其他人都算是花钱买装饰品了。

    然后树莓派出现了,而且价格压得足够低。树莓派在性能上不是最强的,但是它的价格实在太诱人,之后就爆红了。各种博客、论坛上都是爱好者的树莓派相关作品、各种各样的库……树莓派是第一块这么流行的板卡,它的社区直到今天也是红红火火,大概这就是它战胜其他板卡的原因。

    不过呢,这都 2019 年了,以现在的视角来看就又不一样了。现在的市场上出现了质量更好,价格也一样便宜的其他板卡,我会在下面介绍下。

    性能

    img

    树莓派的价格能压得这么低是因为它砍了一些功能,结果就是,比起其他同类板卡,它在某些方面表现欠佳。我在这说说树莓派网络和 USB 功能上的缺陷。

    树莓派用一块 SMSC LAN9514 芯片 连接到 SoC ,只用了单个 USB 通道同时作为 USB 转网络接口和 USB hub 。也就是说网络和 USB 共用同一个通道,而典型的 NAS 应用需要同时进行网络上传和 USB 存储,所以这类应用的性能就受到很大的限制,更别说再加个 RAID 了。

    所以说,就算树莓派去年开始支持千兆网,实际的网络传输性能也达不到千兆网的水平,纯网络传输速度最大达到 40MB/s 左右,而从 USB 接口转接以后就降到了最大 20MB/s 。现在市场上已经有了支持真 · 千兆网和 USB3 的板卡,而且也不贵。

    实际上树莓派的 Wi-Fi 并不经过 SMSC ,而是通过 SDIO 连接到 BCM4343 芯片,所以理论上用 Wi-Fi 可以突破网络的性能瓶颈。可是无线芯片性能都不怎么样,而且还会跟其他接口设备竞争附近的无线信道,所以换用 Wi-Fi 也不够好。

    所以,我不推荐用树莓派做 NAS 应用,不管是 Open Media Vault 还是 Nextcloud 。

    树莓派的核心不开源

    img

    如果你在关注软件自由的讨论,那在 Linux 板卡上,首当其冲的问题就是不开源的部分。我不在这描述细节,不过令人在意的是板卡的这些部分控制着所有东西,却是个黑箱。软件社区在解决这事上也做了巨大的贡献,比如 Android Replicant 尝试给出所有黑箱的替代方案,不过这是个痛苦、无聊又缓慢的过程。

    在树莓派上,用户也面临类似的问题。CPU 和 GPU 集成到了一块 BCM2837B0 芯片 上,CPU 是 1400 MHz 的 64 位四核 ARM A53 架构(Pi3B配置),GPU 是400MHz 的双核 32 位 VideoCore IV 架构。这是常见的移动设备 SoC 配置,把所有东西集成到单芯片,兼顾了低成本和低功耗。在竞品里面,NXP iMX 和 Allwinner 也是类似的方案。

    所以在最新的树莓派主芯片上,有 6 个核心,但是其中只有 4 个是 ARM 核心。Linux 系统在 ARM CPU 上跑,这事大家都懂,但是令人诧异的是在树莓派上,Linux 只是个弟弟,GPU 上有个叫 ThreadX 的实时操作系统,它才是老大哥。这个 ThreadX 系统是闭源的,控制了芯片上的系统,跟开源的 Linux 核心屁事没有。

    当树莓派开始启动的时候,CPU 会完全断开连接(确切地说是保持复位状态(reset state)),实际上是靠 GPU 启动系统。可以去看下系统 /boot 目录,就会发现 GPU 用的一些二进制文件,用来启动 CPU 和 GPU 上的 ThreadX OS (bootcode.binstart.elf) 。这里有更多详细的启动过程说明。

    实际上是 GPU 挂载了 SD 卡,读取这些二进制文件和 config.txt 文本文件 里的配置信息,这个文本文件是用户设置的显示配置和 GPU 超频设置。这些东西都不关 Linux 的事。

    在 GPU 控制 CPU 引导了 Linux 内核后,它也不会乖乖退居二线做一个图形处理核心(graphics-processing-unit),GPU 还是老大哥。你曾经想过,当树莓派外接 HDMI 显示器的时候,是啥显示了树莓派的 logo 吗?或者当降频限流(throttling)的时候,是啥显示了 闪电和温度(lightning or temperature symbols) 标识?没错,还是 GPU 上的 ThreadX 系统。这些东西也不关 Linux 的事。

    GPU 具体都干了些啥就没人知道了,但是可以确定有些事情是它干的,这里面最令人关心的就是 ThreadX 系统的低电压处理机制。低压算是常见的问题了,在下一节里有详细介绍。ThreadX 系统在检测到低压时控制 CPU 降频,防止指令失效和 CPU 跑飞,结果就是大家的 CPU 最高主频从 1400 MHz 降到了 600MHz 。在供电电压低于 4.65V ,或者芯片温度过高的时候,降频限流就会启动。而 Linux 和 Linux 系统自己的频率调节器(frequency governor)还傻傻的被蒙在鼓里,以为自己一直在最高主频下运行。

    这些东西还仅仅是我们能看见的部分,因为 ThreadX 是闭源系统,所以没人知道它背地里还干了些啥别的事,甚至令人怀疑它是不是能干些干涉隐私的事情。

    板卡上闭源的部分至少包含一个专利,最早也得到 2025 年才会解除专利保护,开放源码,但是也没人知道那之后会不会再加入类似的东西了。已经有人在搞 VideoCore IV 反向工程 和 VideoCore IV 开源固件了,但是很不幸,这些项目都夭折了 。搞这些东西跟 Android blobs 一样,都是些地狱难度的事。

    供电问题

    img

    供电问题倒不是树莓派自己的问题,大部分情况都是用户的锅。

    初代树莓派电流只有 80 mA,但是每次升级换代,性能都蹭蹭的涨,随之而来的麻烦就是同样上涨的用电需求 。最要命的是,很多用户连接的 USB 设备也是电老虎,除非有单独的 USB 外部供电。

    microUSB 接口当初设计为提供 1.8A 电流 ,尽管这个标准已经很旧了,而且市面上也可以找到电流更大的适配器,还是有好多人在用旧的 1A 手机电源适配器,或者上网买个白菜价的破烂适配器接在树莓派上。树莓派是个计算机,需要高质量、稳定的 5V 恒压电源,电流要能达到 2.5A 。不只是适配器质量要好,电源线和接口也不能差(否则就会有压降),所以,拜托各位,用根好点的线材,类似 20AWG 这样的,或者买官方的电源适配器。总之结论就是,没有 USB 适配器能正常工作,就算标称 2.5A 5V 的也不行。(译者注:官方东西贵且丑,拒绝。本人用的是 OPPO R9 的 USB 电源适配器,标称 5V 4A,线材用的手机自带的 microUSB 的那根。OPPO R9 是闪充来的,所以适配器和线材都撑得住大功率的设备,感觉还不错。)

    结合上一节的内容来看,我们就能发现问题了。大多数用户的树莓派都在低压状态下运行,而 GPU 则靠着调节 CPU 的频率掩盖了这个问题,所以他们的树莓派实际最高主频降到了 600MHz ,这个性能已经差到和之前 ARMv6 的树莓派一样了。

    在一些极端场合,GPU 的这些动作甚至都不够用了,系统会莫名其妙挂掉或者直接死机,数据传输突然中断,甚至损伤 SD 卡。这种事情经常发生在晶体管供电不足(under load)的情况下。然后,用户就会跑到论坛上抱怨:我电源一点问题都没有,我之前运行了这个那个都没问题。 实际当然是有问题的,但是他们通常是不会相信的。

    这就是日本人说的 ポカヨケ(Poka Yoke,防呆) ,换句话说,设计者在设计系统时要通过设计手段防止用户搬起石头砸自己的脚。所以重申一遍,官方电源适配器性价比非常高,我强烈推荐。

    我很讨厌板卡自己悄悄降频,没法人为干预。我宁愿系统挂掉,然后我就知道它有问题了,然后换掉 PSU ,不像现在有那么多蠢货在网上到处发泄他们的不满。如果不考虑防呆的问题的话,我实在是想不出来为什么树莓派的开发者要这么干。

    供电问题的检验

    img

    很久很久之后,Linux 内核 终于 输出了如下的日志记录。查看系统日志

    kern  :crit  : [ 1701.464833    2.116656] Under-voltage detected! (0x00050005)
    kern  :info  : [ 1707.668180    6.203347] Voltage normalised (0x00000000
    

    ,这就说明供电不足。还好,至少 Linux 日志现在显示了这个信息,但是如果还想继续探究细节的话,就必须直接去敲 GPU 的门了。

    使用 vcgencmd 指令 可以和 ThreadX 固件通信,获取系统信息,或者更改设置。

    # vcgencmd get_config int
    arm_freq=1000
    core_freq=500
    sdram_freq=600
    over_voltage=6
    disable_overscan=1
    force_pwm_open=1
    

    可以使用 vcgencmd measure_clock armvcgencmd measure_volts 指令读取实际的频率和电压值。下面是一个 监视脚本(moritoring script) 的输出(by tkaiser)

    # With a crappy PSU and/or Micro USB cable output looks like this
    # on a RPi 3:
    # 在树莓派 3 上
    # 如果用一个破烂电源 和/或 一根破烂 USB 电源线,输出会像下面这样:
    #
    # 44.0'C  600 MHz 1010000000000000000 1.2V
    # 44.5'C  600 MHz 1010000000000000000 1.2V
    # 44.0'C  600 MHz 1010000000000000101 1.2V
    # 44.0'C  600 MHz 1010000000000000101 1.2V
    # 44.0'C  600 MHz 1010000000000000101 1.2V
    # 44.5'C  600 MHz 1010000000000000000 1.2V
    # 45.1'C  600 MHz 1010000000000000101 1.2V
    # 
    # With an ok-ish cable it looks like this (when running cpuburn-a53):
    # 换用好的电源线以后(运行cpuburn-a53):
    # 
    # 48.3'C 1200 MHz 0000000000000000000 1.3312V
    # 48.3'C 1200 MHz 0000000000000000000 1.3312V
    # 48.3'C 1200 MHz 0000000000000000000 1.3312V
    # 48.3'C 1200 MHz 0000000000000000000 1.3312V
    # 50.5'C 1200 MHz 0000000000000000000 1.3312V
    # 56.4'C  600 MHz 0000000000000000000 1.2V
    # 54.8'C  600 MHz 1010000000000000101 1.2V
    # 55.3'C  600 MHz 1010000000000000101 1.2V
    # 55.8'C  600 MHz 1010000000000000101 1.3312V
    # 53.7'C  600 MHz 1010000000000000101 1.2V
    # 51.5'C  600 MHz 1010000000000000101 1.2V
    # 51.0'C  600 MHz 1010000000000000101 1.2V
    # 
    # And only by bypassing the crappy connector you can enjoy RPi 3
    # performing as it should (please note, there's a heatsink on my RPi
    # -- without throttling would start and then reported clockspeed
    # numbers start to get funny):
    # 只有抛弃破烂电源和电源线,才能享受树莓派 3 的真正性能
    # (注意,我的树莓派上装了散热器————不会因为过热而降频,数据开始变得有意思了):
    # 
    # 75.2'C 1200 MHz 1010000000000000000 1.3250V
    # 75.8'C 1200 MHz 1010000000000000000 1.3250V
    # 75.8'C 1200 MHz 1010000000000000000 1.3250V
    # 76.3'C 1200 MHz 1010000000000000000 1.3250V
    # 76.3'C 1200 MHz 1010000000000000000 1.3250V
    # 73.6'C 1200 MHz 1010000000000000000 1.3250V
    # 72.0'C 1200 MHz 1010000000000000000 1.3250V
    # 70.4'C 1200 MHz 1010000000000000000 1.3250V
    #
    # Now with a pillow on top for some throttling:
    # 现在在上面捂个枕头,开始降频了:
    #
    # 82.2'C 1200/ 947 MHz 1110000000000000010 1.3250V
    # 82.7'C 1200/ 933 MHz 1110000000000000010 1.3250V
    # 82.7'C 1200/ 931 MHz 1110000000000000010 1.3250V
    # 82.7'C 1200/ 918 MHz 1110000000000000010 1.3250V
    # 82.2'C 1200/ 935 MHz 1110000000000000010 1.3250V
    # 79.9'C 1200/1163 MHz 1110000000000000000 1.3250V
    # 75.8'C 1200 MHz 1110000000000000000 1.3250V
    #
    # And here on RPi 2 with crappy USB cable and some load
    # 在树莓派 2 上用破烂 USB 电源线,再加上一些负载
    #
    # 50.8'C  900 MHz 1010000000000000000 1.3125V
    # 49.8'C  900 MHz 1010000000000000000 1.3125V
    # 49.8'C  900/ 600 MHz 1010000000000000101 1.2V
    # 49.8'C  900/ 600 MHz 1010000000000000101 1.2V
    # 48.7'C  900/ 600 MHz 1010000000000000101 1.2V
    # 49.2'C  900/ 600 MHz 1010000000000000101 1.2V
    # 48.7'C  900 MHz 1010000000000000000 1.3125V
    # 46.5'C  900 MHz 1010000000000000000 1.3125V
    #
    # The funny thing is that while the kernel thinks it's running
    # with 900 MHz (performance governor) in reality the 'firmware'
    # throttles down to 600 MHz but no one knows :)
    # 有趣的事情是,当内核认为自己运行在 900 MHz 的时候(Linux 的性能调节器)
    # 实际已经被"固件"降到了 600 MHz,但是没人知道这事 :)
    

    结论

    img

    我承认在 SBCs 的历史上,树莓派有非常重要的地位,但是时代变了,现在它的质量、性能和开源程度都落后了,市面上有很多不贵的替代品,他们的开发者在这些问题上做得更好。

    尽管如此,我还是在用树莓派做创建私人云服务的教学。鉴于树莓派如此流行,只要它还能做这个事情,支持它对我来说就还是有意义的。

    img

    作者: nachoparker

    Humbly sharing things that I find useful github dockerhub View all posts by nachoparker

    (评论我就不翻译了,太长了,感兴趣的观众可以直接查阅原网站。)

  • 相关阅读:
    变态的IE
    视频豪横时代,应用如何快速构建视频点播能力?
    阿里云峰会 | 阿里云CDN六大边缘安全能力,全力助推政企数字化转型
    从 2018 年 Nacos 开源说起
    完美日记:实现高弹性高稳定电商架构
    Dubbo 迈出云原生重要一步 应用级服务发现解析
    如何提升微服务的幸福感
    怀里橘猫柴犬,掌上代码江湖——对话阿里云 MVP郭旭东
    云原生时代消息中间件的演进路线
    solr中特殊字符的处理
  • 原文地址:https://www.cnblogs.com/adjwang/p/13958946.html
Copyright © 2020-2023  润新知