ข้อควรพิจารณาสำหรับ Raspberry Pi ที่ต้องทำงานระยะยาว

 (dzombak.com)
1 คะแนน โดย GN⁺ 2024-02-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากต้องการให้ Raspberry Pi ทำงานแบบ ไม่มีการแทรกแซง ตั้งแต่หลายสัปดาห์ไปจนถึงหลายปี ควรออกแบบเส้นทางการกู้คืนอัตโนมัติไว้ล่วงหน้าเมื่อเกิดความขัดข้อง
  • คู่มือนี้เป็นซีรีส์ด้านความน่าเชื่อถือที่กว้างขึ้น ซึ่งมาแทนบทความเดิมเรื่อง การลดการสึกหรอของ SD card โดยรวบรวมแนวทางรับมือตามประเภทปัญหาและเคล็ดลับการมอนิเตอร์ไว้ด้วยกัน
  • ความเสี่ยงหลักแบ่งเป็น การเชื่อมต่อ WiFi ล้มเหลว, บริการหยุดทำงาน, การแครชจากความไม่เสถียรของฮาร์ดแวร์·เฟิร์มแวร์·ไดรเวอร์, และ SD card สึกหรอหรือพื้นที่เต็ม
  • ปัญหา SD card สามารถบรรเทาได้ด้วยการเลือก microSD ที่เหมาะสม, ไม่ใช้ swap, ลดการเขียน, ใช้ root filesystem แบบอ่านอย่างเดียว, และรัน fsck เมื่อจำเป็น
  • แม้ การปิดใช้งาน journaling จะช่วยลดการสึกหรอได้ แต่จะเพิ่มความเสี่ยงที่ filesystem เสียหายเมื่อเกิดแครชหรือไฟดับ จึงไม่สอดคล้องกับเป้าหมายความเสถียรระยะยาว

จุดล้มเหลวที่ควรดูก่อนในการใช้งานระยะยาว

  • หากต้องการให้ Raspberry Pi ออนไลน์อยู่ได้เป็นเวลานาน ต้องพิจารณาว่า Pi จะกู้คืนอย่างไรในแต่ละสถานการณ์ขัดข้อง และควรเปรียบเทียบทั้งประโยชน์และความเสี่ยงของแนวทางแก้ไขด้วย
  • ผู้เขียนใช้ Raspberry Pi ภายในบ้านเป็น เครื่องส่ง FM กำลังต่ำ และตัวมอนิเตอร์พลังงานของ UPS เป็นต้น
  • ซีรีส์ Raspberry Pi Reliability รวบรวมประเภทปัญหาที่พบด้วยตนเองและวิธีแก้ไข โดยรวมถึงเคล็ดลับการมอนิเตอร์ที่ใช้ Uptime Kuma เป็นหลัก
  • ซีรีส์นี้มีเป้าหมายเป็นคู่มือที่ครอบคลุมกว่า บทความการลดการสึกหรอของ SD card เดิม และบทความที่ลิงก์ไว้ทำหน้าที่เป็นเนื้อหาทดแทนที่อัปเดตแล้ว

แนวทางรับมือแยกตามประเภทปัญหาและทางเลือกที่ควรหลีกเลี่ยง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-18
ความคิดเห็นบน Hacker News

  • ผมหันไปซื้อ Lenovo mini PC แทน ขนาด 18 ซม. x 18 ซม. x 3 ซม. ก็ยังเล็กมากอยู่ดี
    เดี๋ยวนี้หาซื้อได้ถูกมาก และมีเคสกับระบบระบายความร้อนที่เหมาะสมด้วย: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    ผมวางเครื่องหนึ่งไว้ข้างตัว ใช้ i5-8500T, RAM 32GB, SSD 2 ตัว และเมื่อเปิด auto tuning ของ powertop ตอน idle ตอนนี้กินไฟ 5W: https://wiki.archlinux.org/title/powertop

    • ไม่มี GPIO, I2C, SPI ถ้าแค่มองหาเซิร์ฟเวอร์ที่เล็กและเบา ก็เหมาะดี แต่ Raspberry Pi ได้รับความนิยมเพราะมี ความสามารถด้าน I/O ซึ่งหาได้ยากในอุปกรณ์สำหรับผู้บริโภค/สำนักงาน
      จะเพิ่มการเชื่อมต่อแบบ serial ไปยังไมโครคอนโทรลเลอร์ก็ได้ แต่ทำแบบนั้นแล้วโซลูชันจะไม่เรียบร้อยเท่าไร
    • ปีที่แล้วผมย้าย Kodi media player จาก RasPi 4 ไปเป็น N3350 mini PC และไม่เสียใจเลย
      ช่วงหลังยังย้าย NAS (N5105) กับเครื่องสำหรับรันบริการต่าง ๆ (3215U) ไปใช้ mini PC มือสองกับ Chromebook ที่ปลดล็อกแล้ว ซึ่งหามาจาก eBay หรือตลาดนัดของมือสองด้วย ราคาถูก กินไฟต่ำ แต่สมรรถนะการประมวลผลคนละระดับกับ Pi เลย
    • ผมก็ใช้แนวเดียวกัน แต่ใช้ Dell 7060
      ในออสเตรเลียมีของที่หมดสัญญาเช่าหลุดออกมาทีละหลายพันเครื่อง ชิป 8500T หรือ 8700T นั้นยอดเยี่ยม รัน Windows 11 ได้อย่างเป็นทางการ และมี hardware transcoding ในตัว จึงเหมาะเป็น Plex server
      เครื่องหนึ่งของผมอัปเกรดเป็น SSD 2TB สองตัวกับ RAM 64GB และรัน 24/7 ได้ไม่มีปัญหา
    • ผมก็เหมือนกัน ซื้อ Dell refurbished แล้วเรื่องจุกจิกลดลงมาก
      SD card น่าจะเป็นสาเหตุปัญหาใหญ่ที่สุด และถ้ารวมค่าใช้จ่ายในการต่อของอย่าง SSD เข้ากับ RPi แล้ว มันก็ไม่คุ้มราคาอีกต่อไป
    • เมื่อเทียบกับฮาร์ดแวร์ ARM ข้อดีก็คือรัน Linux distribution ได้แทบทุกตัว

  • คำแนะนำแรกไม่ควรเป็นการเปิดโหมด journaling ของ filesystem
    คำแนะนำแรกควรเป็นการ mount filesystem เป็นแบบ อ่านอย่างเดียว แล้ว mount /var ไว้ในหน่วยความจำ และส่ง log ทั้งหมดไปยัง node ที่มี UPS กับ NUT ที่เหมาะสม ไม่ใช่เก็บไว้บน RPi ถ้า filesystem เป็นแบบอ่านอย่างเดียวหรือเป็นพื้นที่ชั่วคราว ไฟดับก็แทบไม่สร้างความเสียหาย
    ถ้ามี RPi แค่เครื่องเดียวอาจดูเกินจำเป็น แต่ผู้เขียนบอกว่าใช้หลายเครื่องทั่วบ้าน
    นอกจากนี้ การมี system partition แบบ A/B แล้วอัปเกรดด้วยการเขียนทั้ง partition ใหม่ก่อนสลับ partition ที่ active ก็เป็นแนวทางที่ดีเช่นกัน แบบนั้นต่อให้เวอร์ชันใหม่มีบั๊กร้ายแรง ก็ยังมี system partition ที่ใช้งานได้เหลืออยู่เสมอ และกู้คืนได้ง่าย
    ผมใช้วิธีแบบนี้กับ PC ขนาดเล็ก/บอร์ดเดี่ยวหลายเครื่องในหลายบทบาทมาเกิน 20 ปีแล้ว และใช้งานได้ดี

    • ผู้เขียนใส่ลิงก์คำแนะนำเรื่อง การตั้งค่าแบบอ่านอย่างเดียว ไว้ในอีกไม่กี่บรรทัดถัดลงมา
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • ไม่ใช่แค่ /var แต่ควรใช้ tmpfs กับที่อย่าง /tmp ด้วย แบบนั้นอายุการใช้งานของ SD card จะเพิ่มขึ้นมาก
    • ถ้าจะอัปเกรดโดยมี system partition แบบ A/B แล้วเขียนทั้ง partition ใหม่ ผมสงสัยว่าขั้นตอนอัปเกรดเป็นอย่างไร
      สร้าง disk image ใหม่อย่างไร แล้วต้องล็อกอินเข้าไปอัปเกรดทีละเครื่องหรือมีระบบอัตโนมัติหรือไม่
    • ถ้า mount filesystem เป็นแบบอ่านอย่างเดียว แล้วจะอัปเดตระบบหรือติดตั้งซอฟต์แวร์ใหม่อย่างไร
    • ถ้าใช้ของอย่าง Docker เมื่อ mount /var ไว้ในหน่วยความจำ อาจใช้หน่วยความจำของอุปกรณ์เกินได้
      อาจต้องย้าย /var/lib/docker ไปไว้ใน storage เสริม

  • ในปี 2011 ผมเคยทำผลิตภัณฑ์เชิงพาณิชย์ที่รันบน plug computer รุ่นแรก ๆ ของ Global Scale Technologies
    ขายไปแค่ 20 กว่าเครื่อง แต่ถูกส่งคืนทั้งหมดเพราะปัญหา SD card เสียหาย และต้องรีบเปลี่ยน root filesystem ให้เป็นแบบอ่านอย่างเดียว หลังจากนั้นผมก็ชอบแนวทางนี้มาตลอด
    ผลิตภัณฑ์เชิงพาณิชย์ยุคแรกนั้นเป็นผลิตภัณฑ์รักษาความปลอดภัยในบ้านที่มีฟังก์ชัน home automation เล็กน้อย และในปี 2021 ได้เปิดซอร์สภายใต้ชื่อใหม่ ตอนนี้ทำงานบนคอมพิวเตอร์บอร์ดเดี่ยวตระกูล Jetson: https://github.com/hcfman/sbts-install
    ตอนนี้มีโมเดล YOLO ระดับสูงเป็น trigger ด้วย เพราะตั้งใจให้เป็นผลิตภัณฑ์แบบ standalone จึงรองรับ HTTPS และมี GUI ที่ครอบงานเกี่ยวกับ certificate ทั้งหมดไว้ ฟีเจอร์นี้ยังคงอยู่ในเวอร์ชันโอเพนซอร์ส ทำให้ใช้ self-signed certificate สำหรับการเรียก REST ระหว่างอุปกรณ์ได้ง่าย
    นอกจากนี้ยังรักษาและขยายแนวทาง overlayFS แบบหน่วยความจำหลาย partition และในขั้นตอนติดตั้งจะให้ติดตั้งระบบ sbts-base ก่อน เพื่อให้คนอื่นนำไปใช้เป็นระบบฐานของตัวเองได้

    • ผมมีประสบการณ์คล้ายกัน เคยดัดแปลง PC Pentium 2 ราคา 5 ดอลลาร์ให้เป็นเวิร์กสเตชันแบบ fanless และเงียบสนิท โดยเปลี่ยน HDD เป็น CF card
      พอเวลาผ่านไป ระบบเริ่มค้าง 1–2 วินาทีทุกครั้งที่มีการเขียนดิสก์ ซึ่งทรมานพอสมควร

  • สำหรับคนที่คิดจะทำอะไรแบบนี้ ผมอยากแนะนำให้ลองดูก่อนว่า บอร์ดขนาดเล็กอย่าง ESP32 จัดการงานที่ต้องการได้หรือไม่
    ใช้พลังงานน้อยกว่ามาก ราคาก็แค่ไม่กี่ดอลลาร์ และเพียงพอสำหรับการใช้งานหลายอย่าง ถ้าชอบฝั่ง Python บอร์ดจำนวนมากรองรับทั้ง MicroPython และ CircuitPython
    ลดได้ทั้งค่าใช้จ่ายตอนซื้อครั้งแรกและค่าไฟที่ต้องจ่ายต่อเนื่อง จึงคุ้มค่าที่จะลองพิจารณา

    • เข้าใจข้อโต้แย้งเรื่องต้นทุนด้านเวลาและความซับซ้อนของการเขียนโปรแกรมแบบ embedded แต่ถ้าเป็นผู้ใช้สายงานอดิเรก ผมมองว่านี่เป็นคำแนะนำที่ดีและอย่างน้อยก็ควรพิจารณา
      โปรเจกต์ที่ทำด้วยไมโครคอนโทรลเลอร์มีความเสถียรกว่าโปรเจกต์ที่ใช้ Pi ในระดับหลายสิบปี และยังไม่ต้องกังวลมากนักว่าจะลืมเปลี่ยนค่า SSH พื้นฐานจนกลายเป็นส่วนหนึ่งของบอตเน็ต ค่าเริ่มต้นน่าจะเป็น pi:raspberry ใช่ไหม
      นอกจาก MicroPython แล้ว การรองรับ no_std Rust สำหรับ ESP32C3 ก็ดีขึ้นทุกเดือน สำหรับคนที่ทำโปรเจกต์ home automation เล็ก ๆ สนุก ๆ ข้อจำกัดที่เพิ่มขึ้นอาจทำให้สนุกและคุ้มค่ามากขึ้นด้วยซ้ำ
      อย่างไรก็ตาม สำหรับคนที่คุ้นกับ Linux อยู่แล้ว Pi มักง่ายกว่ามาก และจากประสบการณ์ของผม ค่าใช้จ่ายแพงกว่าอย่างน้อยราว 10 เท่า ควรเอาการตั้งค่าเพิ่มเติมเพื่อให้ได้ความเสถียรระดับเดียวกัน เช่น การบูตจาก SSD, การบูตผ่านเครือข่าย, root filesystem แบบอ่านอย่างเดียว, การตั้งค่า watchdog รวมถึงการใช้พลังงานที่สูงกว่า โดยเฉพาะไฟของ Pi 5 มารวมในการตัดสินใจด้วย
    • บน ESP32 รัน media server ได้ไหม? ไม่ได้
      บน ESP32 รันเซิร์ฟเวอร์ password manager ได้ไหม? ไม่ได้ Pi-hole ล่ะ? ไม่ได้ Unifi controller? ไม่ได้
      คำแนะนำแบบนี้เหมือนจินตนาการว่าคนเอา Pi ไปใช้กับอะไรอย่างตัวควบคุมประตูโรงรถ แต่การเสนอ ESP32 เป็นตัวแทน Pi แบบอัตโนมัติไม่ได้ช่วยอะไรมากนัก
    • ESP32 และบอร์ดที่เกี่ยวข้องเจ๋งมากก็จริง แต่ต้องใช้วิธีคิดที่ต่างไปอย่างสิ้นเชิง
      เวลาอะไรบางอย่างไม่ทำงาน คุณไม่สามารถเสียบ HDMI กับคีย์บอร์ด แล้วดีบักสด ๆ ในสภาพแวดล้อม Linux mainline ที่มี utility ทั่วไปครบถ้วนได้
    • Pi Zero มีค่าไฟประมาณปีละ 1 ดอลลาร์
    • ช่วงหลังในชุดที่ซับซ้อนขึ้นเล็กน้อย ผมใช้ Pi Zero หนึ่งตัวคุยกับ ESP8266/32 หลายตัวผ่าน HTTP และ Wi‑Fi
      เพิ่งลองใช้ MicroPython แทน Arduino เป็นครั้งแรกแล้วชอบมาก และน่าประหลาดใจที่มันเสถียรมาก เมื่อก่อนโปรเจกต์มักพังในระยะยาวเพราะสถานะพลังงานของ Wi‑Fi แต่จนถึงตอนนี้ในโครงสร้างแบบ MicroPython ยังไม่มีปัญหา

  • ประโยคที่ว่า “สุดท้ายส่วนใหญ่ก็มักกลายเป็นสคริปต์ที่คอยตรวจเป็นระยะว่า Wi‑Fi ยังเชื่อมต่อดีอยู่ไหม ถ้าไม่ดีก็รีสตาร์ตอินเทอร์เฟซ Wi‑Fi หรือทั้ง Pi” นั้นไม่ใช่การแฮ็ก แต่เป็น แนวปฏิบัติที่ดี
    เช่นเดียวกับที่เซิร์ฟเวอร์สำคัญในดาต้าเซ็นเตอร์ควรมีช่องทาง out-of-band อย่าง IPMI หรือปลั๊ก RPDU ที่ควบคุมระยะไกลได้ เซิร์ฟเวอร์สำคัญในจุดห่างไกลที่เข้าถึงยากก็ควรมีสคริปต์ watchdog
    แน่นอนว่าต้องปรับให้เหมาะกับการใช้งาน โดยคำนึงถึงผลกระทบของการรีบูตและช่วง downtime ก่อนรีบูต และอย่างน้อยก็ควรบันทึกเหตุการณ์ผิดปกติไว้เพื่อให้ตรวจสอบภายหลังได้
    ตอนที่ผม deploy RPi ระยะไกล สิ่งแรกที่ทำคือสคริปต์ watchdog แบบ Bash ง่าย ๆ ไม่ใช่แค่สำหรับปัญหา Wi‑Fi แต่สำหรับสถานการณ์อีกเป็นสิบ ๆ แบบที่อาจพังและแก้ได้ด้วยการรีบูต

    • ทุกวันนี้ในดิสโทรส่วนใหญ่ บทบาท watchdog แบบนี้เป็นหน้าที่ของ init/PID 1 หรือก็คือ systemd
      ถ้าเราเชื่อใจ init ให้จัดการ service ไม่ได้ ก็สงสัยเหมือนกันว่าความมั่นใจว่าระบบจะให้บริการได้มาจากไหน
      จะสร้างใหม่ด้วยสคริปต์ก็ได้ แต่เราผ่านจุดนั้นมาแล้ว ผมพูดถึง systemd เยอะ แต่ไม่ได้จะลำเอียงเข้าข้างมัน และยังมีทางเลือกอื่นด้วย
      service ส่วนใหญ่ไม่ได้ใช้ประโยชน์จากสภาพแวดล้อมที่มันอยู่ให้ถูกต้อง ดูเหมือนจะคาดหวังการปรับแต่งเฉพาะไซต์ เช่น ประกาศว่าเว็บเซิร์ฟเวอร์ต้องการ mount บางตัว
      directive ที่มักถูกมองข้ามคือ PartOf= ซึ่งสามารถผูกการรีสตาร์ตของ service หรือ resource หนึ่งเข้ากับอีกอย่างได้
      ถ้าให้ง่ายกว่านั้น NetworkManager ก็น่าจะมีวิธีให้ปรับแต่งการตรวจ Wi‑Fi/portal ได้ อาจไม่จำเป็นต้องไปสุดโต่งขนาดนั้น
    • ผมทำคล้าย ๆ กันด้วย ESP8266 เพื่อเฝ้าดูเราเตอร์ Wi‑Fi กับเคเบิลโมเด็ม ถ้ามีปัญหาก็รีบูต
      สำหรับเราเตอร์ มันจะพยายามเชื่อมต่อกับ SSID ที่เหมาะสมแล้ว ping ไปที่เราเตอร์ ถ้าอย่างใดอย่างหนึ่งล้มเหลว ก็สลับไปใช้อีกเราเตอร์หนึ่ง ผมมีเราเตอร์รุ่นเดียวกันสองตัวที่ตั้งค่าเหมือนกัน และต่อไฟเข้ากับหน้าสัมผัส NO/NC ของรีเลย์ SPDT ถ้าตัวหนึ่งล้มเหลว ก็แค่เปลี่ยนสถานะรีเลย์เพื่อสลับไปอีกฝั่ง
      ถ้าเราเตอร์ยังมีชีวิตอยู่ watchdog จะโหลดหน้าสถานะของเคเบิลโมเด็ม และ ping ไปยัง IP ใดก็ได้จากสาม IP ในเครือข่าย ISP ที่ดูเหมือนเป็น CMTS หรืออุปกรณ์ใกล้เคียง เพื่อยืนยันว่าโครงข่าย HFC ยังทำงานอยู่ เพราะถ้าเป็นความขัดข้องที่แก้ด้วยการรีบูตไม่ได้ ก็ไม่อยากรีบูตโดยเปล่าประโยชน์
      น่าเสียดายที่ผมหาวิธีมีเคเบิลโมเด็มสองตัวที่ใช้ MAC เดียวกันแล้วสลับกันไม่ได้ และ ISP ก็ไม่อนุญาตให้มีโมเด็มสองตัวในบัญชีเดียวกัน ดังนั้นถ้าเคเบิลโมเด็มล้มเหลว ก็ทำได้แค่รีบูตแล้วหวังว่าจะกลับมาดี
      ผมยังต่อ rack แบตเตอรี่ที่ทำให้เราเตอร์และโมเด็มทำงานต่อได้เกิน 30 ชั่วโมงแม้ไฟดับ และตั้งแต่ทำขึ้นในเดือนพฤษภาคม 2020 มันก็ออนไลน์แทบตลอด โค้ดแย่มาก แต่ในการใช้งานจริงมันทำงานได้แข็งแรงมาก
    • เห็นด้วยอย่างยิ่ง watchdog timer เป็นสิ่งจำเป็นสำหรับไมโครคอนโทรลเลอร์และคอมพิวเตอร์ที่รันซอฟต์แวร์ “ตลอดไป”
      มีสิ่งที่เกิดขึ้นได้แม้โค้ดและการออกแบบจะสมบูรณ์แบบ เช่น บิตพลิกจากเหตุการณ์ในอวกาศ หรือแรงดันตกชั่วขณะ และ watchdog timer จะตัด infinite loop แล้วรีเซ็ตให้ ใน Raspberry Pi ยังต้องกังวลเรื่อง SD card เสียหายด้วย
      เท่าที่รู้ Raspberry Pi มี hardware watchdog timer ในตัว ส่วน Arduino มีแน่นอน
    • เป็นทั้งแนวปฏิบัติที่ดีและเป็นการแฮ็กไปพร้อมกัน มันไม่ควรจะจำเป็น แต่เพราะมีบั๊กอยู่ จึงกลายเป็นสิ่งจำเป็น

  • ตลอดเกือบ 10 ปีที่ผ่านมา ได้ใช้งาน Pi หลายพันเครื่อง ในสภาพแวดล้อมจริง และตอนนี้เริ่มย้ายไป x86 แล้ว
    ความคุ้มค่าด้านราคาต่อประสิทธิภาพของ Pi ไม่เหมือนเดิมแล้ว เมื่อไม่นานมานี้ได้พูดถึงประสบการณ์นี้ที่ State of Open Con: https://youtu.be/vX-qK9mxKZI

    • ในฐานะเพื่อนร่วมวงการที่เป็น CEO ดิจิทัลไซเนจบน Raspberry Pi ผมแปลกใจที่ในพรีเซนต์ไม่ได้พูดถึงการรองรับ secure boot ที่เป็นไปได้ตั้งแต่ Pi 4
      บริการของเรายังไม่ได้ใช้ แต่ตามเอกสารแล้วดูค่อนข้างแข็งแรง และสามารถปกป้องข้อมูลบนดิสก์/SD ได้
      เรายังค่อนข้างพอใจกับ Pi และการย้ายไปใช้ API ที่เปิดกว่ามากอย่าง Mesa/DRM/KMS/FFmpeg ซึ่งเพิ่งเริ่มอยู่ในสภาพที่ใช้งานได้จริง ก็ดูมีอนาคตมาก
      เนื่องจากกรณีใช้งานหลักยังเป็นดิจิทัลไซเนจ พลังประมวลผลดิบจึงไม่ได้สำคัญมากนัก ส่วนที่มีต้นทุนสูงอย่างการถอดรหัสวิดีโอก็แน่นอนว่ามีการเร่งความเร็วด้วยฮาร์ดแวร์ และความเข้ากันได้ย้อนหลังที่ Pi ทำได้นั้นยอดเยี่ยม ยังมีลูกค้าที่ใช้ Pi1B+ ต่อเนื่องมาเกือบ 10 ปี และยังรัน OS รุ่นล่าสุดที่เราให้บริการอยู่
    • ต้องพิจารณารูปแบบการใช้งานด้วย ถ้าอยู่ในสถานะ idle เป็นส่วนใหญ่ ผมมองว่า ARM ดีกว่า x86
      ต้องดูเรื่องอายุการใช้งานด้วย ซึ่งตรงนั้น ARM ก็น่าจะอยู่ได้นานกว่า x86 เช่นกัน ในแง่โมดูลาร์ ARM ก็ดีกว่า x86 เพราะการวางอุปกรณ์เล็ก ๆ หลายตัวมีต้นทุนถูกกว่า
      แต่ด้านความสามารถในการขยาย หรือความคุ้มค่าทางธุรกิจในเศรษฐกิจปัจจุบัน x86 ดีกว่า ARM
      อีกอย่าง กราฟทั้งหมดควรเทียบตามวัตต์ การบอกว่าจากรุ่น 2 ไป 4 แล้วประสิทธิภาพดีขึ้นไม่ใช่ข่าวใหม่ สิ่งสำคัญคือประสิทธิภาพต่อวัตต์ดีขึ้นหรือไม่
      ถ้าดูแบบนั้นจะเห็นว่า Raspberry Pi 5 ไม่ได้มีประสิทธิภาพต่อวัตต์ดีขึ้นมากเท่าที่คาด ดูเหมือนเราจะมาถึงจุดสูงสุดถาวรในประวัติศาสตร์มนุษย์แล้ว
      สุดท้าย ณ ตอนนี้ ความหวังเดียวของความก้าวหน้าใด ๆ ไม่ใช่ด้านประสิทธิภาพ แต่เป็นด้านความเปิดกว้าง คือ JH7110 ทว่า การรองรับ 3D ยังตามหลังอยู่
    • สงสัยว่าใช้สำหรับขับจอแสดงผล หรือเป็นอุปกรณ์ปฏิบัติการที่ใช้ GPIO อย่างเครื่องจักรประกอบในการผลิต
    • สงสัยว่าการย้ายไป x86 หมายถึงอะไรกันแน่

  • แม้ไม่ได้ทำอะไรพวกนั้นเลย Pi บางตัวก็ทำงานได้หลายปีโดยไม่มีปัญหาจนกระทั่งถูกแทนที่ด้วยรุ่นใหม่
    เกตเวย์ HomeKit/Zigbee และ data logger ตอนนี้เป็น Pi 4 สุดท้ายแล้วดูเหมือนหัวใจสำคัญคือ SD card ที่ดีและแหล่งจ่ายไฟที่เสถียร

    • เห็นด้วย ผมเองก็ใช้ Pi มาหลายตัว และตอนที่เสียก็เป็นเพราะ SD card เสีย
      คิดว่า pibenchmark เป็นแหล่งข้อมูลที่ดี: https://pibenchmarks.com/
      ก่อนซื้อควรเปรียบเทียบ SD card ให้ดี
    • ผมคิดว่าขนาดตัวอย่างมีผลต่อประสบการณ์มากกว่า
      ถ้าดูแลอุปกรณ์จำนวนมากพอ อะไรที่อาจผิดพลาดได้ก็จะผิดพลาดทั้งหมด และยังจะมีรูปแบบความเสียหายใหม่ ๆ ที่ไม่เคยนึกฝันมาก่อนโผล่มาด้วย
    • Raspbian OS รุ่นเก่าช่วงราวปี 2016 และก่อนหน้านั้นเปิด การบันทึกเวลาเข้าถึง ไว้ ทำให้ทุกครั้งที่อ่านไฟล์ก็เกิดการเขียนด้วย
      เหตุผลที่หลังจากนั้นมีรายงานการ์ดเสียหายจำนวนมากอาจเป็นเพราะเรื่องนี้
    • ผมก็คล้ายกัน ใช้ Pi3 หลายตัวเป็นเซิร์ฟเวอร์ Cups มาหลายปีแล้ว uptime จะรีเซ็ตเฉพาะตอนไฟดับเท่านั้น ซึ่งไฟดับก็เกิดน้อยมาก
      นอกจากติดตั้ง Raspbian ลงใน micro SD card, ตั้งค่า Cups และต่อ USB เข้ากับพรินเตอร์แล้ว ก็ไม่ได้ทำอะไรอีก อีกตัวหนึ่งดูแลพรินเตอร์เครือข่าย หลังจากนั้นก็ปล่อยไว้อย่างนั้น
    • แปรปรวนมาก บางตัวมีปัญหาไม่รู้จบ แต่อีกบางตัวก็ใช้งานได้นานโดยไม่เป็นอะไร ไม่เห็นรูปแบบชัดเจน
      ตอนนี้ส่วนใหญ่เปลี่ยนไปใช้ SSD แล้ว ไม่อย่างนั้นมันเหมือนเสี่ยงดวงเกินไป

  • แปลกใจที่เรื่อง SD card ไม่ได้เป็นข้อแรก และยิ่งแปลกใจกว่าที่บทความไม่ได้แนะนำ การบูตผ่าน USB
    ผมเปิด Pi ตัวหนึ่งแทบจะ 24/7 มาหลายปีแล้ว และคิดว่าสาเหตุที่ไม่มีปัญหาคือ 1) ตั้งค่า Alpine ให้แทบไม่แตะดิสก์เลย 2) ไม่มี SD card ให้เสียหาย ส่วนทำไม USB ถึงเสถียรกว่านั้นไม่รู้ แต่จากประสบการณ์ก็เป็นแบบนั้น

    • ชุด Argon Raspberry ของผมที่ต่อ SSD ก็เสถียรเช่นกัน
      เหตุผลเดียวที่มันล้มเหลวคือไฟดับ ถ้ามีแบตเตอรี่ที่อยู่ได้สัก 10 นาที ก็น่าจะเพียงพออย่างสมบูรณ์
    • อยากรู้ว่าตั้งค่า Alpine ให้แทบไม่แตะดิสก์ได้อย่างไร
      เช่น หมายถึงแบบ https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode หรือเปล่า
    • เคยมี Pi หลายตัวที่รันจาก SD ได้โดยไม่มีปัญหา แต่มีตัวหนึ่งที่จู่ ๆ SD card ก็ร้อนมาก และเป็น Pi ใหม่ที่กำลังตั้งค่าอยู่พอดี
      เลยถอดการ์ดออก แล้วเปลี่ยนทั้งการ์ดนั้นกับ Pi ตัวถัดไปไปใช้ USB SSD แทน ค่อนข้างน่ากลัว แต่ก็อย่างที่บอกไป Pi ที่ใช้ micro SD เป็นเซิร์ฟเวอร์ Cups มาหลายปีก็ไม่มีปัญหา
    • เห็นด้วยอย่างยิ่ง ความเสียหายของ RPi ของผมทั้งหมดเกิดจาก SD card
      RPi สองตัวของผมบูตและรันจาก USB ทั้งคู่ และทำงานได้ดีมาหลายปีแล้ว
    • ผมก็เหมือนกัน บูตจาก SSD ผ่าน M.2 HAT และทำงานได้ดีมาก

  • ตั้งแต่ปี 2017 ผมรัน Pi สองเครื่องด้วย SD card ใบเดิมแทบจะตลอดเวลา มีไฟดับประมาณ 2–3 ครั้ง
    เครื่องหนึ่งเป็น DNS/print server อีกเครื่องเป็น Kodi โดยสื่ออยู่บน NFS ภายนอก สิ่งเดียวที่ผมทำคือปิด log ทั้งหมด และไม่เคยมีปัญหาเลย
    ทั้งคู่ใช้ การ์ด SanDisk 2GB อยู่ ผมจำได้ลาง ๆ ว่าตอนนั้นคิดแบบซื่อ ๆ ว่า “พื้นที่น้อย → ความหนาแน่นของบิตต่ำ → ความน่าเชื่อถือดี”

    • ใช้ log2ram (github/azlux/log2ram) มาตลอด และพอใจกับผลลัพธ์
      มัน mount RAM disk ไว้ที่ /var แล้วค่อย ๆ คัดลอก log จาก RAM disk ไปยัง SD card เป็นครั้งคราว ทำให้ยังดู log ทั้งหมดได้โดยไม่ต้องเขียนกระหน่ำใส่ SD card
    • รัน Kodi บน Pi 1 ด้วย SD card ใบเดิมมาตั้งแต่แรก เกือบ 10 ปีแล้ว
      ส่วนใหญ่เปิดอยู่ตลอด แต่บางครั้งเผลอปิดแหล่งจ่ายไฟ USB ที่ต่ออยู่ เป็นแหล่งจ่ายไฟเล็ก ๆ แบบ 5 พอร์ต ซึ่งก็อายุไล่เลี่ยกัน และในชุดของผมปุ่มเปิด/ปิดกดโดนได้ง่ายเกินไป
    • มี RPi เครื่องหนึ่งที่รันไม่หยุดด้วย SD card ใบเดิมมาตั้งแต่ปี 2014 ใช้ให้บริการเว็บไซต์สภาพอากาศ
      โดยพื้นฐานแล้ว mount log ทั้งหมดและเว็บเพจไว้บน tmpfs ส่วน DB อยู่บน SD card และถูกเขียนทุก 5 นาที
    • ยังมี Pi เครื่องแรกอยู่ น่าจะเป็น Pi 1B
      ผ่านการติดตั้งมาหลายแบบ แต่ตอนนี้เป็น DNS server สำรอง ดูจาก filesystem แล้วใช้เป็น Pi-hole มาตั้งแต่ปี 2018 และนอกจากการ reboot ไม่กี่ครั้งกับตอนย้ายบ้าน ก็เรียกได้ว่ารัน 24/7 จริง ๆ
      ไม่เขียนอะไรลง SD เลย ส่งทุกอย่างไปไว้ใน RAM ที่ /dev/shm ถ้า Pi-hole ล่มนาน ๆ ครั้ง ก็แค่ให้มันดึงรายการใหม่ และอย่างไรก็ดาวน์โหลดทุกวันอยู่แล้ว
    • ผมก็เหมือนกัน มี Raspberry Pi 3 สองเครื่อง รัน Pi-hole เพื่อบล็อกโฆษณามาตั้งแต่ปี 2019
      ภายหลังเริ่มใช้เป็น DNS ภายในและ node ของ Tailscale ด้วย เคยไม่ reboot อยู่หลายเดือน และ uptime สูงสุดประมาณ 11 เดือน ทนทานมาก การต่อเข้ากับ UPS ช่วยได้อย่างชัดเจน

  • มีคนบอกว่า “การทำให้ Raspberry Pi ออนไลน์อยู่ได้โดยไม่ต้องแตะเป็นเวลาหลายสัปดาห์ หลายเดือน หรือหลายปีนั้นเป็นศิลปะอย่างหนึ่ง” แต่ผม boot เคอร์เนล NetBSD ที่มี filesystem ฝังอยู่ในตัว
    เช่น ใช้เคอร์เนล INSTALL หรือเคอร์เนลที่ปรับแต่งเอง หลัง boot แล้วจะถอด SD card ออกก็ได้ และเลือก chroot ไปยัง storage ที่ต่ออยู่ได้
    ทำแบบนี้แล้วมันรันได้เป็นสัปดาห์ เป็นเดือน เป็นปี ไม่เคยเจอปัญหาที่ผู้เขียนบล็อกยกมา
    ปัญหาเดียวที่ผมพบคือฝั่งขั้วต่อไฟเมื่อใช้เคส เช่น ถ้าใช้สายทดแทน การเชื่อมต่ออาจหลวมได้ ใน Pi รุ่นใหม่ ๆ อาจดีขึ้นแล้วก็ได้
    แต่ก็คงพูดได้ว่าคอมพิวเตอร์ส่วนใหญ่ก็คล้ายกัน สายและขั้วต่อมักเป็นชิ้นส่วนที่อ่อนแอและราคาถูก ถ้าไฟหลุดเพราะการขยับ Pi ก็จะ reboot เอง