Zawieszanie się Orange Pi Zero - nieregularne zamrożenia w trakcie pracy?

Sun Apr 08, 2018 3:26 pm   

On 08.04.2018 15:43, Marcin Debowski wrote:


Wyłącznie po kablu. Wi-fi jest wyłączone.
Gdybym nie potrzebował kabla, rozsądne byłoby użyć Rpi Zero i być może
problemu by nie było.

--
Mirek.

Sun Apr 08, 2018 11:54 pm   

On 2018-04-08, Mirek <mirek@null.dev> wrote:

To pewnie nie żre wtedy pradu tak bardzo w dość losowych momentach. Z
drugiej strony jak te zasilacze są 2A i są to nołnejmy to mimi wszystko
srpóbowałbym dac mocniejszy, z możliwie krótkim kablem i poobserwować.
To się da łatwo sprawdzić, a za dużo innych opcji nie masz.

--
Marcin

Mon Apr 09, 2018 8:53 am   

W dniu 2018-04-08 o 17:26, Mirek pisze:

lub więcej.

--
Pozdr
Janusz

Mon Apr 09, 2018 10:58 am   

On 2018-04-09, Adam Wysocki <gof@somewhere.invalid> wrote:

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.

--
Marcin

Mon Apr 09, 2018 12:49 pm   

Marek <fake@fakeemail.com> wrote:


Zainteresuj się pakietem cpuburn.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Mon Apr 09, 2018 12:51 pm   

Marek <fake@fakeemail.com> wrote:


Czy dotyczy to tylko Orange PI, czy także Raspberry?

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Mon Apr 09, 2018 12:54 pm   

Mirek <mirek@null.dev> wrote:


Spotkałem się na Raspberry PI 3. W wyniku dużego obciążenia (raczej
pamięci, niż CPU) potrafi się zawiesić w taki sposób, że kernel działa,
ale userland nie -- np. jak łączę się telnetem na port ssh, to przyjmuje
połączenie (kernel), ale już nie odpowiada welcome stringiem.

W logach (w tym wysyłanych zdalnie po UDP na inny serwer) też nic nie ma.

Nie doszedłem jeszcze, co to powoduje. Zasilanie jest mało prawdopodobne,
bo zasilacz ma duży zapas, ale może dla spokoju obejrzę to zasilanie pod
oscyloskopem (może na kondensatorach zaoszczędzili, może przewody za
długie)...

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Mon Apr 09, 2018 2:02 pm   

On Mon, 9 Apr 2018 10:49:37 +0000 (UTC), gof@somewhere.invalid (Adam
Wysocki) wrote:

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

--
Marek

Mon Apr 09, 2018 2:06 pm   

Mon Apr 09, 2018 2:08 pm   

On Mon, 9 Apr 2018 10:51:02 +0000 (UTC), gof@somewhere.invalid (Adam
Wysocki) wrote:

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...

--
Marek

Mon Apr 09, 2018 3:02 pm   

Marcin Debowski <agatek@invalid.zoho.com> wrote:


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...

https://packages.debian.org/search?keywords=cpuburn

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Mon Apr 09, 2018 7:44 pm   

Thu Apr 12, 2018 1:29 pm   

Użytkownik "Adam Wysocki" napisał w wiadomości grup
dyskusyjnych:panljj$ath$1$gof@news.chmurka.net...
Marek <fake@fakeemail.com> wrote:

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.

Thu Apr 12, 2018 3:05 pm   

Marek <fake@fakeemail.com> wrote:


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ść?

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Thu Apr 12, 2018 3:08 pm   

Marek <fake@fakeemail.com> wrote:


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

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]