orange pi zero zawieszanie sie

Po prawdzie nie ma sensu nawet ww. gzipem. Sprawdź jak dociąża zwykle dd if=/dev/zero of=/dev/null. Jedna instancja na jeden rdzeń i 100% zajęte.

cpuburn wykorzystuje możliwie najwięcej elementów procesora jednocześnie. dd wykorzysta jedynie fragment.

Z drugiej strony nie wiem, czy jest cpuburn na ARM. apt-cache na raspbianie mi nie znajduje, ale tu piszą, że w wheezy i jessie był na arma...

A co to może zrobić więcej z CPU niż gzip?

Bo dd to tylko utylizacja Io z większym naciskiem na dna niż sam cpu, to że pokazuje 100% CPU nie oznacza, że faktycznie CPU/ALU jest ”przyciśnięte”.

Ta informacja dot. tylko opi, na forum opi jest cały wątek o tym i ostrzeżenie a nawet petycja do producenta, żeby zaprzestał dystrybuować nieprawidłowo skonfigurowanego softu (sic!)na oficjalnej stronie...

Robiłem testy porównawcze dd z i bez gzipa oraz stress/stress-ng i różnice temperaturowe cpu są praktycznie żadne. Wynika to zapewne z tego, że coś (różne w zalezności od metody) się w końcu gdzies i tak zapycha i pełnej utylizacji zasobów cpu i tak nie będzie.

Pytanie, czy dd z pustego (/dev/zero) w próżne (/dev/null) używa w ogóle sprzętowo I/O. IMO powinno się to dziać tylko w obrębie procesora, bo gdzie (do którego fizycznego urządzenia) to I/O miałoby iść?

Rozkaz rozkazowi nierówny. CPU ma wiele modułów, które są używane przy określonych operacjach.

Ok, czyli mój problem to pewnie coś innego :)

Dokladnie - czysty procesor i troche RAM.

Tyle ze dosc ograniczony program, a wiec i zestaw instrukcji, adresow itp. gzip lepszy, ale nie nie z dev/zero :-)

J.

I to chodzi, by obciążyc procesor.

Kompresja samych zer też używa rejestry i alu.

No właśnie. Pytanie, jak różni się obciążenie procesora względem np. gzipa, a to -- względem dedykowanego cpuburn.

Walka trwa. Od soboty uruchomiłem trzecią płytkę z wcześniejszego zakupu. Do dziś chodzi bez zarzutu. Teraz pytanie: czy można bezkarnie przekładać kartę z systemem z płytki na płytkę? Zakładam, że są sprzętowo identyczne. I żeby nie było że zadaję głupie pytania: przekładałem i działa, ale zastanawiam się czy nie wpłynie to negatywnie na wiarygodność testów.

Można, chyba że (np.) gdzies na twardo jest zdefiniowana zalezność czegoś od MAC kontrolera sieci i to coś sie inaczej zachowuje z innym MACiem, ale byłby to tak rzadki przypadek, że można śmiało olac.

Test dał wynik pozytywny czyli zawiesiła się. Miałem ustawiony heartbeat na czerwonej diodce - dziś po południu patrzę

- świeci światłem ciągłym, z płytką nie ma kontaktu. Na razie pomysły mi się kończą i do tego nie mam czasu na jakieś bardziej interaktywne testy.

Używam intensywnie od ponad roku i na początku zwisy miałem w dwóch przypadkach: przy pomyłce w FEX (jak zaczynałem to nie było jeszcze oficjalnej obsługi Orange Pi Zero i przerabiałem z Orange Pi One), jak się ciepło zrobiło.

Po doprowadzeniu powyższego do ładu uptime miałem ponad 300 dni. A teraz byłoby blisko 400 gdybym nie musiał zrobić restartu przy okazji modyfikacji zasilania/podmiany jądra.

Sprzęt zajmuje się głównie przerzucaniem pakietów po sieci i USB-owym RS-485.

W tej chwili support dla Orange Pi Zero już jest tak więc o ile używasz kernela 3.4 to sugeruję upewnić się, że masz dobrze podlinkowany /boot/script.bin.

Natomiast jeśli chodzi o termikę to profilaktycznie proponuję podkleić choćby najmniejszy radiator na chipa.

Przy czym nie należy się bać temperatur na poziomie 40-50 stopni.

U mnie aktualnie wygląda to tak:

/ _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/ |___/

Welcome to ARMBIAN 5.38 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i System load: 0.18 0.21 0.22 Up time: 88 days Memory usage: 13 % of 494MB IP: *.*.*.* CPU temp: 44°C Usage of /: 13% of 14G

Piotrek

Aaa! Te 300+ dni działało na jakimś badziewiastym zasilaczu przez USB. Natomiast ostatnie 88 dni działa na rownie badziewiastej przetwornicy z

W obu przypadkach zero problemów.

P.

U mnie niestety coś tam banglam GPIO. Bardzo możliwe, że większość zwisów ma związek z jakąś niepoprawną obsługą GPIO, ale miałem też przypadki zamrożenia się płytki, z którą kompletnie nic nie robiłem (być może samo zainicjowanie GPIO czy eksporty robią problem), ale fakt - płytka, na której nic nie kombinuję z GPIO działa zwykle najdłużej. Aktualnie przeniosłem projekt na Raspbery Pi Zero W i od kilku dni intensywnie testuję - na razie żadnych zwisów. Docelowo muszę mieć połączenie po ethernecie - nie wiem jeszcze w którą stronę pójść.