Raspbery PI a raczej już BeagleBone Black :)

kamar · Post napisał: **kamar** » 13 cze 2014, 14:33

jacek-1210 pisze:J ale ostatnio władowałem mu program na ponad 70tys. linii i ?:

Ja takowych nie posiadam, jak podeślesz to spróbuję uruchomić.

markcomp77 · Post napisał: **markcomp77** » 13 cze 2014, 15:02

zrobiłem test... obserwowałem wykresy obciążenia procesora i zajęcia pamięci...

podczas próby ładowania 1000 obiegów w pętli przykładu arcspiral... procesor prawie momentalnie się nasyca, natomiast zajętość pamięci systematycznie narasta, aż do przerwania ładowania i wyrzuceniu błędu linuxcnc - przy zajęciu całej wolnej pamięci

kamar pisze:Ja takowych nie posiadam, jak podeślesz to spróbuję uruchomić.

można zastosować ten plik arcspiral do zamulenia lub zablokowania BBB, po dopisania zapętlenia....

kamar · Post napisał: **kamar** » 13 cze 2014, 20:13

Nie sztuka zamulić zapętleniem

Dostałem plik od kol. Jacka i rzeczywiście na starym Dellu muli makabrycznie po wczytaniu.

Obrazek

Dzięki koledze będzie na czym testować BBB, ale za kilka dni, jak odrobię zaległości na porębie.

markcomp77 · Post napisał: **markcomp77** » 13 cze 2014, 22:04

mi udało się zamulić pętlą na spirali i7/8GB ram+ 10GB swapa
obciążenie procka było prawie nie widoczne, jednak przy dużym przeciążeniu pamięci system prawie przestawał reagować nawet na mysz...

Szybkość procka nie jest krytyczna, istotna jest ilość pamięci w systemie przy dużych plikach... (najlepiej aby SWAP nie był potrzeby)

ciekawe na ile starczy 512MB RAMu z BBB?

micges · Post napisał: **micges** » 13 cze 2014, 22:11

Generalnie problemem jest pamięciożerność podglądu opengl. Jest one wiielopoziomowy i przekombinowany. Chłopaki z MachineKit mają parę propozycji jak usunąć ten problem, na pewno tego nie zostawią.

syntetyczny · Post napisał: **syntetyczny** » 13 cze 2014, 22:31

w BBB jest 1gb ramu jeżeli dobrze pamiętam. Tych problemów nie mają atomy, tam wrzucić można 4gb ramu i pętle niegroźne. Ja używałem D2500 albo coś w ten deseń, ale w tej cenie, można dwa BBB. Wszystko zależy od zastosowania...

markcomp77 · Post napisał: **markcomp77** » 13 cze 2014, 22:49

syntetyczny pisze:tam wrzucić można 4gb ramu i pętle niegroźne.

zamuliłem i7 z 8GB ramu... i cały system również, wypełniając z 5..6GB swapu (a to znacznie zwalnia sytem)

[ Dodano: 2014-06-13, 22:53 ]

syntetyczny pisze:w BBB jest 1gb ramu

ja patrzyłem na rewizje B i C
tam ramu jest 512MB
różnią się "2GB 8-bit eMMC on-board flash storage" lub 4GB w C

1GB ramu jest np. Cubieboard

syntetyczny · Post napisał: **syntetyczny** » 13 cze 2014, 23:16

No to pomyłka z tym ramem. Kwestia tego, na ile te zamulanie jest groźne na dłuższą metę...

markcomp77 · Post napisał: **markcomp77** » 13 cze 2014, 23:30

normalne linuxcnc z axis podczas ładowania gcodu generuje zajętość pamięci proporcjonalną do długości kodu (uwzględniając każdy obieg pętli)

sam interpreter mógłby relizować kontrole ruchu w locie...
jednak przy starcie axis usilnie próbuję zrobić obrazek

triera · Post napisał: **triera** » 14 cze 2014, 02:18

W testach u siebie (3Dcut+) - komputer Pentium II 400MHz 64MB RAM
ładuję plik ok. 65000linii gkodu (nie mam większego) - wyświetla się w czasie ok. 3s,
- ale i grafika jest cokolwiek mizerna...(na razie 2D).
Przy obróbce wielkość pliku dla wydajności
w zasadzie nie ma żadnego znaczenia
- nie rozpędzę tak plotera...

Szkoda, że nie można postawić na BeagleBone FreeDosa + LPT

Może jest coś podobnego z architekturą x86?

Raspbery PI a raczej już BeagleBone Black :)

Wałek prowadzący aluminiowy drążony drylin® R AWMR-20 fi 20 - 1500 mm

Dysk na rzepy 150 H21N/P806H

Raspbery PI a raczej już BeagleBone Black :)

Wałek prowadzący aluminiowy drążony drylin® R AWMR-20 fi 20 - 1500 mm

Dysk na rzepy 150 H21N/P806H

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej