LinuxCNC v uspace

Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

22. 8. 2017, 3:29

Provozujete prosím někdo LinuxCNC v uspace?
Tedy asi nikoli s RTAI, ale buď s RT-preempt nebo Xenomai?
A pokud ano, tak s jakými výsledky?
A je to na platformě PC nebo na nějaké jiné?

Díky za případné info.
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

24. 8. 2017, 7:43

Mex píše:Provozujete prosím někdo LinuxCNC v uspace?
Tedy asi nikoli s RTAI, ale buď s RT-preempt nebo Xenomai?
A pokud ano, tak s jakými výsledky?
A je to na platformě PC nebo na nějaké jiné?

Díky za případné info.
Ahoj Mexi,
ano používám, protože si hraju s ethernetovejma kartama od MESY a bez uspace to nerozběhneš.
Používám to na klasickým PC nebo miniPC a chodí to tak ak nejak "normálně".
uname -a mi hlasí: 3.2.0-4-rt-686-pae SMP PREEMPT RT Debian 3.2.88.-1
a testoval sem to kdysi i na xenomai nejakym
Z jakýho důvodu tě to zajímá?
Martin
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

24. 8. 2017, 9:29

Díky, žes napsal.
Zajímá mě, jak moc použitelné už to v uspace dneska je.
Jaké Ti to dává latence? Nezkoušel jsi prosím jen tak ze studijních důvodů na tom zprovoznit SW stepgeny nebo PWM-geny a podívat co, co v toho leze?
Jde o to, že RTAI a tedy kernelový režim funguje jen na platformě PC. Všude jinde (tedy v praxi dnes asi hlavně na ARMu) už to musí jen v uspace. Tak mě zajímá, co se od toho dá očekávat. To porovnání kernelového a uspace režimu na stejném HW může hodně napovědět.

Jinak mě celkem překvapuje, že Ethernetové karty Mesa musí jen v uspace. Podle mě pro to není žádný zásadní důvod. Vlasní driver síťovky je určitě kompatibilní s kernelovým real-time. A vyšší vrstvy (IP stack) by vůbec používat nemuseli, pro komunikaci s CNC interpolátorem to celkem k ničemu není.

Kdysi dávno (to ještě chodili po světě poslední dinosauři) jsem psal takovou real-time komunikaci ještě na UnixWare (tam jsem měl i vlastníma rukama napsaný driver síťovky) a pak i na Linuxu (tam už s běžným Linuxovým driverem), a když se to rozumně napíše, tak se dají dosáhnout hodně slušné odezvy.
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

25. 8. 2017, 7:49

Mex píše:Díky, žes napsal.
Zajímá mě, jak moc použitelné už to v uspace dneska je.
Jaké Ti to dává latence? Nezkoušel jsi prosím jen tak ze studijních důvodů na tom zprovoznit SW stepgeny nebo PWM-geny a podívat co, co v toho leze?
Jde o to, že RTAI a tedy kernelový režim funguje jen na platformě PC. Všude jinde (tedy v praxi dnes asi hlavně na ARMu) už to musí jen v uspace. Tak mě zajímá, co se od toho dá očekávat. To porovnání kernelového a uspace režimu na stejném HW může hodně napovědět.

Jinak mě celkem překvapuje, že Ethernetové karty Mesa musí jen v uspace. Podle mě pro to není žádný zásadní důvod. Vlasní driver síťovky je určitě kompatibilní s kernelovým real-time. A vyšší vrstvy (IP stack) by vůbec používat nemuseli, pro komunikaci s CNC interpolátorem to celkem k ničemu není.

Kdysi dávno (to ještě chodili po světě poslední dinosauři) jsem psal takovou real-time komunikaci ještě na UnixWare (tam jsem měl i vlastníma rukama napsaný driver síťovky) a pak i na Linuxu (tam už s běžným Linuxovým driverem), a když se to rozumně napíše, tak se dají dosáhnout hodně slušné odezvy.

Moc to nesleduju, ale přecejenom se člověk neubrání jak tak pročítá hromadu informací aby v tý hlavě něco neutkvělo.
LinuxCNC dříve EMC existuje hromadu let. Před dávnými časy (těsně po vymření dinosaurů) existovaly dvě hlavní nezávislé větvě vyvoje pro real time. RT-Linux a RTAI. RT-Linux postupně upadl a tak zůstala jen jediná cestička.
RTAI byl a je určený jen a pouze na platformu PC, čím je značně omezeno jeho nasazení. Navíc LINUXCNC a jeho kompilace je přímo svázaná s jádrem, to znamená, že když se změní kus jádra je potřeba ho znovu překompilovat a binárně je tím pádem nepřenositelný. Snaha vývojářů v posledních letech je psát programy nezávisle na jádru,používat POSIX API a jiné věci umožnujíci abstrahovat vlastní program od jádra.
Následovalo nekolik pokusů chytrých jedinců a nakonec vznikl RT-PREEMT patch pro debian.
Dalším důvodem vzniku uspace je platforma x86. V dnešní době ARMU a jinych chytrych procesoru za par korun a snaha vývojářů řídích systému vedla k nové větvi LINUXCNC a to MACHINEKIT pro všechny maliny, ostružiny, banany a beaglebony.
Po nejakem čase tak vlastně zpětně vznikl uspace i pro x86 a byl napsan od počátku protože nešlo jen sloučit větve git z machinekitu na linuxcncn.
Takže výsledkem je to, a je to jen muj osobni a možná mylný pocit, že rtai jako takovy postupně vyšumí a hlavní proud pujde do uspace. A to je možná i duvod,proč nikdo nenapsal driver pro ethernet pro mesy do rtai ale do uspace ano. Přesto že by to jak říkáš nemel být problém. Tomu nerozumím to je moc složitý.

Otázkou zůstává, jestli to celé je dobře nebo špatně. Určitě dobře je, že to půjde rozběhat na více platformách, ale možná za cenu ztráty výkonu. přecejenom, když udělám jednoučelovou věc, tak slouží přesně k tomu k čemu má a podstaně lépe, než nejaký univerzální nástroj. Nicméně mi tvoje otázka nedala a protože tady mám pár ethernetovejch desek od RaSe a Luboše na nejaký jejich nový mašinky, tak tu samozřejmě mám i stroj s uspace a tak sem udělal hned po ránu test.
Výsledek mě trochu zarazil. protože říká něco jiného než sem napsal v předchozí větě.
v dokumentaci k uspace se píše, že by měl na většině strojů běžet alespon tak, že zvládne servo-thread. ten pro mesy pohodlně staci.
pustil sem latency test na RT-PREEMT 3.0.2. a výsledek servo-thread max jitter 3 978ns base-thread 9 862
nasledoval reboot do klasickeho rtai 3.4.9 servo-tread 7 665 029 ns base thread 8 035 165 ns proste naprosto nepouzitelny.
Počítač je nejaký mini-PC asus.
Závěr si musí udělat každý sám. :-)

M
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

25. 8. 2017, 2:29

Počkej, to je na mě takhle při pátku trochu moc.
Pochopil jsem to správně, že na té stejné mašině Ti vyšla latence s RP-preempt neskutečně dobrá, a s RTAI neskutečně špatná?
Nebyla někde koncepční chyba měření?
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

26. 8. 2017, 3:33

Mex píše:Počkej, to je na mě takhle při pátku trochu moc.
Pochopil jsem to správně, že na té stejné mašině Ti vyšla latence s RP-preempt neskutečně dobrá, a s RTAI neskutečně špatná?
Nebyla někde koncepční chyba měření?
No jo, takhle mi to vyslo. Nikde sem nic nenastavoval, jen pustil latency-test ve dvou ruznych jadrech.
V pondeli to jeste zkontroluju. I me zarazil vysledek. Nikdy me to nenapadlo merit, kdyz sem v uspace potreboval jen servo-thread pro mesu.
Neni problem uspace rozbehat, jsou to tri prikazy a mas ho tam.
M
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

28. 8. 2017, 1:13

Mex píše: Nebyla někde koncepční chyba měření?
Tak si měl pravdu. chyba mezi klavesnici a židlí.
Instalace uspace z repozitaře pomoci apt-get nahradí původní linuxcnc a tim to je.
takže sem vlastne pouštěl linuxcnc zkompilovanej pro uspace an rtai jadru.
rano sem nainstaloval čistý jadro 3.4.9 a vysledek je stejnej a jeste trochu lepsi nez u uspace. jitter nekde kome 3000.
pak sem nahradil linuxcnc uspace verzi (sama si dohraje jadro 3.2.0) a v tu ranu vsechno spatne, hodnoty 3miliony, samozrejme pouze na rtai jadru 3.4.9. na jadru 3.2.0 krasny hodnoty 5000.
nasledne sem stahnul dalsi verzi linuxcnc z gitu (git clone......) a zkompiloval pro rtai 3.4.9. nastavil prostredi a hodnoty kolem 4000 byly zpet.
takze zalezi na tom jestli chces pouzivat obe verze. pak je potreba instalovat z gitu a danou verzi si zkompilovat.
Dopeledne v prdeli ale aspon víme čím to je.

M
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

28. 8. 2017, 1:35

Díky za (jak je u Tebe obvyklé) hodnotný příspěvek.
I když ne úplně ho chápu, trochu to nesedí s tím, co jsi naměřil minule (i když už víme, že se měřila nesprávná konfigurace).
Beru to ale tak, že teď jsi to změřil všechno správně, takže platí nové výsledky, staré jsou zapomenuty. A z nich plyne, že uspace je prudce použitelný, což je skvělé.
Takže ještě jednou díky.
:-)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

26. 7. 2018, 3:45

Vyzkoušel jsem LinuxCNC v uspace, a jsem z toho hodně smutný.
Testoval jsem to na dvou PC - jedno a Atomem a jedno s AMD Athlonem. Na RTAI obě mají výborný jitter - Atom pod 11000, AMD pod 9000.

Použil jsem jádro 3.2.0-6-rt-686-pae a přes apt-get stažený aktuální LinuxCNC ve verzi uspace.
Jitter se změnil naprosto dramaticky. Bez zátěže se zvedl na AMD na 65000/32000 (servo/base), na Atomu pak 180000/65000. Při zátěži pak mnohem víc, třeba Atom na servothreadu občas skočí až na 650000.
Mám správně spárované verze, tj. jádro s PREEMPT-RT s LatencyTest pro uspace.
Jako poslední záchranu ještě zkusím Xenomai.

Fupe tady psal o jitteru kolem 4000. To snad musí být nějaké zázračné PC, nebo já mám naopak posrané PC, případně ruce.

Docela tragédie, řekl bych.
Jak je to prosím u vás?
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

26. 7. 2018, 5:07

To bude v pc
Zkus se povrtat v biosu
Me pomohlo na jednom pc povypinat veci kolem usb
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

26. 7. 2018, 5:27

Díky za tip.
Nicméně mám to na dvou naprosto různých PC, kde obě pod RTAI vykazují jitter velmi dobrý.
No - zkusím to. Budu muset někde vyhrabat starou PS/2 myš, abych mohl komplet vypnout USB.

Jestli to máš na nějakém svém PC v uspace - co Ti tam prosím hlásí Latency test? A jak to je nebo není závislé na zátěži?
Zřejmě to v uspace asi musíš provozovat, když používáš EtherCAT, že jo.
Díky.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

26. 7. 2018, 5:32

Dostal jsem se na 70000 puvodle pul mega az mega a desne to litalo tech 70k nijak nelita nabehne to hned a drzi
Jj ethercat tam mam
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

26. 7. 2018, 8:53

Takže poznatky:
Latence/jitter na Intel Atom se výrazně zlepšila po vypnutí hyper-threadingu. Na jádře s RTAI to prakticky nemá vliv, na variantě s PREEMPT-RT ale výrazný.

Celkově se mi povedlo se dostat na AMD na cca 70us/50us, na Intel Atom na cca 80us/60us, zcela výjimečně to skočilo na 100us.
Závislost na zátěži procesoru minimální, trochu to skákalo při spouštění programů, takže zřejmě to ovlivňovala práce s řadičem HDD.

Takže hodnoty cca 5-10x horší, než na stejném HW s RTAI. Úplná hitparáda to není, ale jsou to už celkem použitelné hodnoty, zvlášť když se nebude používat base-thread.

Nicméně hodnoty, o jakých psal fupe (4-5us) jsou pro mě absolutně nedosažitelné. Takže ho podezřívám, že si z nás dělal srandu a chtěl nás naštvat. Něco jako "chytil jsem táááákhle velkou rybu".

Dobrá zpráva je ale z jiné oblasti: díval jsem se na EtherCAT mastera od IgH/EtherLab. A pokud se použijí jejich upravené drivery, tak se dá LinuxCNC i s EtherCATem spustit pod RTAI !
Tak to je skvělé, já jsem si mylně myslel, že to musí běžet s uspace, proto jsem to testoval. V uspace to musí běžet jen pokud se používají univerzální ethernetové drivery.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

27. 7. 2018, 12:10

No vida
To jsem prehledl
Vsechna prava na chyby vyhrazena (E)
fupe
Příspěvky: 638
Registrován: 27. 5. 2008, 9:10
Bydliště: Praha

6. 8. 2018, 8:09

Mex píše: 26. 7. 2018, 8:53 Nicméně hodnoty, o jakých psal fupe (4-5us) jsou pro mě absolutně nedosažitelné. Takže ho podezřívám, že si z nás dělal srandu a chtěl nás naštvat. Něco jako "chytil jsem táááákhle velkou rybu".
Tak přece bych vás netahal za fusekli.
Posílám důkaz místo slibů.
uspace2.png
:D
Martin
Odpovědět

Zpět na „LinuxCNC - drive pod nazvem EMC2“