การปรับแต่งการบูต Pi แบบสุดขีด

 (kittenlabs.de)
4 คะแนน โดย GN⁺ 2024-09-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SolarCamPi เป็นกล้องพลังงานแสงอาทิตย์แบบออฟกริดที่เปิด Raspberry Pi Zero 2 W เฉพาะตอนถ่ายภาพแล้วปิดทันที ดังนั้นเวลาบูตจึงส่งผลโดยตรงต่ออายุแบตเตอรี่
  • เมื่อวัดโดยให้ /init.sh เป็นโค้ด user space ตัวแรกบน Debian 12 arm64 Lite การบูตเริ่มต้นใช้เวลาประมาณ 12 วินาที และใช้พลังงาน 9.5Ws
  • มีการตัดการรอและการตรวจจับที่ไม่จำเป็นออก โดยลด HDMI, LED, HAT/PoE/LCD, การตรวจจับกล้องและจออัตโนมัติ รวมถึง initramfs ทำให้กระแสลดจาก 136.7mA → 120.6mA
  • หลังย้ายไปใช้ Buildroot 2024.02.1 และเคอร์เนลปรับแต่งเอง พร้อมตัดไดรเวอร์ การบีบอัด KASLR และฟีเจอร์ mitigations บางส่วนออก ก็สามารถไปถึงโปรแกรม Linux user space ได้ในเวลา ต่ำกว่า 3.5 วินาที
  • เมื่อลดแรงดันไฟเข้าจาก 5.0V เหลือ 3.6V พลังงานรวมลดจาก 1.754Ws → 1.438Ws แต่ยังเป็นการทำงานนอกสเปก จึงยังต้องตรวจสอบเสถียรภาพและความน่าเชื่อถือ

ทำไม SolarCamPi ต้องลดเวลาบูต

  • SolarCamPi คือกล้อง WiFi พลังงานแสงอาทิตย์ที่บูต Raspberry Pi Zero 2 W เป็นระยะเพื่อถ่ายรูป อัปโหลดผ่าน WiFi ไปยังบริการคลาวด์ แล้วปิดเครื่องอีกครั้ง
  • ในสภาพแวดล้อมที่พลังงานขาดแคลน เช่น ฤดูหนาวในยุโรปตะวันตก ทุกวินาทีที่ Pi เปิดอยู่คือค่าใช้จ่ายด้านพลังงาน
  • แอปพลิเคชันใน user space ที่เชื่อมต่อเซิร์ฟเวอร์และอัปโหลดรูปถูกปรับแต่งไว้มากที่สุดแล้ว และวงจรอิเล็กทรอนิกส์ก็ถูกออกแบบให้ลดการใช้พลังงานระหว่างโหมดพักด้วย
  • เส้นทางที่ยังพอลดได้จึงเหลือ 2 แบบ
    • ลดกระแสไฟที่ใช้
    • ลดเวลาที่ใช้รัน
  • การลดเฉพาะกระแสไม่ได้แปลว่าจะคุ้มเสมอไป
    • เช่น ปิด CPU turbo แล้วกระแสลดลง แต่ถ้าเวลารันนานขึ้น พลังงานรวมอาจมากกว่าเดิม
    • เป้าหมายคือทำให้พื้นที่ใต้กราฟกระแสกับเวลาน้อยที่สุด

อุปกรณ์วัดและวิธีทดสอบ

  • ในการปรับแต่งการบูตของระบบฝังตัว จำเป็นต้องตรวจผลจริงหลังแก้ไขได้รวดเร็ว ดังนั้นเครื่องมือที่ช่วยลดการถอด SD card และการเปิดปิดไฟจึงสำคัญ
  • อุปกรณ์ที่ใช้มีดังนี้
  • Power Profiler Kit II จ่ายไฟให้กับอุปกรณ์ทดสอบพร้อมวัดการใช้พลังงานตามเวลา และอ่านสถานะอินพุตดิจิทัล 8 ช่องไปพร้อมกัน
    • มีการต่อ GPIO ของ Raspberry Pi เข้ากับอินพุตดิจิทัล
    • โดยให้แอปพลิเคชันสลับสถานะ GPIO เป็นการทำงานแรก เพื่อวัดเวลาตั้งแต่เริ่มจ่ายไฟจนถึงจุดที่โค้ด user space เริ่มทำงาน
  • USB-SD-Mux เป็น interposer ที่คั่นระหว่าง microSD card กับตัวอุปกรณ์ ทำให้คอมพิวเตอร์ดึงการ์ดไปเขียนใหม่แล้วส่งคืนให้อุปกรณ์ได้
    • ช่วยตัดงานซ้ำ ๆ อย่างการถอดการ์ด เสียบกับ card reader แล้วใส่กลับเข้าเครื่อง
    • และยังใช้ onboard GPIO เพื่อทำ automation สำหรับรีเซ็ตหรือควบคุมไฟของอุปกรณ์ทดสอบได้ด้วย
  • คอนโซล USB-UART จำเป็นสำหรับตรวจสถานะเมื่อระบบพัง เช่น บูตไม่ขึ้นหรือมีปัญหา WiFi

วัดการบูตบน Debian

  • บน Debian 12 bookworm arm64 Lite แบบสะอาด มีการเพิ่ม init=/init.sh ลงใน /boot/firmware/cmdline.txt
  • การตั้งค่านี้ทำให้เคอร์เนลรัน /init.sh เป็นโปรเซสแรกของ user space ก่อน systemd
  • ตัวอย่าง init.sh จะสลับสถานะ GPIO4 แล้ว exec /sbin/init เพื่อให้บูตต่อด้วย systemd
  • การวัดครั้งแรกพบว่าประมาณ 12 วินาที หลังเปิดเครื่อง อินพุตดิจิทัล 0 จะเป็น low ซึ่งยืนยันว่า init.sh เริ่มทำงานแล้ว
  • กระบวนการบูตนี้ใช้ทั้งหมด 1.90 coulomb
    • 1.9As * 5.0V = 9.5Ws
    • ถ่านอัลคาไลน์ AA หนึ่งก้อนให้พลังงานได้ประมาณ 13500Ws

ลดกระแสไฟที่ใช้

  • เมื่อตัด HDMI encoder ออกทั้งหมด กระแสลดจาก 136.7mA เหลือ 122.6mA
    • แต่ GPU ปิดไม่ได้ เพราะยังต้องใช้เข้ารหัสข้อมูลจากกล้อง
    • ถ้าเป็นแอปพลิเคชันที่ไม่ต้องใช้กล้องหรือ GPU ก็อาจลองปิด GPU ได้
  • การปิด activity LED เพียงอย่างเดียวช่วยประหยัดได้ 2mA ทำให้กระแสลดจาก 122.6mA เหลือ 120.6mA
  • หากมีกล้องที่มี LED ก็สามารถปิดได้เช่นกัน
    • และยังช่วยลดโอกาสที่แสง LED จะสะท้อนเข้าไปในภาพ
  • ในการทดสอบเปลี่ยนค่า turbo พบว่า Pi ในสถานะที่ปรับแต่งปัจจุบันใช้ 1.62As
    • ถ้ารันโดยไม่บังคับ turbo จะใช้ 1.58As
    • ด้วยเหตุผลที่ไม่ทราบแน่ชัด เมื่อปิดโหมด turbo/boost สถานะเริ่มต้นของ GPIO4 กลับด้าน จึงต้องสลับ polarity ใน init.sh

ลดเวลาบูต

  • แม้กระแสจะลดลงราว 13% แต่กว่าจะมีข้อความแรกจาก Linux โผล่บนคอนโซลก็ยังใช้เวลาประมาณ 8 วินาที และช่วงนี้กินไฟไปราว 1As
  • ในตระกูล Raspberry Pi จะเป็น GPU ที่เริ่มต้นก่อน
    • GPU จะค้นหา bootcode.bin จาก SD card
    • ส่วน Pi 4 ขึ้นไปใช้ EEPROM
  • หากเปิด BOOT_UART ใน bootcode.bin จะดู log UART แบบละเอียดได้
    • ควรสำรอง bootcode.bin ต้นฉบับไว้ และขั้นตอนแก้ไขนี้มีความเสี่ยงที่จะทำให้ระบบเสียหายได้
  • บูตโหลดเดอร์พยายามตรวจจับพารามิเตอร์วิดีโอของจอ HDMI ที่ต่ออยู่โดยอัตโนมัติ จึงต้องรอคำตอบ EDID
    • เนื่องจากไม่ได้ใช้ HDMI จึง hardcode สตริง EDID เพื่อตัดขั้นตอนตรวจจับนี้
  • ยังมีการปิดการตรวจจับ I2C EEPROM ที่เกี่ยวกับ HAT, พัดลม PoE, LCD และทัชสกรีนด้วย
    • ตัวเลือกเหล่านี้ต้องรอการตอบสนองจากบัส I2C จึงควรปิดถ้าไม่จำเป็น
  • การตรวจจับกล้องและจอ MIPI แบบอัตโนมัติก็กินเวลาเช่นกัน
    • เนื่องจากกล้องที่ใช้ถูกกำหนดแน่นอนว่าเป็น HQ Camera IMX477 จึงปิดด้วย camera_auto_detect=0, display_auto_detect=0 และโหลด dtoverlay=imx477 โดยตรง
  • หลังปรับตามนี้ เวลา boot ที่รายงานเองลดจาก 5.38 วินาที เหลือ 4.75 วินาที และเมื่อลบ auto_initramfs=1 เพื่อปิด initramfs ก็ลดต่อได้ถึง 4.47 วินาที
  • วิธี sdtweak ที่โอเวอร์คล็อกอุปกรณ์ SD เป็น 100MHz ไม่ทำให้ประสิทธิภาพการบูตต่างอย่างมีนัยสำคัญ
    • อีกทั้งยังมีความเสี่ยงข้อมูลเสียหายตอนเขียน จึงไม่เหมาะกับอุปกรณ์ IoT ระยะไกล

คอขวดของการโหลดเคอร์เนลและการย้ายไป Buildroot

  • ณ จุดนี้ การโหลดเคอร์เนลกลายเป็นหนึ่งในงานที่ช้าที่สุด
    • การโหลด kernel8.img ขนาด 9,276,375 ไบต์ ใช้เวลาประมาณ 1.54 วินาที
    • คิดเป็นอัตราส่งข้อมูลราว 6MiB/s
  • การโหลดเคอร์เนลทำโดย GPU ซึ่งใช้โปรเซสเซอร์ภายในแบบ proprietary คือ VideoCore IV
    • โค้ดโหลดอาจไม่มีประสิทธิภาพหรือใช้ค่าคอนฟิกแบบอนุรักษ์นิยม แต่เพราะเป็น black box จึงไม่สามารถไปปรับรีจิสเตอร์หรือพารามิเตอร์ได้อย่างมีประโยชน์
  • ในทางทฤษฎี การโอเวอร์คล็อกคอร์ GPU ทำได้ และช่วยลดเวลาโหลดเคอร์เนลได้ 20%
    • แต่ไม่แนะนำ เพราะไม่ทราบผลข้างเคียงด้านความน่าเชื่อถือ
  • จากนั้นจึงย้ายระบบจาก Raspbian/Debian ไปเป็นดิสโทรปรับแต่งเองบนฐาน Buildroot 2024.02.1
    • ใช้ native aarch64 toolchain
    • ยังคงใช้ glibc และเครื่องมือ userland ของ Raspberry Pi
  • ในเคอร์เนลปรับแต่งเอง มีการตัดหรือลดสิ่งต่อไปนี้
    • รองรับเสียง
    • ไดรเวอร์ block device และไฟล์ซิสเต็มส่วนใหญ่ โดยคงไว้แค่ SD/MMC และ ext4
    • RAID, USB, HID, DVB
    • รองรับวิดีโอและ framebuffer
    • ฟีเจอร์เครือข่ายขั้นสูง เช่น tunneling, bridging, firewall
    • การบีบอัดเคอร์เนลแบบ Gzip และการบีบอัดโมดูล
  • แนวทางไม่บีบอัดทั้งเคอร์เนลและโมดูล แม้ GPU จะใช้เวลาโหลดนานขึ้น แต่เมื่อมองด้านพลังงานรวมกลับคุ้มกว่า
    • การคลายบีบอัด Gzip ใช้พลังงานมาก และแทบจะเท่ากับมีขั้นตอนย้ายตำแหน่งเพิ่มอีกชั้นหนึ่ง
  • ยังมีการปิด KASLR ด้วย
    • KASLR สุ่มตำแหน่งโหลดเคอร์เนลในหน่วยความจำเพื่อทำให้การเขียน exploit ยากขึ้น แต่ทำให้หลัง GPU โหลดแล้วต้องมีขั้นตอนย้ายตำแหน่งเคอร์เนล
    • สำหรับกรณีใช้งานนี้ พื้นที่โจมตีผ่านเครือข่ายมีจำกัดมาก และซอฟต์แวร์แอปพลิเคชันทั้งหมดรันเป็น root
    • รวมถึงมีการปิด mitigations สำหรับช่องโหว่ speculative execution อย่าง Spectre ด้วย
  • เคอร์เนลที่ได้มีขนาด 8.5MiB แบบไม่บีบอัด และถ้าบีบอัด Gzip จะเหลือ 4.1MiB
    • เทียบกับเคอร์เนล Raspbian เดิมที่มีขนาด 25MiB แบบไม่บีบอัด และ 8.9MiB แบบ Gzip

ผลลัพธ์สุดท้ายและการปรับแรงดันไฟเข้า

  • สุดท้ายสามารถไปถึงโปรแกรม Linux user space ได้ในเวลา ต่ำกว่า 3.5 วินาที
  • เวลาที่ใช้ภายใน Linux kernel เองมีประมาณ 400ms
  • การใช้พลังงานรวมคือ 0.364As * 5.0V = 1.82Ws
    • เมื่อเทียบกับการเข้าถึง user space บน Debian เดิมที่ใช้ 9.5Ws ก็เหลือประมาณหนึ่งในห้า
  • หลังเผยแพร่บทความ Graham Sutherland / Polynomial ได้ชี้ว่า regulator ของ Pi Zero ไม่มีประสิทธิภาพนักเมื่อใช้ไฟเข้า 5.0V
  • ในสถานการณ์ทดสอบและตัวผลิตภัณฑ์จริง สามารถลดแรงดันไฟเข้าลงได้ถึง 4.0V
    • 5.0V: 350.94mAs * 5.0V = 1.754Ws
    • 4.0V: 390.77mAs * 4.0V = 1.563Ws
    • 3.6V: 399.60mAs * 3.6V = 1.438Ws
  • เมื่อลดแรงดันลง ค่า mC หรือ mAs จะเพิ่มขึ้นเพราะกระแสสูงขึ้น แต่พลังงานรวมลดลงอย่างชัดเจน
  • การทำงานที่ 3.6V ช่วยลดพลังงานได้เพิ่มอีกราว 20% เพราะสวิตชิงเรกูเลเตอร์ทำงานใกล้จุดที่เหมาะสมกว่า แต่ในทางเทคนิคยังอยู่นอกสเปก จึงต้องตรวจสอบเสถียรภาพและความน่าเชื่อถือเพิ่มเติม

