auch von meiner Seite, herzliches Dankeschön, Deiner Arbeiten. Trotz allen empfohlenen und durchgeführten Anpassungen liegen Readtime bei 170`000 und Writetime um 12000.
Sehe cool. Danke für deine Arbeit! Ich hatte das erst auch immer gedacht, weiß aber mittlerweile, dass die 600.000 im halscope allerdings counts sind und keine ns! Du musst das also in Relation zum Takt setzen. Meist ja so um 3 Ghz. 600.000 sind dann also 200 us und matchen dann ganz gut mit den pings der Kombinationen. Da es immer ein read/write gibt und die calculation in der Mitte, kann man dann mit Sicherheitsreserve ein 600.000 counts readrime System mit einem 1ms Swrvothread noch gut betreiben, wenn der jitter gut ist. Ich kann bei gutem Jitter ein System mit 200.000 counts readtime stabil mit 4kHz betreiben.
Super Hinweis! Das erklärt warum ich mit eingestellten 200 us und einer Anzeige von 290.000 im Scope keinen Fehler bekomme. Was auch bedeutet, dass der servo thread tatsächlich mit ca. 70 us laufen würde. Wirklich sehr gut zu wissen.
@Partyhunter100 200us mit einer readtime von 290000 ticks sind je nach Cpu aber bereits knappe Kante. Du darfst nicht vergessen, dass du immer folgendes hast: read calculation write jitter Wenn ich mal von 3GHz ausgehe hast du also eine readtime von 96us (vgl. Ping). Calculation kann wenig sein bei einer knappen hal. Sagen wir 30us. Jitter bei geilen Cpus unter 10us. Write ist sone Sache..Bin nicht 100% sicher ob man von der halben Zeit ausgehen darf/kann. Du siehst. Dann sind die 200us voll.
@@juliankonig1412 Danke für die Rückmeldung, der Wert hatte sich auch rein durch ausprobieren ergeben und läuft bisher ohne Fehler zu verursachen. Ich gebe dir aber durchaus recht, dass es knapp erscheint, vorallem wenn es 3 GHz wären. Hier vlt. noch ein paar weitere Infos. Die CPU (Ryzen 5 4500) läuft dauerhaft mit 4,2 GHz und der Ping liegt bei ca. 0,07 ms, was in etwa den errechneten Werten entspricht. Read time wird mit ca. 283.000 Ticks angezeigt, write time mit 6.000 Ticks und servo thread time mit ca. 290.000. Der Jitter liegt im Latenztest bei etwas unter 10.000 ns bei Belastung des Rechners.
@Partyhunter100 Jo. Dann hast du so in etwas die Hardware die allgemeinhin als Maximum für Netzwerk Mesakarten angesehen wird. 5kHz gilt so in etwa als erreichbare Grenze (die du ja hast). Bei 4,2 GHz wird noch etwas mehr gehen, aber dann ist Schluss.
Hi Peter, thank you for your excellent videos. Just one remark: in my experience with N100 based systems, it would probably be better to use "quiet irqaffinity=0 isolcpus=2,3". At least for my system that gave me much better low latency results, but I understand that different motherboards may give different results. Could you test that on your system? I am curious what the result would be on your ASRock N100DC-ITX board.
Thank you for your kind words and the suggestion! 😊 I did test the setting "quiet irqaffinity=0 isolcpus=2,3" on my ASRock N100DC-ITX board. However, when using this configuration and running the ServoThread at 4kHz, I experienced connection drops with the Mesa card. With "quiet irqaffinity=0 isolcpus=0,1," I can reliably run the ServoThread at 4kHz without any communication errors with the Mesa card. It seems like CPU settings play a significant role here, but as you mentioned, results can vary depending on the motherboard. Thanks again for sharing your experience, and let me know if you find other tweaks worth testing!
@@talla83 Thank you for testing it! When I try "quiet irqaffinity=0 isolcpus=0,1" on my N100 system, the max jitter for the servo thread easily goes up to 160us, while with isolcpus=2,3 it stays below 20us. I really think it may be related to how the motherboard has been implemented. One more thing: I believe it is usually advised not to run the IRQs on the isolated cores, except for the IRQs related to the ethernet port for the Mesa card. What is your experience in that respect? And have you tried to use irqbalance daemon instead of irqaffinity? There is an interesting thread on the LinuxCNC forum about the use of the irqbalance daemon, including a script that assigns the Mesa card ethernet port to the highest isolated cpu core. The irqdaemon automatically assigns all other IRQs to the non-isolated cores and this setup is supposed to further reduce latency jitter.
@@ericr.5477 Yes, I’m familiar with the discussions and approaches from the LinuxCNC forum. I’ve also tried several variations and methods, but only this combination ensures a stable Ethernet Mesa connection on my system with a 4kHz servo thread. As I’ve mentioned in the videos, everyone has to experiment with their own system and find the optimal parameters. There is no universal solution for everyone.
@@talla83 At least I'm glad that you seem to have mixed results with the different approaches, just like me. There really does not seem to be a uniform success formula. It's more a kind of black magic, where trial and error is the only way to go. That even seems true for some of the bios settings. Thank you for all your efforts and feedback. Much appreciated!
ein mainboard mit nur einer LAN schnittstelle? wie machst du das mit den mesa ethernetkarten? hast du die am lan und gehst via wlan ins internet? ich mache es mir jeweils einfach und verbaue ein UP Squared Pro Edge mit Intel Celeron N3350. ist günstiger und fixfertig und passt locker in den steuerschrank. perfomance ist nich gewaltig, aber linuxcnc läuft flüssig und problemlos
auch von meiner Seite, herzliches Dankeschön, Deiner Arbeiten. Trotz allen empfohlenen und durchgeführten Anpassungen liegen Readtime bei 170`000 und Writetime um 12000.
Danke fürs erwähnen meiner Arbeit.
Wieder mal ein sehr interessantes und informatives Video, vielen Dank dafür 👍
Sehe cool. Danke für deine Arbeit!
Ich hatte das erst auch immer gedacht, weiß aber mittlerweile, dass die 600.000 im halscope allerdings counts sind und keine ns!
Du musst das also in Relation zum Takt setzen. Meist ja so um 3 Ghz. 600.000 sind dann also 200 us und matchen dann ganz gut mit den pings der Kombinationen.
Da es immer ein read/write gibt und die calculation in der Mitte, kann man dann mit Sicherheitsreserve ein 600.000 counts readrime System mit einem 1ms Swrvothread noch gut betreiben, wenn der jitter gut ist.
Ich kann bei gutem Jitter ein System mit 200.000 counts readtime stabil mit 4kHz betreiben.
Super Hinweis! Das erklärt warum ich mit eingestellten 200 us und einer Anzeige von 290.000 im Scope keinen Fehler bekomme.
Was auch bedeutet, dass der servo thread tatsächlich mit ca. 70 us laufen würde.
Wirklich sehr gut zu wissen.
@Partyhunter100 200us mit einer readtime von 290000 ticks sind je nach Cpu aber bereits knappe Kante. Du darfst nicht vergessen, dass du immer folgendes hast:
read
calculation
write
jitter
Wenn ich mal von 3GHz ausgehe hast du also eine readtime von 96us (vgl. Ping). Calculation kann wenig sein bei einer knappen hal. Sagen wir 30us. Jitter bei geilen Cpus unter 10us. Write ist sone Sache..Bin nicht 100% sicher ob man von der halben Zeit ausgehen darf/kann.
Du siehst. Dann sind die 200us voll.
@@juliankonig1412 Danke für die Rückmeldung, der Wert hatte sich auch rein durch ausprobieren ergeben und läuft bisher ohne Fehler zu verursachen. Ich gebe dir aber durchaus recht, dass es knapp erscheint, vorallem wenn es 3 GHz wären.
Hier vlt. noch ein paar weitere Infos.
Die CPU (Ryzen 5 4500) läuft dauerhaft mit 4,2 GHz und der Ping liegt bei ca. 0,07 ms, was in etwa den errechneten Werten entspricht. Read time wird mit ca. 283.000 Ticks angezeigt, write time mit 6.000 Ticks und servo thread time mit ca. 290.000.
Der Jitter liegt im Latenztest bei etwas unter 10.000 ns bei Belastung des Rechners.
@Partyhunter100 Jo. Dann hast du so in etwas die Hardware die allgemeinhin als Maximum für Netzwerk Mesakarten angesehen wird. 5kHz gilt so in etwa als erreichbare Grenze (die du ja hast). Bei 4,2 GHz wird noch etwas mehr gehen, aber dann ist Schluss.
Hi Peter, thank you for your excellent videos. Just one remark: in my experience with N100 based systems, it would probably be better to use "quiet irqaffinity=0 isolcpus=2,3". At least for my system that gave me much better low latency results, but I understand that different motherboards may give different results. Could you test that on your system? I am curious what the result would be on your ASRock N100DC-ITX board.
Thank you for your kind words and the suggestion! 😊 I did test the setting "quiet irqaffinity=0 isolcpus=2,3" on my ASRock N100DC-ITX board. However, when using this configuration and running the ServoThread at 4kHz, I experienced connection drops with the Mesa card.
With "quiet irqaffinity=0 isolcpus=0,1," I can reliably run the ServoThread at 4kHz without any communication errors with the Mesa card. It seems like CPU settings play a significant role here, but as you mentioned, results can vary depending on the motherboard.
Thanks again for sharing your experience, and let me know if you find other tweaks worth testing!
@@talla83 Thank you for testing it! When I try "quiet irqaffinity=0 isolcpus=0,1" on my N100 system, the max jitter for the servo thread easily goes up to 160us, while with isolcpus=2,3 it stays below 20us. I really think it may be related to how the motherboard has been implemented. One more thing: I believe it is usually advised not to run the IRQs on the isolated cores, except for the IRQs related to the ethernet port for the Mesa card. What is your experience in that respect? And have you tried to use irqbalance daemon instead of irqaffinity? There is an interesting thread on the LinuxCNC forum about the use of the irqbalance daemon, including a script that assigns the Mesa card ethernet port to the highest isolated cpu core. The irqdaemon automatically assigns all other IRQs to the non-isolated cores and this setup is supposed to further reduce latency jitter.
@@ericr.5477 Yes, I’m familiar with the discussions and approaches from the LinuxCNC forum. I’ve also tried several variations and methods, but only this combination ensures a stable Ethernet Mesa connection on my system with a 4kHz servo thread.
As I’ve mentioned in the videos, everyone has to experiment with their own system and find the optimal parameters. There is no universal solution for everyone.
@@talla83 At least I'm glad that you seem to have mixed results with the different approaches, just like me. There really does not seem to be a uniform success formula. It's more a kind of black magic, where trial and error is the only way to go. That even seems true for some of the bios settings. Thank you for all your efforts and feedback. Much appreciated!
ein mainboard mit nur einer LAN schnittstelle? wie machst du das mit den mesa ethernetkarten? hast du die am lan und gehst via wlan ins internet? ich mache es mir jeweils einfach und verbaue ein UP Squared Pro Edge mit Intel Celeron N3350. ist günstiger und fixfertig und passt locker in den steuerschrank. perfomance ist nich gewaltig, aber linuxcnc läuft flüssig und problemlos
@@petersiegrist4153 er hat eine USB LAN Karte angeschlossen.