Richard Biener composed on 2017-08-02 15:15 (UTC+0200):
How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?
I have to think if it wasn't a rolling release that those in timing critical situations and would rather openSUSE than something else would, as summarized here: https://lists.debian.org/debian-user/2017/07/msg00320.html I emailed the author for more details, and got what follows in response: That is probably my best argument on the subject Felix. Generally we build an rtai patched kernel, which is a rather daunting task and use it until its hardware support forces the issue again in 2 or more years. currently, 3 of the 4 cnc machines here are still on the 3.4-9-rtai-686-pae kernel, which has some warts but is generally stable and gives us latencytest results in the 5 to 7 microsecond range. This is not great but is good enough to do software step generation, driving a small machine at useable speeds directly from the parport, in this particular case an atom powered intel D525mw motherboard with 4Gb of dram on it. All other machines here have mesa (or similar, there are other competing brands, usually needing a larger stack of green to buy but with far less responsive support) interfaceing cards installed, which interpose an FPGA based board that does this stepper generation in hardware, and which can, motor voltage effects included, drive the stepper 4 to 8 times faster, because the steppers available speed is highly dependent on a steady stream of pulses so its traveling at a consistent speed. Because steppers stop if something disturbs the step timing for 50 microseconds, and it cannot re-accelerate quick enough when the next step does arrive, they will stall at zero speed until such time as its driver stops it, and the accelerates it again. Needless to say, that stoppage wrecks the part, possible breaking a $20+ dollar cutting tool and generally raising all sorts of blue air in the shop when that happens. We don't need the latest whizbang hardware, but that same latency-test program, running on 64 bit hardware, has IRQ latencies in the 100-500 microseconds (unless the user is using the nvidia supplied drivers, which can expand those results into the hundreds of milliseconds range), restricts the machines top speed from 50 or more inches a minute, to under 10 inches a minute, with 5 to 7 for a safety margin under working loads. So yes, we need a 32 bit linux else it raises the cost of converting a manual machine, or a machine whose controls have died, and the maker is long gone. To illustrate, my latest build has a raspberry pi 3b doing the computing. But it also has a 65 dollar controller card which in turn needs 3 ea filter/surge absorbing cards at $45 each because the FPGA's are killed by I/O voltages above 3.4 volts, and the induced from one wire to the next voltages in a box full of stepper drivers can exceed 30 volts. I wouldn't call the raspi setup 100% usable because of the pi's I/O architecture, it runs the code just fine but drops keyboard events, so I will be investigating the rock64 board when it ships as it claims to not suffer from the I/O problems the raspi's have. But it is running a nearly 70 yo, 1500 lb Sheldon lathe right now. Hopefully the spi support it has will allow us to use the spi driver we have with little or no patching. TBD of course. I know, TL;DR, but thats my 2 cents. Thanks for asking, Felix. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org