การตั้งค่าและโค้ดที่เผยแพร่

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

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

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

  • การจัดการพลังงานของตระกูล Raspberry Pi เป็นหนึ่งในจุดอ่อนอย่างชัดเจน ดังนั้นจึงตั้งตารอ Pico 2 รุ่นใหม่ เพราะดูเหมือนว่าจะเข้าสู่สถานะประหยัดพลังงานที่ค่อนข้างลึกได้ง่ายขึ้น แม้ไม่มีฮาร์ดแวร์ภายนอก
    ผมเคยทำกล้องสำหรับงานคล้าย ๆ กันด้วย Google Coral mini ซึ่งกล้องไม่ได้ดีเท่า HQ cam แต่มี RTC ในตัวที่รองรับการสแตนด์บาย/ปลุกได้ง่ายมาก จึงเหมาะพอดีสำหรับแอปที่ถ่ายภาพเป็นระยะ ๆ และยังมีประสิทธิภาพกับหน่วยความจำ 2GB พอสำหรับประมวลผลภาพความละเอียดสูง
    แม้จะเชื่อมต่อ HQ camera ทางกายภาพได้ แต่เท่าที่รู้ ไม่มีซอฟต์แวร์ไพป์ไลน์บน Coral สำหรับจัดการมัน
    ระบบนิเวศของ Raspberry Pi เติบโตเต็มที่กว่ามาก และผมเชื่อถือความพร้อมในการจัดหาของ Raspberry Pi ในอนาคตมากกว่าความเป็นไปได้ที่ Google จะยังคงจัดหาไลน์ Coral ต่อไป ถึงอย่างนั้นก็รู้สึกได้ชัดว่าการรองรับพลังงานที่ดีในฮาร์ดแวร์มีประโยชน์แค่ไหน
    น่าขันที่กล้องเวอร์ชันถัดมาผู้รับเหมาภายนอกทำด้วย Raspberry Pi และชดเชยปัญหาพลังงานด้วยการใส่แบตเตอรี่ที่ใหญ่ขึ้นมาก ผลคือมี Coral dev mini กับกล้อง 100 ตัวที่ยังไม่ได้แกะกล่องกองอยู่ ทำให้ต้องหาไอเดียดี ๆ หรือไม่ก็ต้องเอาไปขาย

    • ไลน์ Coral ดูเหมือนจะตายไปแล้วหรือเลิกผลิตไปแล้ว เว็บไซต์ coral.ai ก็ดูไม่มีอัปเดตหลังปี 2021 และข้อความลิขสิทธิ์ยังเป็นปี 2020
      ตอนค้นหา "google coral twitter" เพื่อหา Twitter ทางการ ผลลัพธ์ที่สองกลับเป็นทวีตของคุณที่พยายามขายบอร์ดที่เหลือ 100 ตัว น่าตกใจจริง ๆ
    • น่าสนใจ เพราะผมใช้ Pi กับไฟบ้านมาตลอด สงสัยว่าฮาร์ดแวร์ Pi ทำ การปรับแต่งการใช้พลังงาน แบบ Coral ไม่ได้ หรือว่าเป็นเพราะการรองรับซอฟต์แวร์จัดการพลังงานของ Pi ยังไม่พอ
      จากที่บอกว่าใช้ฮาร์ดแวร์ภายนอกมาจัดการพลังงาน ดูเหมือนจะไม่ใช่แค่ปัญหาซอฟต์แวร์ง่าย ๆ
    • สงสัยว่าได้ลองดูฮาร์ดแวร์ BeagleBone ที่มี อุปกรณ์ PRU สำหรับการทำงานพลังงานต่ำหรือยัง PRU สามารถตื่นอยู่ได้แม้ระบบจะหลับอยู่
    • สงสัยว่ากำลังทำงานอะไรที่กล้องสำเร็จรูปในปัจจุบันทำไม่ได้

  • ถ้ารวมแอปพลิเคชันเป็น initramfs ที่ลิงก์เข้ากับเคอร์เนล ในกรณีง่าย ๆ จะไม่ต้องเมานต์ไฟล์ซิสเต็ม จึงลดลงได้ค่อนข้างมาก
    บางกรณีสามารถแทนที่ของอย่าง BusyBox init ด้วยสคริปต์ bash ง่าย ๆ ที่ทำแค่การบูตขั้นต่ำได้ด้วย เช่น เมานต์ devtmpfs, proc, sysfs เป็นต้น และถ้าเป็นไปได้ก็ควรพิจารณาทิ้ง glibc
    ก่อนผูก initramfs เข้ากับเคอร์เนล ควรทดสอบด้วย chroot ว่ามี dependency ของแอปพลิเคชันที่จำเป็นครบหรือไม่ ถ้ารันใน chroot ได้ เคอร์เนลก็รันระหว่างบูตได้ และรอบการพัฒนาจะเร็วขึ้นมาก
    ถ้าปิดโมดูลเคอร์เนลแล้วลิงก์เฉพาะฟังก์ชันที่ต้องใช้เข้าไปในเคอร์เนล ก็ลดทั้งพื้นที่และเวลาบูตได้อีก ควรลองทดสอบ การบีบอัด zstd แทน gzip ด้วย

    • ในทางกลับกัน หากการโหลดเคอร์เนลและ initramfs ช้า การบูตด้วยอิมเมจที่เล็กที่สุดเท่าที่ใช้ได้จริง แล้วค่อยโหลดซอฟต์แวร์ที่เหลือหลัง user space เริ่มทำงาน อาจเร็วกว่า
      กรณีนี้เกิดเมื่อขั้นตอนบูตก่อนหน้าใช้ประสิทธิภาพฮาร์ดแวร์ได้ไม่เต็มที่ หรืออิมเมจมีขนาดใหญ่จนทำงานอื่นไปพร้อมกับการโหลดจะดีกว่า
    • ไม่จำเป็นต้องใช้เชลล์สคริปต์เพื่อเมานต์ pseudo-filesystem หลายตัวเสมอไป ทำได้โดยตรงในแอปพลิเคชัน
      แบบนั้นสิ่งที่เหลือก็มีแค่ initramfs ที่มีไบนารีลิงก์แบบสแตติกตัวเดียว

  • มีบทความดี ๆ อีกสองบทความเกี่ยวกับการลดเวลาบูตของ Pi
    https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...
    http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
    ผมอ้างอิงสองบทความนี้ทำกรอบรูปดิจิทัลด้วย Pi และทำให้บูตเร็วมากจนถึง เบราว์เซอร์โหมดคีออสก์ ถ้าความต้องการมีน้อยมาก ก็ได้เวลาบูตที่น่าประทับใจทีเดียว

    • อ่านบทความแรกแล้วดูเหมือนบทความต้นทางก็น่าจะได้ประโยชน์จากการใช้ start_cd.elf เป็นบูตโหลดเดอร์ขั้นที่ 3 ที่ตัดระบบย่อยกราฟิกออก และบอกว่าปรับปรุงเวลาโหลดได้ 0.5 วินาที
    • ขอบคุณสำหรับลิงก์ครับ โค้ดของ กรอบรูปโหมดคีออสก์ นั้นเปิดเผยต่อสาธารณะไหมครับ?

  • โศกนาฏกรรมจริง ๆ คือ โค้ด GPU bootcode.bin เป็นกล่องดำแบบ proprietary และไม่มีซอร์สโค้ด
    แย่มากที่โปรเจกต์แฮ็กและงานอดิเรกต้องมีกล่องดำลับซ่อนอยู่ที่แก้ไขไม่ได้

    • เฟิร์มแวร์ของ Pi คือ ThreadX ซึ่งภายหลัง Microsoft ซื้อไปและเปลี่ยนชื่อเป็น Azure RTOS
      ตอนนี้เป็นซอฟต์แวร์เสรีโอเพนซอร์สแล้ว
      https://www.theregister.com/2023/11/28/microsoft_opens_sourc...
      แต่นั่นไม่ได้ทำให้เฟิร์มแวร์ Pi ทั้งหมดกลายเป็นเสรีโอเพนซอร์สโดยอัตโนมัติ เพราะมันไม่ใช่ไดรเวอร์ แต่ถ้าต้องการก็สามารถทำได้
    • ถ้าเปิดซอร์ส bootcode แล้วจะทำให้ดัดแปลงได้สุดโต่งเกินไปจน RPI รับประกันการทำงานปกติไม่ได้หรือเปล่า หรืออาจเกี่ยวกับการโหลดไดรเวอร์ proprietary ก็ได้
      สงสัยว่าข้างในมีอะไรถึงต้องปิดไว้

  • ผมชอบบทความโดยรวม แต่ยังไม่ค่อยมั่นใจกับส่วนนี้
    คือส่วนที่บอกว่าการปิด CPU turbo เพื่อประหยัดการใช้กระแสไฟเล็กน้อยเป็นทางเลือกที่ไม่ดี และเพราะเวลาที่ช้าลงจึงใช้พลังงานมากกว่าการรีบทำให้เสร็จแล้วปิด
    ในวิชาวิทยาการคอมพิวเตอร์ ผมเคยเรียนว่า การใช้พลังงานไฟฟ้าแปรผันตามกำลังสองของความถี่สัญญาณนาฬิกา กล่าวคือถ้าเพิ่ม clock เป็นสองเท่า กำลังไฟจะเพิ่มเป็นสี่เท่า
    ถ้าอย่างนั้น หากจะตรวจสอบว่าการเพิ่มขึ้นแบบกำลังสองจากการเพิ่ม clock มากกว่าผลคูณของการใช้พลังงานคงที่ที่เกิดจากเวลาทำงานที่ยาวขึ้นหรือไม่ ก็น่าจะต้องวัดความต่างของกำลังไฟจริง
    ในเรื่องนี้ ถ้า Pi CPU ให้ ข้อมูลการใช้พลังงานไฟฟ้า แบบละเอียดที่อนุมานได้จาก datasheet หรือเปิดเผยแบบเรียลไทม์ผ่าน register ได้ก็คงดี

    • คำอธิบายนั้นไม่ได้ถูกต้องทั้งหมด กำลังไฟสำหรับการสวิตช์ของชิป ถ้าไม่นับการรั่วไหลแบบสถิต จะแปรผันตาม กำลังสองของแรงดันไฟฟ้าคูณด้วยความถี่
      ชิปส่วนใหญ่ต้องใช้แรงดันที่สูงขึ้นเพื่อให้ไปถึงความเร็ว clock ที่สูงขึ้น จึงเกิดความสัมพันธ์แบบกำลังสองตรงนั้น
      แต่เท่าที่ผมรู้ Raspberry Pi ไม่มีการควบคุมแรงดันแบบไดนามิก ดังนั้นถ้าลดแค่ clock โดยไม่ลดแรงดัน ก็น่าจะไม่มีผลต่อการใช้พลังงานจากการสวิตช์โดยรวม
    • นี่เป็นกลยุทธ์ปรับประสิทธิภาพด้านพลังงานที่รู้จักกันดีในชื่อ race to idle ได้ผลเพราะนอกจาก CPU แล้วยังมีอุปกรณ์รอบข้างอีกมากที่ใช้พลังงาน และไม่สามารถปิดได้จนกว่างานของ CPU จะเสร็จ
      แน่นอนว่ามีจุดเหมาะสมอยู่ด้วย ถ้า overclock CPU มากเกินไป ประสิทธิภาพต่อวัตต์จะแย่ลงมากจน race to idle ใช้ไม่ได้อีกต่อไป
    • ถ้าเป็น workload ที่ทำต่อเนื่อง นี่เป็นกฎคร่าว ๆ ที่ใช้ได้ แต่ไม่ใช่เรื่องทั้งหมด แค่ component เปิดอยู่ก็มี การใช้พลังงานแบบสถิต ในระดับคงที่อยู่เสมอ
      ดังนั้นระบบ embedded สมัยใหม่จึงมักใช้กลยุทธ์ "race-to-sleep" หรือ "race-to-halt" โดยรันงานให้เร็วมาก แล้วปิด component ส่วนใหญ่ไว้จนกว่า event ถัดไปจะมาถึง
    • มี overhead ด้านพลังงาน พื้นฐานที่อุปกรณ์ใช้แม้ไม่ได้ทำอะไรเลย ใน benchmark ก็ระบุว่าเมื่อเปิด turbo การใช้กระแสเพิ่มขึ้น 10% แต่เวลาบูตลดลง 11% ทำให้การใช้พลังงานรวมต่างกันเล็กน้อยแต่ยังวัดได้
    • น่าสนใจมาก ขอบคุณที่แชร์
      ถ้าการคำนวณอย่างหนึ่งใช้เวลา 1 วินาทีและใช้ 1J เช่น 1W ที่ 1GHz ในโมเดลวัวทรงกลมแบบสมบูรณ์ ก็คงหมายความว่าถ้าจะทำการคำนวณเดียวกันให้เสร็จใน 0.5 วินาที ต้องใช้ 2J เพราะที่ 2GHz จะเป็น 4W
      แต่ตรงนั้นดูเฉพาะการใช้ของ CPU และถ้าทั้งระบบมีการใช้คงที่ 4W ที่ 1GHz ก็จะเป็น CPU 1J กับระบบ 4J รวม 5J ส่วนที่ 2GHz จะเป็น CPU 2J กับระบบ 2J รวม 4J
      ถ้าผมเข้าใจถูก หมายความว่าถ้าการใช้พลังงานรวมของทั้งระบบพอ ๆ กับการใช้พลังงานของ CPU ตอน turbo ก็ควรใช้ turbo ไม่อย่างนั้นก็ไม่ควร ใช่ไหม?

  • น่าประทับใจ แต่ทุกครั้งที่อ่านบทความแบบนี้ ผมจะนึกถึงตอนที่เคยอัดวิดีโอ การบูต Plan 9 บน Pi Zero: https://taoofmac.com/space/blog/2020/09/02/1900#resurrecting
    GIF เป็น output แบบเรียลไทม์

    • ตัวมันเองก็ดูเจ๋ง
      แต่จะโหลด ไดรเวอร์กล้องและ Wi-Fi ที่จำเป็นสำหรับโปรเจกต์ในบทความต้นฉบับได้หรือไม่ก็เป็นอีกเรื่องหนึ่ง

  • โดยส่วนตัวแล้ว เวลาบูตของ Linux distribution โดยรวมค่อนข้างน่าผิดหวัง และบนฮาร์ดแวร์ที่อ่อนแบบนี้ ปัญหานั้นยิ่งหนักขึ้นมาก
    ผมเคยทำ optimization คล้าย ๆ กันบน MQ-Pro SBC ด้วย บนแล็ปท็อปก็รู้สึกได้ค่อนข้างมากเหมือนกัน MacBook อาจเป็นข้อยกเว้น แต่ยังไงก็เป็นเรื่องน่ารำคาญอยู่ดี

    • ขึ้นอยู่กับมากว่าเรานิยาม เวลาบูต ว่าอะไร เช่น Windows ปรับให้เวลาที่ UI แรกปรากฏเร็ว แต่หลังจากนั้นส่วนที่เหลือยังโหลดต่อ และ PC ก็แทบใช้งานจริงไม่ได้อีกหลายวินาที
    • M1 MacBook ใช้เวลาเริ่มระบบนานกว่า desktop PC ที่รัน Windows ของผมอยู่หลายเท่าในระดับเลขหลักเดียว
      เมื่อเปิดเครื่องแล้ว แค่ login ใหม่ก็เร็วมาก แต่ reboot ใช้เวลาค่อนข้างนาน
    • Linux ก็สามารถบูตได้ค่อนข้างเร็วถ้าตั้งค่าให้ดี ผมเคยเขียนเกี่ยวกับเรื่องนี้ไว้ที่ [0]
      แต่ distribution สร้าง kernel และ initramfs ที่เป็นแบบทั่วไปมากด้วยเหตุผลที่สมเหตุสมผล และชุดนี้ก็ไม่ได้บูตเร็วเป็นพิเศษ
      [0]: https://blog.davidv.dev/posts/minimizing-linux-boot-times/
    • ผมไม่ค่อยแน่ใจว่า distribution จะทำอะไรได้มากแค่ไหนตรงนี้ เวลาบูตฝั่ง user space มักแทบไม่สำคัญ
      เว้นแต่จะมีการตั้งค่าผิดพลาดร้ายแรง เช่น NetworkManager รอ Wi-Fi ที่ไม่มีอยู่ 90 วินาที เครื่อง Linux ของผมใช้เวลาประมาณ 4 วินาทีถึง graphical.target และส่วนใหญ่เป็นเพราะการเชื่อมต่อ Wi-Fi กับ ntpd ซึ่งทั้งคู่โดยหลักแล้วเป็นสิ่งที่เลือกได้
      ถ้าอยากบูตให้เร็วจริง ๆ ก็ทิ้ง ความสามารถในการตั้งค่าแบบไดนามิก อย่างชั้น compatibility ของ bootloader, abstraction และ initramfs ไปได้เลย แต่ถ้าทำแบบนั้นก็จะขึ้นอยู่กับผู้ผลิตฮาร์ดแวร์ จึงไม่คุ้มเท่าไร
    • คำพูดนี้ทำให้ผมแปลกใจนิดหน่อย สำหรับผม Linux บูตเร็วมากแม้บนเครื่องเก่าและ storage ช้า
      ตัวอย่างเช่น MacBook Air 11 ที่ติดตั้ง Linux ขึ้นหน้าจอ login เร็วจนแทบดู boot log ไม่ทัน ตาม systemd-analyze ใช้เวลาน้อยกว่า 4 วินาทีถึง graphical target
      ประเด็นสำคัญดูเหมือนมีสองอย่าง คือไม่ใช้ desktop environment และบูตเข้า text mode แล้วค่อย startx เมื่อจำเป็น หรือบูตเข้า X ด้วย login manager เบา ๆ (lightdm) ถ้าไม่มี desktop environment จำนวน service จะลดลงหลายเท่าในระดับเลขหลักเดียว ทำให้แรงกดดัน I/O ระหว่างบูตบนฮาร์ดแวร์เก่าลดลงมาก แม้รัน X ระบบที่บูตแล้วก็ใช้ไม่ถึง 200MB
      อีกอย่างหนึ่งคือ EFI stub ช่วยเพิ่มความเร็วได้: https://wiki.archlinux.org/title/EFISTUB

  • ความรู้สึกแรกคือ น่าจะใช้คอร์อื่นไม่ได้เหรอ? การถ่ายรูปแล้วส่งขึ้นคลาวด์จำเป็นต้องใช้ Linux จริง ๆ หรือ?
    ผมไม่ใช่สายฮาร์ดแวร์ เลยสงสัยว่าจะทำงานนี้ให้เสร็จได้อย่างไรด้วยงบขั้นต่ำ เป็นบทความที่น่าสนใจ

    • ผมก็คิดแบบเดียวกันตั้งแต่แรก
      อาจเป็นเพราะตอนนี้มี ESP32-CAM สองตัววางอยู่บนโต๊ะกินข้าวพอดี แต่ก็สงสัยว่าการจัดชุด ESP32-CAM จะเทียบกันได้อย่างไร น่าจะใช้ได้ดีแค่กับภาพระดับ 2 เมกะพิกเซลเท่านั้น แต่เวลาเริ่มต้นกับการใช้พลังงานทั้งคู่น่าจะต่ำกว่ากันเกือบหนึ่งหลัก
      ถ้าสงสัย รายละเอียดอยู่ที่นี่: https://components101.com/modules/esp32-cam-camera-module
    • ปัญหาคือโปรเจกต์นี้ใช้กล้องกับเครือข่ายไร้สาย ซึ่งทั้งคู่ต้องใช้ ไดรเวอร์ ที่ค่อนข้างซับซ้อน
      โดยหลักการแล้วทำแบบ bare metal ก็ได้ แต่การทำให้อุปกรณ์ต่อพ่วงที่จำเป็นทำงานได้นั้นไม่ง่าย

  • ผมสงสัยว่าทำไมเคอร์เนลแบบคัสตอมถึงมาใช้ช้าขนาดนี้ ถ้าจะปรับให้เหมาะสม ปกติไม่เริ่มจาก LFS หรือดิสโทรแบบอิงซอร์สกันหรือ? ดูเหมือนอุปกรณ์แบบนี้ก็ไม่ได้จำเป็นต้องมีการอัปเดตซอฟต์แวร์แบบอัตโนมัติเสมอไป
    อีกอย่างก็สงสัยว่าในอุปกรณ์แบบนี้จะปรับ EFI/BIOS ให้เหมาะสมได้ไหม อย่างน้อยบนเดสก์ท็อป Arch Linux ทั่วไปของผม มันกินเวลาบูตไปส่วนไม่น้อยเลย
    $ systemd-analyze
    Startup finished in 10.076s (firmware) + 1.339s (loader) + 1.569s (kernel) + 2.974s (initrd) + 3.894s (userspace) = 19.854s

    • Buildroot ที่พวกเขาใช้ก็คือเครื่องมือสำหรับจุดประสงค์แบบนี้พอดี ใน Buildroot คุณตั้งค่า "ดิสโทร" ของตัวเอง แล้วสร้างอิมเมจบูตเดี่ยวจากตรงนั้น
      ผมไม่รู้ฮาร์ดแวร์ Raspberry Pi แบบละเอียด แต่ SoC แบบฝังตัวจำนวนมากมี bootloader ที่ค่อนข้างมินิมัลซึ่งทำงานด้วย u-boot และโดยปกติเร็วมาก โดยเฉพาะถ้าตั้งค่าหน่วงเวลาที่รออินพุตจากผู้ใช้เป็น 0
    • ในสภาพแวดล้อมจริง คุณคงไม่อยากใช้ LFS ตามคู่มือของโปรเจกต์ LFS หรอก เพราะต้องคอมไพล์ GNU เยอะเกินไป
      ระบบที่มีเคอร์เนลขั้นต่ำกับ busybox เจ็บตัวน้อยกว่ามาก และ Gentoo ก็ไม่ใช่ตัวเลือกที่แย่
    • ต้องขอบคุณเรื่องนี้ ทำให้ผมรู้ว่าควรปรับ bootloader (systemd-boot) ของตัวเอง และเฟิร์มแวร์ของผมดีกว่าที่คิดอย่างน่าประหลาดใจ
      > systemd-analyze
      Startup finished in 3.259s (firmware) + 35.127s (loader) + 1.823s (kernel) + 2.927s (userspace) = 43.138s

  • 3.5 วินาทีนั้นเจ๋ง แต่ถ้าสถานการณ์ทั้งหมดคือการเชื่อมต่อ Wi-Fi ทุก ๆ ไม่กี่นาทีเพื่ออัปโหลดภาพ ESP32 น่าจะเป็นตัวเลือกที่ดีกว่ามากในแง่การใช้พลังงาน
    เว้นแต่ว่าจะจำเป็นต้องใช้ฟีเจอร์เฉพาะบางอย่างของโมดูลกล้องสำหรับ Pi ที่กล้องที่เข้ากันได้กับ ESP32-CAM ไม่มี

    • ESP32 รองรับได้แค่ PSRAM 4MB แต่ภาพนิ่งเดี่ยวจาก RPi HQ Camera ก็ 18MB แล้ว
    • ผมอาจแนะนำไมโครคอนโทรลเลอร์ที่สูงขึ้นมาอีกหน่อยซึ่งมีอินเทอร์เฟซ MIPI CSI ได้ แต่นอกเหนือจากนั้นก็เห็นด้วย
      ดูเหมือนกำลังทำงานมากเกินไปเพื่อทำสิ่งที่ไมโครคอนโทรลเลอร์แทบทำได้โดยไม่ต้องออกแรงเลย