Am Dienstag, dem 20.01.2026 um 17:01 +0200 schrieb Viesturs Lācis: > > > > use the "cpupower" command to monitor frequency > > > > My apologies but I am not sure I understand this. Is that a command > to > run in terminal?
yes that is a CLI program from the linux-cpupower package. > > > > > set cpu frequency governor to "performance": > > > > echo -n performance | sudo tee > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > > > > Ok, did set the governor, but I am not sure about the latter - is > that > one command or 2 separate commands? this is one command (line break inserted by mail client) and sets governor on all cpus > > > > > I guess positioning of the induction coil doesn't need to be very > > precise or fast and timing is also not that critical, so you could > > probably get away with a way slower servo thread (500kHz / 250kHz). > > > > I actually did that on old laptop, increased servoperiod to 2ms but > colleagues who supervise the experiments have told me about Mesa card > read errors. read errors are probably not directly related to bad worst-case latency. to pin IRQs, you need to look at /proc/interrupts, there you see how many times which interrupt request was handled on what core, also it should say source of interrupt request in last column. you can influence which irqs are handley by what core in /proc/irq/<number>, look at https://www.kernel.org/doc/html/latest/core-api/irq/irq-affinity.html for explanation of files. isolated cores (cat /sys/devices/system/cpu/isolated) should not serve any interrupt requests (except local timer and stuff) I'm not sure if it is better so serve mesa network interface interrupts on the realtime core or on a different core, in any case, it shouldn't make a huge difference if any at all. -- Robert Schöftner <[email protected]> _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
