Mailinglist Archive: opensuse-factory (649 mails)

< Previous Next >
Re: [opensuse-factory] Tumbleweed 32-bit roadmap?
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >