Re: Latence na LinuxCNC
Napsal: 1. 10. 2020, 6:28
Ať nezakládám nové vlákno, dám to sem.
LinuxCNC mě stále nepřestává překvapovat.
Doposud jsem používal kernelovou verzi RTAI. A to proto, že tady vychází latence lépe, všechno podstatné běží přímo na úrovni jádra a tak do toho ostatní procesy moc nemůžou kecat. Pak se dá slušně používat LinuxCNC i přes LPT.
Ale vývoj směřuje (bohužel) k user-space variantě, tj. k běhu pod RT-PREEMPT.
Tak jsem si nainstaloval novou stabilní verzi LinuxCNC na distribuci Debian Buster 10 64bit s verzí 2.8.0.
Malá odbočka: nová distribuční verze přišla po velmi-velmi dlouho době. A překvapilo mě, jak je (podle mě) odfláknutá.
Instalačka má přes 2 GB, což zas není tak úplně málo. Ale přitom tam schází podle mě tak základní věci jako Samba, NFS, SSHD, RT testy atd.
Vždyť to jsou základní nástroje, jak to používat: otestovat vhodnost daného PC (RT testy), připojit to do sítě (Samba, NFS) a umožnit vzdálený přístup (SSHD).
Člověk Linuxu znalý si to tam jistě snadno doinstaluje sám. Ale nepoužívají to jen lidé Linuxu znalí, a pak je to případně zbytečně odradí.
Konec odbočky.
Abych i na systému s PREEMPT-RT dosáhl aspoň trochu rozumné latence, tak jsem vyčlenil jedno jádro pro real-time. Mám to na 3-jádrovém počítači, tak samozřejmě poslední jádro, tj. jádro 2 (parametrem isolcpus=2).
No ale teď přichází moje překvapení: systém to jádro sice vyřadil z plánování pro běžné procesy, ale nepošle na něho ani ty real-time, které by tam podle mě patřit měly. Tedy jádro vlastní obsluhy HALu, a v mém případě taky ještě EtherCAT master. Systém prostě to jádro nechal úplně prázdné, zcela nevytížené.
Výpis RT programů, které by tam zřejmě měly být. Je vidět, že mají nastaveno, že můžou jít na všechna jádra, tedy 0,1,2 (to je ten 4. sloupeček ve výpisu). Běžné programu tam mají uvedeno jen 0,1:
1214 OTHER 0 0,1,2 29 24 rtapi_app
1219 OTHER 0 0,1,2 10295 777 EtherCAT-OP
No a výpis, na kterém jádru je systém reálně spustil (ani jeden neběží na vyčleněném jádru 2, viz 1. sloupeček výpisu):
1 /usr/bin/rtapi_app load threads name1=master period1=1000000
0 [EtherCAT-OP]
Tak buď je něco špatně v LinuxCNC, nebo v mojí hlavě.
Nebo se musí ještě nějak extra konfigurovat jak s tím má systém zacházet? Poradí prosím nějaký znalec?
Na RTAI verzích se EtherCAT master správně umístil na jádro 2. Obsluha CNC tam běží v kernelovém režimu, takže ta tam není vidět vůbec.
******************
A ještě poznámka k otázce, kterou tohle vlákno kdysi začalo. Tedy jak je možné, že někdy latence vyjde zdánlivě záporná.
LinuxCNC to opravdu dělá tak, že počítá s nějakým zpožděním a naplánuje svou obsluhu o něco dřív, než by odpovídalo požadovanému nastavení. Takže ne třeba po 1ms, ale například po 0.99ms. Když mu to pak někdy jde dobře od ruky, tak může skončit dřív, než by správně měl vůbec začínat.
LinuxCNC mě stále nepřestává překvapovat.
Doposud jsem používal kernelovou verzi RTAI. A to proto, že tady vychází latence lépe, všechno podstatné běží přímo na úrovni jádra a tak do toho ostatní procesy moc nemůžou kecat. Pak se dá slušně používat LinuxCNC i přes LPT.
Ale vývoj směřuje (bohužel) k user-space variantě, tj. k běhu pod RT-PREEMPT.
Tak jsem si nainstaloval novou stabilní verzi LinuxCNC na distribuci Debian Buster 10 64bit s verzí 2.8.0.
Malá odbočka: nová distribuční verze přišla po velmi-velmi dlouho době. A překvapilo mě, jak je (podle mě) odfláknutá.
Instalačka má přes 2 GB, což zas není tak úplně málo. Ale přitom tam schází podle mě tak základní věci jako Samba, NFS, SSHD, RT testy atd.
Vždyť to jsou základní nástroje, jak to používat: otestovat vhodnost daného PC (RT testy), připojit to do sítě (Samba, NFS) a umožnit vzdálený přístup (SSHD).
Člověk Linuxu znalý si to tam jistě snadno doinstaluje sám. Ale nepoužívají to jen lidé Linuxu znalí, a pak je to případně zbytečně odradí.
Konec odbočky.
Abych i na systému s PREEMPT-RT dosáhl aspoň trochu rozumné latence, tak jsem vyčlenil jedno jádro pro real-time. Mám to na 3-jádrovém počítači, tak samozřejmě poslední jádro, tj. jádro 2 (parametrem isolcpus=2).
No ale teď přichází moje překvapení: systém to jádro sice vyřadil z plánování pro běžné procesy, ale nepošle na něho ani ty real-time, které by tam podle mě patřit měly. Tedy jádro vlastní obsluhy HALu, a v mém případě taky ještě EtherCAT master. Systém prostě to jádro nechal úplně prázdné, zcela nevytížené.
Výpis RT programů, které by tam zřejmě měly být. Je vidět, že mají nastaveno, že můžou jít na všechna jádra, tedy 0,1,2 (to je ten 4. sloupeček ve výpisu). Běžné programu tam mají uvedeno jen 0,1:
1214 OTHER 0 0,1,2 29 24 rtapi_app
1219 OTHER 0 0,1,2 10295 777 EtherCAT-OP
No a výpis, na kterém jádru je systém reálně spustil (ani jeden neběží na vyčleněném jádru 2, viz 1. sloupeček výpisu):
1 /usr/bin/rtapi_app load threads name1=master period1=1000000
0 [EtherCAT-OP]
Tak buď je něco špatně v LinuxCNC, nebo v mojí hlavě.
Nebo se musí ještě nějak extra konfigurovat jak s tím má systém zacházet? Poradí prosím nějaký znalec?
Na RTAI verzích se EtherCAT master správně umístil na jádro 2. Obsluha CNC tam běží v kernelovém režimu, takže ta tam není vidět vůbec.
******************
A ještě poznámka k otázce, kterou tohle vlákno kdysi začalo. Tedy jak je možné, že někdy latence vyjde zdánlivě záporná.
LinuxCNC to opravdu dělá tak, že počítá s nějakým zpožděním a naplánuje svou obsluhu o něco dřív, než by odpovídalo požadovanému nastavení. Takže ne třeba po 1ms, ale například po 0.99ms. Když mu to pak někdy jde dobře od ruky, tak může skončit dřív, než by správně měl vůbec začínat.