Raspberry Pi adalah perangkat yang sangat populer yang dikenal karena harganya yang terjangkau, keserbagunaan, kemampuan dan komunitas yang dinamis. Sangat mudah untuk menemukan situs penggemar dan artikel, tetapi kebanyakan orang tidak tahu tentang kelemahannya sampai mereka sendiri menderita dari mereka dan mencari informasi di forum.

Saya akan mencoba berbicara tentang beberapa masalah yang saya temui secara pribadi, serta beberapa masalah khas yang paling sering muncul pada orang yang tidak curiga dengan hal itu. Dan akhirnya, mengapa saya tidak merekomendasikan Pi untuk beberapa aplikasi, khususnya layanan NAS seperti NextCloudPi dan Open Media Vault. Saya harap ini menghemat waktu saya sehingga saya tidak mengulangi semua ini di forum.

Saya telah memiliki banyak Raspberry Pi dan telah menggunakannya selama bertahun-tahun. Ketika model pertama muncul di 2012, itu menjadi tonggak penting di pasar papan tunggal. Meskipun beberapa papan bagus sudah ada, seperti Beagleboard dan Odroid, mereka cukup mahal, dan hanya penggemar hardcore yang bisa membeli dan mengujinya.

Pi tidak begitu kuat dibandingkan dengan mereka, tetapi karena murahnya yang menakjubkan itu benar-benar meledakkan pasar. Blog, kartu ekspansi, banyak proyek pribadi, banyak perpustakaan ... Raspberry Pi adalah yang pertama untuk mencapai semua ini, dan hingga hari ini komunitas yang berkembang adalah keuntungan Pi terbesar dibandingkan papan lainnya.

Tapi sekarang adalah 2019 dan saatnya untuk melihat-lihat lagi. Menurut pendapat saya, ada alternatif yang lebih terbuka dengan kualitas yang lebih baik dengan harga yang sama. Saya akan coba jelaskan.

Performa

Raspberry Pi memotong harga dengan memotong sudut. Akibatnya, dewan tidak cukup produktif untuk beberapa tugas, dibandingkan dengan pesaing. Secara khusus, itu tidak cocok untuk tugas-tugas jaringan dan fungsi USB.

Berikut ini adalah chip SMSC LAN9514 , yang terhubung ke SoC dengan satu saluran USB, bertindak sebagai adaptor USB ke Ethernet dan hub USB pada saat yang sama. Dengan demikian, Ethernet dan USB duduk di saluran yang sama dan bersaing satu sama lain, yang bertentangan dengan penggunaan NAS, ketika sesuatu diunduh melalui jaringan dan disimpan pada drive USB, belum lagi penambahan RAID di sini.

Untuk alasan yang sama, bahkan ketika mereka akhirnya merilis model Gigabit Ethernet-enabled tahun lalu, kinerja jaringan nyata bahkan tidak pernah mendekati gigabit, tetapi maksimum 40 MB / s dalam kecepatan bersih dan maksimum 20 MB / s jika Mentransfer ke perangkat USB . Pada saat itu, sudah ada papan murah dengan Gigabit Ethernet dan USB3 nyata.

Faktanya, Wi-Fi tidak melalui SMSC , tetapi terhubung ke chip BCM4343 melalui SDIO , sehingga bottleneck ini dapat dihindari dengan menggunakan Wi-Fi. Namun, chip Wi-Fi tidak mahakuasa, ia harus berurusan dengan gangguan di sekitarnya, jadi ini bukan alternatif yang ideal.

Untuk alasan ini, saya tidak akan merekomendasikan menggunakan Pi sebagai NAS, apakah itu Open Media Vault atau Nextcloud.

Pi Otak Nyata - Sumber Tertutup

Jika Anda terlibat dalam perselisihan kebebasan perangkat lunak, maka masalah utama dalam sistem Linux kami adalah gumpalan biner sumber tertutup. Saya tidak akan merinci, tetapi masalahnya adalah bahwa bagian-bagian dari sistem ini tidak dapat diverifikasi, dan mereka memiliki akses ke semua yang terjadi pada perangkat. Proyek open source besar ini, seperti Android Replicant , dirancang untuk membebaskan sistem kami dari sembarang biner: proses yang menyakitkan, membosankan, dan lambat.

Masalah serupa adalah dengan Raspberry Pi, di mana CPU dan GPU terintegrasi dalam chip BCM2837B0 yang sama. Prosesor sentral adalah 64-bit quad-core ARM A53 pada 1400 MHz (dalam Pi 3B), dan prosesor grafis adalah VideoCore IV 32-bit dual-core dengan frekuensi 400 MHz. Integrasi CPU dan GPU populer di dunia seluler karena mengurangi harga dan konsumsi daya. Pesaing NXP iMX dan Allwinner menggunakan pendekatan serupa.

Jadi, dalam Pi terakhir ada enam inti, tetapi hanya empat di antaranya adalah ARM. Linux berjalan pada prosesor, tetapi mungkin mengejutkan Anda bahwa Linux pada perangkat ini adalah warga negara kelas dua. Inti GPU berjalan di bawah sistem operasi real-time ThreadX. OS sumber tertutup ini mengelola sistem tanpa sepengetahuan kernel Linux.

Pada awal pengunduhan, prosesor Raspberry Pi sepenuhnya dinonaktifkan (secara teknis dalam keadaan reset ) dan itu adalah GPU yang memulai sistem. Anda dapat melihat pada folder /boot dan Anda akan menemukan gumpalan biner yang dengannya GPU memulai prosesor dan ThreadX OS-nya sendiri ( bootcode.bin dan start.elf ). Baca lebih lanjut tentang proses pengunduhan di sini .

Ini adalah GPU yang memasang kartu SD, mengunduh gumpalan ini dan membaca konfigurasi dari file teks config.txt , yang kami edit untuk menyesuaikan pengaturan video atau overclock GPU. Linux tidak terlibat di sini.

Ketika GPU memungkinkan CPU untuk memuat kernel Linux, tidak hanya meninggalkan panggung, hanya berfungsi sebagai prosesor grafis . Tidak, GPU masih yang utama. Pernahkah Anda berpikir siapa yang menampilkan logo-logo ini ketika Pi terhubung ke HDMI? Atau apakah simbol petir atau suhu ini ada di ikon peringatan? Tepatnya, inilah yang dilakukan sistem ThreadX pada GPU, dan Linux tidak tahu apa yang terjadi.

Kita mungkin tidak tahu fungsionalitas penuh GPU, tetapi kita tahu sesuatu yang menjadi tanggung jawabnya. Untuk artikel ini, penting bahwa ThreadX memonitor penurunan tegangan - masalah yang meluas, seperti yang akan kita lihat nanti, dan mengurangi frekuensi prosesor untuk mencegah kegagalan dan pembekuan prosesor. Oleh karena itu, pada manusia, perangkat beroperasi pada frekuensi 600 MHz, bukannya 1400 MHz, paling banter. Pembatasan ini dimulai pada 4,65 V dan juga dapat dipicu oleh suhu. Pada saat yang sama, Linux masih berpikir bahwa sistem beroperasi secara normal pada frekuensi penuh.

Inilah yang kita lihat. Karena OS utama adalah hak milik, kami tidak memiliki cara untuk mengetahui apa lagi yang dapat dilakukan atau yang dapat dilakukan, sehingga selalu ada masalah privasi.

Setidaknya ada satu paten yang termasuk dalam blok sumber tertutup yang melarang pembukaan kode hingga setidaknya 2025 , tetapi kami tidak tahu apakah ini akan dilakukan bahkan saat itu. Ada upaya untuk merekayasa balik VideoCore IV dan membuat firmware open source untuknya. Sayangnya, proyek itu mati sebelum menghasilkan sesuatu yang bermanfaat. Seperti halnya gumpalan Android, ini adalah pekerjaan yang sangat sulit.

Masalah gizi

Ini bukan kesalahan teknis Raspberry Pi, melainkan kesalahan khas pengguna.

Model pertama hampir tidak menggunakan 80 mA, tetapi setiap generasi baru menjadi lebih dan lebih kuat, dan karena alasan ini lebih banyak energi-intensif. Selain itu, banyak pengguna memasang perangkat USB yang juga mengonsumsi daya jika mereka tidak datang dengan catu daya sendiri.

Konektor microUSB pada awalnya dirancang hanya untuk 1,8 A, dan meskipun merupakan standar lama, dan Anda dapat menemukan pengisi daya yang memberi lebih banyak, sehingga banyak orang mencoba menggunakan pengisi daya telepon 1 A lama atau membeli adaptor murah di Internet untuk memberi daya pada Raspberry. Tetapi Pi adalah sebuah komputer, dan itu membutuhkan catu daya yang stabil dan berkualitas tinggi yang memberikan kestabilan 5 V pada input dengan kekuatan saat ini hingga 2,5 A. Tidak hanya diperlukan transformator yang layak, tetapi juga koneksi berkualitas tinggi (atau penurunan tegangan akan terjadi), tetapi yang lebih penting bahwa Anda memerlukan kabel yang bagus, jika tidak tegangan akan turun sangat. Kabel yang buruk bahkan lebih umum daripada sumber tegangan yang tidak stabil, jadi pastikan untuk menggunakan kabel yang bagus: mungkin 20AWG atau serupa, atau hanya membeli sumber listrik resmi. Kesimpulannya adalah bahwa tidak setiap pengisi daya USB akan berfungsi dengan baik, meskipun itu 2.5A 5V.

Tambahkan ini ke apa yang kita bahas di bagian terakhir, dan Anda akan mulai memahami gambaran besarnya. Sebagian besar pengguna bekerja pada perangkat mereka dengan frekuensi yang lebih rendah, dan GPU menyembunyikannya dari mereka, sehingga mereka benar-benar bekerja dengan frekuensi yang berkurang dari 600 MHz: hampir sama dengan ARMv6 pada Pi pertama.

Dalam banyak kasus, upaya GPU tidak mencukupi dan sistem macet secara acak atau hanya membeku, mungkin merusak data atau merusak kartu SD. Ini biasanya terjadi di bawah beban , yaitu ketika transistor membutuhkan daya maksimum. Kemudian pengguna datang ke forum dan mengeluh: catu daya saya dalam urutan, saya menjalankan ini dan itu, dan tidak ada yang gagal . Tentu saja, ini tidak benar, tetapi seringkali mereka tidak percaya.

Menurut pendapat saya, inilah yang orang Jepang sebut Poka Yoke , yaitu, kita harus merancang sistem sedemikian rupa sehingga dengan desain mereka tidak akan memungkinkan pengguna menembak dirinya sendiri di kaki. Sekali lagi, sumber daya resmi berkualitas sangat baik untuk harganya, dan saya sangat merekomendasikannya.

Saya tidak suka sistem kepemilikan tersembunyi menurunkan frekuensi di luar kendali kami. Akan lebih baik jika sistem membeku: maka Anda dapat segera melihat apa yang terjadi, dan seseorang dapat mengganti catu daya. Menurut pendapat saya, ini lebih baik daripada menipu pengguna dan membuat mereka mengeluh di Internet . Sulit membayangkan alasan pengembang Pi akan melakukan ini jika mereka tidak menyembunyikan masalah Poka Yoke.

Periksa masalah daya

Butuh waktu terlalu lama, tetapi kami masih berhasil mencatat masalah di tingkat kernel. Jika Anda melihat pesan seperti itu di log sistem:

  kern: crit: [1701.464833 2.116656] Tegangan rendah terdeteksi!  (0x00050005)
 kern: info: [1707.668180 6.203347] Tegangan dinormalisasi (0x00000000 

maka Anda mengalami penurunan tegangan. Bagus bahwa sekarang Linux menangkap setidaknya informasi semacam itu, tetapi jika kita ingin tahu lebih banyak, kita perlu akses langsung ke GPU.

Perintah vcgencmd bisa mendapatkan informasi sistem dari firmware ThreadX.

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

Anda dapat menggunakan vcgencmd measure_clock arm vcgencmd measure_volts untuk memeriksa frekuensi dan tegangan yang sebenarnya. Berikut adalah contoh output dari skrip pemantauan tkaiser.

 # With a crappy PSU and/or Micro USB cable output looks like this # on a RPi 3: # # 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): # # 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): # # 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 # # 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 :) 

Kesimpulan

Saya benar-benar berpikir bahwa Raspberry Pi telah menjadi peristiwa yang sangat penting dalam sejarah komputer papan tunggal, tetapi hari ini ia tertinggal dalam hal kualitas, kinerja, dan keterbukaan. Ada alternatif yang terjangkau di mana pengembang lebih memperhatikan masalah ini.

Meskipun demikian, saya masih menggunakan Raspberry Pi, membantu pengguna mengatur cloud hosting mereka sendiri. Mengingat popularitas papan ini, masuk akal bagi saya untuk memeliharanya selama itu bermanfaat bagi orang-orang.