Latence na LinuxCNC

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

16. 1. 2020, 5:02

Dopisoval jsem si v jiném vlákně s kolegou kolem latence na LinuxCNC.
A když jsem se nad tím zamyslel, tak zjišťuju, že v tom mám vlastně sám taky hokej.
Na obrázcích je výpis latence v textové a grafické podobě.
Ten textový vypadá normálně. Ale jak je možné, že v tom grafickém histogram u latence Base-threadu ukazuje hodnoty skoro symetricky kolem nuly?
Jak může být latence záporná? Přece zpoždění nikdy nemůže být záporné.
Nebo to ten plánovač plánuje tak blbě, že občas dá povel k probuzení vlákna předčasně? Nebo skutečně startuje v předstihu, ale je to naopak optimalizace aby to v průměru pak vycházelo co nejlíp?
U Servo threadu je to OK, tam je latence vždy kladná.
Jde o to, jak stanovit nejhorší možný případ a jak pak nastavit frekvenci Base-threadu. Pokud platí ten histogram, tak je třeba uvažovat ten jitter jako +-, což je vcelku nepříjemné.
Jestli v tom máte někdo jasno, udělejte prosím nějakou osvětu.
Díky.
Latence_textove.jpg
Latence_graficky.jpg
Uživatelský avatar
zz912
Příspěvky: 1354
Registrován: 25. 5. 2008, 7:16

27. 2. 2020, 4:05

Definice latence dle Wikipedie je zde:
https://cs.wikipedia.org/wiki/Latence

Pochopil jsem to tak, že v prvním okně máš latency test. Ovšem v tomto latency testu se vyloženě latence nevyskytuje. Vyskytuje se tam reakce na "podnět" trvající 1ms nebo 25us.

Last interval - představuji si to tak, že systém má něco udělat za 1ms = 1 000 000 ns a on to udělá za 996 635 ns , tato proměná ukazuje momentální stav

Max interval - to samé co Last Interval, ale zobrazuje maximální hodnotu za dobu testu

Latence - pochopil jsem to tak: Latence = Zadaná 1ms - Last Interval (Proto může být Latence +/- , tak jak je vidět v histogramu)

Jitter = Max interval - Min interval (Myslím si, že Jitter tím pádem nemůže být záporný)

Dále co není ve Tvém dotazu přesné je to, že u Servo threadu je latence pouze kladná. Týká se to jen Tvého počítače. Můj počítač i vzorové latency testy na linuxcnc.org mají latenci servo threadu +/-.

Ovšem čím více linuxCNC studuji, tím více zjišťuji že nic nevím. Tudíž jaký postup zvolit při nastavování Base Threadu zůstává záhadou.

Dále jsem si zkomplikoval život tím, že na svém cnc mám dva paralelní porty a tímpádem mi tam běží 2 vlákna. Což absolutně netuším jaký to má vliv na co.

Vím, že nemáš rád kouzelníky, ale z poznatku zkoušení stepconf, jsem přišel na to, že změna Jitteru nemá vliv na BaseThread. (Možná má, ale nepodařilo se mi to nasimulovat)
Ale "Driving Timing Seting" ovlivňuje BaseThread.

Prej k celému LinuxCNC se dá dostat ke zdrojákům, tak možná by se dalo dostat i ke zdrojákům stepconf a něco z toho vyčíst, ale to budu umět až v roce 2148, pokud budu studovat LinuxCNC rychlostí, jako teď.

Tak co Mexi podařilo se mi splnit domácí úkol? Není úplný, takže aspoň za 4?
LinuxCNC - MESA 7i96
zz912.webnode.cz
Mex
Příspěvky: 10287
Registrován: 6. 2. 2014, 10:29

27. 2. 2020, 4:58

Vezmu to odzadu.

Známkovat Tě nebudu. Učitelům prý furt přidávají prachy, ale mi nikdo nic nedal. Tak za trest neznámkuju, a z výkladu jsem vynechal láčkovce.

Jasně, k LinuxCNC jsou zdrojáky. Je to kompletně Open Source projekt, což je na něm super. Já sám jsem si v něm třeba upravoval drivery, aby mi fungovaly PCI a PCIexpress LPT karty v EPP režimu.

Pokud máš v systému 2 LPT karty, tak to neznamená, že tam proto běží 2 vlákna. Resp. 2 vlákna tam běží, ale jedno je Servo thread a druhé Base thread. Nesouvisí to s tím, že máš 2 karty. Ty jsou obsluhované normálně po sobě tím samým vláknem.

K latenci: latence je dopravní zpoždění. Tedy doba od podnětu po reakci.
Není to reakce na podnět, trvající 1ms nebo 25us, ale reakce na podněty, které chodí pravidelně každou 1ms a 25us.
Tedy každou 1ms "zazvoní budík", vzbudí dané vlákno, to provede svou obsluhu a zase usne. No a latence by měla být doba mezi zazvoněním budíku a tím, kdy vlákno začne svou činnost. Jitter je tam rozptyl doby mezi nejkratší a nejdelší latencí za nějakou dobu.

Takže proto by skutečná latence (podle mě) neměla být nikdy záporná. Nemůže být záporná doba mezi zazvoněním budíku a dobou, kdy reálně vstanu. Možné je to jedině v případě, že systém nastavuje ten budík už v předstihu, protože počítá s tím, že nějaké zpoždění tam vždycky je. Jedině tak si dovedu vysvětlit zápornou latenci.

No a ono to asi (možná) souvisí s tím, jak je ten budík realizován. Běží to v obecném operačním systému, takže si tam SW nemůže dělat co chce. Třeba takové GRBL nebo jiný SW na jednochipu by si prostě nastavil HW čítač, a ten by vyvolal přerušení každou 1ms a 25us. Ale v Linuxu se to zřejmě dělá tak, že program jen zapíše do fronty požadavků svůj požadavek na probuzení a obsluhu za daný interval. A systém už to nějak řeší ve své režii. Buzení po 1ms asi trefí přesněji, protože to už může být navázané na skutečný HW TIK od nějakého timeru. Ale těch 25us se asi dělá jinak. A zřejmě tam může dojít k tomu, že se opravdu vlákno vzbudí dřív, než by měl být jeho čas.
Ten program Latency test pak zjistí přesný čas obsluhy podle HW hodin, které běží s nanosekundovou přesností, takže jeho měření už je přesné.

Jak latence (nebo spíš jitter) ovlivňuje max. frekvenci Base threadu: No mělo by být zajištěno, že obsluha jednoho intervalu skončí spolehlivě předtím, než začne obsluha dalšího intervalu. Takže pokud mám třeba jitter 40us, je jasné, že Base thread musí mít periodu delší, než je ten jitter. Může se totiž stát, že se to sejde tak, že v jednom intervalu bude latence maximální, a hned v dalším zase minimální. A nikdy se nesmí překrýt konec zpracování jednoho intervalu se začátkem dalšího intervalu. Navíc by tam měla ještě zbýt nějaká doba na jiné zpracování a rezerva pro to, že zpracování v každé periodě může být trochu jinak dlouhé.
Takže při jitteru třeba tech 40us bych nedělal rychlejší Base thread než třeba každých 50us, tedy 20 kHz. A i to už je dost na hraně. A protože každý pulz STEP potřebuje 2 průchody Base threadu, tak pak musí být maximální frekvence STEP nižší než 10 kHz.

****************

Při použití Mesy je to ale jinak. Tam ty rychlé věci dělá Mesa sama na HW úrovni. Systém ji jen každou 1ms zaúkoluje, co má v následujícím intervalu dělat (default je 1ms, ale dá se nastavit jinak).
A je to zařízeno docela chytře, že to umí kompenzovat i rozptyl toho Servo threadu, protože před zadáním nového úkolu napřed LinuxCNC (resp. driver Mesy) zjistí, kolik toho od minulého požadavky reálně udělala, a podle toho případně upraví požadavky do dalšího intervalu.
Uživatelský avatar
zz912
Příspěvky: 1354
Registrován: 25. 5. 2008, 7:16

27. 2. 2020, 5:26

Děkuji za rozsáhlou odpověď, řádně prostuduji.

Tady jsem našel vysvětlení Jitteru:
https://www.youtube.com/watch?v=OpkDz6F ... jm&index=6
7 minut 27 sekund

a teď jsem našel:
https://www.youtube.com/watch?v=sW7uFKP ... jm&index=8
LinuxCNC - MESA 7i96
zz912.webnode.cz
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22385
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

27. 2. 2020, 6:13

to nebude az tak o studiu linuxcnc zdrojaku ale spis rtai patche do jadra jakym zpusobem se vytvari ta reatime priorita
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10287
Registrován: 6. 2. 2014, 10:29

27. 2. 2020, 6:34

A jak vychází ten histogram na systému s Preempt-RT?
Já tady nemám žádnou instalaci v uspace, tak to nemůžu jednoduše vyzkoušet. Musel bych to přeinstalovat a to chvilku trvá.
Tam budou latence/jitter samozřejmě horší. Ale zajímalo by mě, jestli taky ten histogram vychází symetricky kolem nuly.

Ale o tom studiu zdrojáků by to přece jen taky asi trochu bylo.
Docela by mě zajímalo, jestli LinuxCNC pošle do scheduleru požadavek na probuzení pokaždé za 25us, nebo jestli to nějak modifikuje podle latence daného systému.
Mex
Příspěvky: 10287
Registrován: 6. 2. 2014, 10:29

27. 2. 2020, 9:59

Nikdo neodpověděl, tak si odpovím sám.
Ano, i v uspace s Preempt-RT je histogram latence symetrický kolem nuly.
A latence/jitter je samozřejmě mnohem horší než s RTAI, na mém konkrétním stroji zhruba skoro 10-násobný (62000 proti cca 6500 ns).
Bylo by moc fajn ethernetovou Mesu vyškolit, aby jela pod RTAI. Je zvláštní, že to ještě nikdo neudělal/nedokázal.
prcek
Příspěvky: 692
Registrován: 31. 10. 2016, 2:26

28. 2. 2020, 3:34

Mex píše: 27. 2. 2020, 9:59
Bylo by moc fajn ethernetovou Mesu vyškolit, aby jela pod RTAI. Je zvláštní, že to ještě nikdo neudělal/nedokázal.
Nemuze byt problem v tom, ze budes muset vyskolit i cely blazinec okolo ethernet a IP?
--
Všechno je snadné, než to zkusíš sám.
Mex
Příspěvky: 10287
Registrován: 6. 2. 2014, 10:29

28. 2. 2020, 4:19

prcek píše: 28. 2. 2020, 3:34 Nemuze byt problem v tom, ze budes muset vyskolit i cely blazinec okolo ethernet a IP?
Jasně, o to jde.
Ale kus práce už je hotový. Pro EtherCAT udělali hoši z IgH bezinterruptové drivery, které se dají komplet používat v kernelovém režimu.
Ten režim práce v EtherCATu a při obsluze ethernetové Mesy zase nebude tak moc odlišný. Sice se u té Mesy asi musí čekat na odpověď, tedy pokud je to tam dělané stejně jako třeba u LPT Mesy 7i90. Ale i to by se asi dalo nějak ošéfovat. Navíc na druhé straně odpovídá hradlové pole, takže nehrozí opoždění odpovědi.

Samozřejmě by pak musela být pro Mesu vyčleněna jedna ethernetová karta. Ale to snad soudný člověk udělá stejně, i když to technicky v současném provedení lze provozovat i na sdíleném Ethernetu.
Mex
Příspěvky: 10287
Registrován: 6. 2. 2014, 10:29

28. 2. 2020, 4:30

Ještě jedna poznámka.
Včera jsem si dost dlouho hrál s novými verzemi jádra.
Po dlouhé době opět hoši, co stojí za RTAI, naportovali RTAI na aktuální jádro 4.x (předtím se několik let stále používal port na staré jádro 3.x).

Ta předvařená verze je nachystaná jako Linux Mint, a je udělaná v 64-bit provedení. Sice by se mi víc líbila 32-bit verze, no ale na pokus dobré.

Pozitivní je, že to funguje. Takže budoucnost RTAI je zase na několik let zajištěna.
Lehké negativum je, že latence/jitter tam vychází trochu hůř, než na starém jádře 3.x. Možná je to trochu dáno i 64-bit režimem?

Na stejném HW u mě stará distribuční verze LinuxCNC 2.7.15 má jitter 7000/6000ns, při opravdu brutální zátěži pak 7600/8600nm (první číslo je vždy Servo thread, za lomítkem Base thread).
Nový LinuxMint pak 10000/14000ns, při brutální zátěži 11500/14300ns.
Deska je nějaká dost stará Gigabit se starým AMD Athlonem (dostal jsem zdarma, bylo určeno k ekologické likvidaci), grafika integrovaná na desce.
prcek
Příspěvky: 692
Registrován: 31. 10. 2016, 2:26

21. 3. 2020, 8:45

Zajimave video o tom, co je to vlastne realtime a jak se lisi preempt-rt a Xenomai (nebo RTAI)
https://www.youtube.com/watch?v=BKkX9WASfpI

No a mam dotazy.
Mam nejaky hardware, a asi bych na nem chtel pustit stejny test na ruznych distrech. A protoze tech kombinaci, co jsem si navymyslel je nejmene 10, nehodlam to delat rucne, ale pokud mozno si vetsinu zautomatizuju. Mimo jine, abych omezil pocet lidskych chyb.

dotaz1) jaka je minimalni rozumna doba "aby se neco zjistilo" - v odkazovanem videu se pravi, ze 12 hodin
dotaz2) jde ten latency test pustit primo z prikazove radky, idealne aby vysledky vypisoval v textu a ne v grafice? Jen spustit primo test s graf. vystupem se taky pocita.
dotaz3) jakym zpusobem "trapite" pocitac, kdyz delate latency test?

edit: kdybych vcas pouzil vyhledavac, nasel bych toto
http://wiki.linuxcnc.org/cgi-bin/wiki.p ... cyTestDoes

odpoved2) Ano lze, maximalni latency ulozi do ~/.latency kdyz se ukoncuje (takze je treba ho po nejake dobe setrne zabit)

dotaz4) jake casy pouzit pro base a servo period? defaultni - 25us a 1ms ?
--
Všechno je snadné, než to zkusíš sám.
Mara2000
Příspěvky: 122
Registrován: 22. 5. 2012, 9:29

24. 8. 2020, 8:23

Ahoj,

Nechal jsem cca hodinu běžet latence test a zde je výsledek. Asi to nebude uplně v pořádku že?

Mám serva napojené na Mesu 7i76e.

Čeká mě bádání jak to snížit na rozumnou úroveň, občas mi LinuxCNC vyhodí hlášku:

Unexpected realtime delay on task 0 with period 1000000,
This message will only display once per session,
Run latency test and resolve before continuing

Nebo to lze nějak obejít přenastavením Servo threadu?

Děkuji.
Přílohy
Latece.JPG
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22385
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

24. 8. 2020, 8:29

Vlez do biosu a povypinej co nepotrebujes
Hlavne kolem power managementu a rizeni otacek ventilatoru zbytecne veci kolem.usb atd...
Vsechna prava na chyby vyhrazena (E)
Uživatelský avatar
Thomeeque
Příspěvky: 8909
Registrován: 30. 1. 2012, 10:20
Bydliště: Mimo ČR

24. 8. 2020, 8:51

Např. mě pomohlo zaříznout DVDROMku, viz viewtopic.php?p=116428#p116428
mimooborová naplavenina • kolowratský zázrak™ • NPS • GCU • HirthCalc • ncDP.ino
Mara2000
Příspěvky: 122
Registrován: 22. 5. 2012, 9:29

24. 8. 2020, 5:30

Díky kluci, zítra to zkusím poaldit :-)
Odpovědět

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