Janek Stolarek wrote:
Ha! Thanks! I wasn't aware there are ARM builds already - I
That's from Apr '16. For Raspbian Buster Lite (https://www.raspberrypi.org/downloads/raspbian/) you'd need Preliminary Stable Builds (https://wiki.trinitydesktop.org/Preliminary_Stable_Builds, http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-sb/dists/). I'm not sure the specifics, but something like:
1) Add the Debian Trinity Repository sources (2 lines) deb http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-sb raspbian-buster deps-r14 main-r14 deb-src http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-sb raspbian-buster deps-r14 main-r14
2) Add the GPG signing key wget http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-keyring.deb sudo dpkg -i trinity-keyring.deb
I confirm it works, I have it running here (on pi 3 however). I'm interrested to know wht you think of it once it's running. I've got pi 3B+ and an "Up Board" that runs an Atom CPU and, while both can be used, I would not call them "fully-fledged desktop PC" - at least not when you compare to an AMD Ryzen...
Thierry
I would not call them "fully-fledged desktop PC" - at least not when you compare to an AMD Ryzen...
Obviously, Pi is no match for a standard PC when it comes to things like gaming*, video and photo editing, etc. But it is now powerful enough to carry out many daily office tasks and even support two monitor setups. You might want to take a look at MagPi magazine, issue #85 - there's an interesting article that details a week of experience of using a Pi as a desktop at work.
*) However, I have setup Lakka on my Pi and it emulates 16 bit consoles and arcades (and even some 32-bit ones) without problems.
Janek
On Wednesday 25 December 2019 21.54:19 Janek Stolarek wrote:
*) However, I have setup Lakka on my Pi and it emulates 16 bit consoles and arcades (and even some 32-bit ones) without problems.
Janek
The main problem I have with "old"* games is resolution - games written for 640x480 on a big 1920x1080 screen...
Thierry
I say "old" because I still like many more than modern stuff. Sometimes find myself playing lemmings or Wolfenstein 3D :)
Anno domini 2019 Wed, 25 Dec 20:53:09 +0100 Thierry de Coulon scripsit:
I confirm it works, I have it running here (on pi 3 however). I'm interrested to know wht you think of it once it's running. I've got pi 3B+ and an "Up Board" that runs an Atom CPU and, while both can be used, I would not call them "fully-fledged desktop PC" - at least not when you compare to an AMD Ryzen...
I've one running a mill. Gene has some in duty, too, so it's definitly working for maschinists :)
Nik
Thierry
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thursday 26 December 2019 03:40:34 Dr. Nikolaus Klepp wrote:
Anno domini 2019 Wed, 25 Dec 20:53:09 +0100
Thierry de Coulon scripsit:
I confirm it works, I have it running here (on pi 3 however). I'm interrested to know wht you think of it once it's running. I've got pi 3B+ and an "Up Board" that runs an Atom CPU and, while both can be used, I would not call them "fully-fledged desktop PC" - at least not when you compare to an AMD Ryzen...
I've one running a mill. Gene has some in duty, too, so it's definitly working for maschinists :)
Nik
I've switched to an rpi4 on the 11x54 Sheldon lathe and its running with computing power to spare.
I've a couple SSD's on the rpi4 with its new found USB-3 interfaces. And for the curious, the uspace build can be downloaded from my web site. All built on the rpi4.
That will all install on a raspbian buster 10.2 install, which is still an armhf build. Better latencies are from the hf build. The debian buster is now an arm64 build.
Get the preempt-realtime kernel, with about 30x faster video, and the debs to install LinuxCNC from:
http://geneslinuxbox.net:6309/gene/lathe-stf/linuxcnc4pi4b
Working flawlessly with a Mesa 7i90hd interface card, buffered by 3 each 7i42TA's. Should also work with the newer 7C8X ethernet based cards.
Thierry
- To unsubscribe, e-mail:
trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Thursday 26 December 2019 05:24:06 am Gene Heskett wrote:
preempt-realtime kernel
Hi Gene,
You've mentioned realtime kernel before as being faster(/better?), do you have a goto link/article that explains it for a mostly uninformed about kernel person?
I can search this, but with the amount of bias/wrong/propaganda you end up with now from google searches, I figured I’d ask someone who actually knows…
Thanks, Michael
On Thursday 26 December 2019 10:30:39 Michael wrote:
On Thursday 26 December 2019 05:24:06 am Gene Heskett wrote:
preempt-realtime kernel
Hi Gene,
You've mentioned realtime kernel before as being faster(/better?), do you have a goto link/article that explains it for a mostly uninformed about kernel person?
If you install the kernel src debs, you can do a make menuconfig, which will allow you access to the kernels fine tuning, and one of the option buried in the menu's is to turn on a config option call preempt-rt or preempt-realtime. This changes the IRQ handling to make the IRQ's be handled much quicker at the expense of making other stuff wait a few microseconds.
There are other, even better ways to do this but this one disturbs the rest of the system less, and it puts those operations in the users workspace. All other methods become a portion of the kernel wom
I can search this, but with the amount of bias/wrong/propaganda you end up with now from google searches, I figured I’d ask someone who actually knows…
The confusion reigns heavily because the rt developer group is actually 2 or 3 parallel projects. All of which are working on getting the version of the code they are working on good enough to become the core the default build is based on. I am not an expert, I simply git clone a version and if it works we've a winner, if not, tag a newer one and try again. Development is moving at breakneck speeds
Thanks, Michael
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
Anno domini 2019 Thu, 26 Dec 15:08:41 -0500 Gene Heskett scripsit:
On Thursday 26 December 2019 10:30:39 Michael wrote:
On Thursday 26 December 2019 05:24:06 am Gene Heskett wrote:
preempt-realtime kernel
Hi Gene,
You've mentioned realtime kernel before as being faster(/better?), do you have a goto link/article that explains it for a mostly uninformed about kernel person?
If you install the kernel src debs, you can do a make menuconfig, which will allow you access to the kernels fine tuning, and one of the option buried in the menu's is to turn on a config option call preempt-rt or preempt-realtime. This changes the IRQ handling to make the IRQ's be handled much quicker at the expense of making other stuff wait a few microseconds.
One should also mention, that for a normal user a realtime kernel is a bad idea, the GUI will not perform better.
There are other, even better ways to do this but this one disturbs the rest of the system less, and it puts those operations in the users workspace. All other methods become a portion of the kernel wom
I can search this, but with the amount of bias/wrong/propaganda you end up with now from google searches, I figured I’d ask someone who actually knows…
The confusion reigns heavily because the rt developer group is actually 2 or 3 parallel projects. All of which are working on getting the version of the code they are working on good enough to become the core the default build is based on. I am not an expert, I simply git clone a version and if it works we've a winner, if not, tag a newer one and try again. Development is moving at breakneck speeds
And then there is RTAI, which gives a latrency of ~ 1/5th to 1/10th of RT-PREEMPT. But it does not work on ARM :(
Nik
Thanks, Michael
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Thursday 26 December 2019 15:23:11 Dr. Nikolaus Klepp wrote:
Anno domini 2019 Thu, 26 Dec 15:08:41 -0500
Gene Heskett scripsit:
On Thursday 26 December 2019 10:30:39 Michael wrote:
On Thursday 26 December 2019 05:24:06 am Gene Heskett wrote:
preempt-realtime kernel
Hi Gene,
You've mentioned realtime kernel before as being faster(/better?), do you have a goto link/article that explains it for a mostly uninformed about kernel person?
If you install the kernel src debs, you can do a make menuconfig, which will allow you access to the kernels fine tuning, and one of the option buried in the menu's is to turn on a config option call preempt-rt or preempt-realtime. This changes the IRQ handling to make the IRQ's be handled much quicker at the expense of making other stuff wait a few microseconds.
One should also mention, that for a normal user a realtime kernel is a bad idea, the GUI will not perform better.
That is highly dependant on the kernel. At the present time, the version I built is about 25 fps faster than the raspbian kernel it replaces. And even that is an older build.
There are other, even better ways to do this but this one disturbs the rest of the system less, and it puts those operations in the users workspace. All other methods become a portion of the kernel wom
I can search this, but with the amount of bias/wrong/propaganda you end up with now from google searches, I figured I’d ask someone who actually knows…
The confusion reigns heavily because the rt developer group is actually 2 or 3 parallel projects. All of which are working on getting the version of the code they are working on good enough to become the core the default build is based on. I am not an expert, I simply git clone a version and if it works we've a winner, if not, tag a newer one and try again. Development is moving at breakneck speeds
And then there is RTAI, which gives a latrency of ~ 1/5th to 1/10th of RT-PREEMPT. But it does not work on ARM :(
Its my understanding that it is being worked on. But I've been in the shop getting my ticker rebuilt too, and this computer had a fire and had to be rebuilt with a new mobo, cpu and memory, which occupied my time between visits to the cath-lab, so I'm not exactly uptodate on that. Couple months out of date, or more, I had the heart attack in late Sept. Theoreticly fixed now, and I feel better than a year ago. So you, Nik, are likely quite a bit closer to current than I. Please fill these folks in where I blew it.
Nik
Thanks, Michael
--- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
Cheers, Gene Heskett
On Thursday 26 December 2019 03:15:28 pm Gene Heskett wrote:
On Thursday 26 December 2019 15:23:11 Dr. Nikolaus Klepp wrote:
Anno domini 2019 Thu, 26 Dec 15:08:41 -0500 Gene Heskett scripsit:
On Thursday 26 December 2019 10:30:39 Michael wrote:
On Thursday 26 December 2019 05:24:06 am Gene Heskett wrote:
preempt-realtime kernel
You've mentioned realtime kernel before as being faster(/better?), do you have a goto link/article that explains it for a mostly uninformed about kernel person?
If you install the kernel src debs, you can do a make menuconfig, which will allow you access to the kernels fine tuning, and one of the option buried in the menu's is to turn on a config option call preempt-rt or preempt-realtime. This changes the IRQ handling to make the IRQ's be handled much quicker at the expense of making other stuff wait a few microseconds.
One should also mention, that for a normal user a realtime kernel is a bad idea, the GUI will not perform better.
That is highly dependant on the kernel. At the present time, the version I built is about 25 fps faster than the raspbian kernel it replaces. And even that is an older build.
Real world, I’d be considering this for a Web server. They are a minimum/bare install with LAMP (e.g. no GUI). A fairly standard page display is 100 - 200 total requests spanning multiple seconds. So I guess I’m wondering if this would shave a bit off each request (though faster talking with NIC/disk/etc.)?
Anno domini 2019 Thu, 26 Dec 16:21:48 -0600 Michael scripsit:
On Thursday 26 December 2019 03:15:28 pm Gene Heskett wrote:
On Thursday 26 December 2019 15:23:11 Dr. Nikolaus Klepp wrote:
Anno domini 2019 Thu, 26 Dec 15:08:41 -0500 Gene Heskett scripsit:
On Thursday 26 December 2019 10:30:39 Michael wrote:
On Thursday 26 December 2019 05:24:06 am Gene Heskett wrote:
preempt-realtime kernel
You've mentioned realtime kernel before as being faster(/better?), do you have a goto link/article that explains it for a mostly uninformed about kernel person?
If you install the kernel src debs, you can do a make menuconfig, which will allow you access to the kernels fine tuning, and one of the option buried in the menu's is to turn on a config option call preempt-rt or preempt-realtime. This changes the IRQ handling to make the IRQ's be handled much quicker at the expense of making other stuff wait a few microseconds.
One should also mention, that for a normal user a realtime kernel is a bad idea, the GUI will not perform better.
That is highly dependant on the kernel. At the present time, the version I built is about 25 fps faster than the raspbian kernel it replaces. And even that is an older build.
Real world, I’d be considering this for a Web server. They are a minimum/bare install with LAMP (e.g. no GUI). A fairly standard page display is 100 - 200 total requests spanning multiple seconds. So I guess I’m wondering if this would shave a bit off each request (though faster talking with NIC/disk/etc.)?
Test it.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Michael wrote:
Real world, I’d be considering this for a Web server. They are a minimum/bare install with LAMP (e.g. no GUI). A fairly standard page display is 100 - 200 total requests spanning multiple seconds. So I guess I’m wondering if this would shave a bit off each request (though faster talking with NIC/disk/etc.)?
What does TDE have to do with it? Then mark it OT, please.
On Wednesday 25 of December 2019 20:27:03 Dave Lers wrote:
Janek Stolarek wrote:
Ha! Thanks! I wasn't aware there are ARM builds already - I
That's from Apr '16. For Raspbian Buster Lite (https://www.raspberrypi.org/downloads/raspbian/) you'd need Preliminary Stable Builds (https://wiki.trinitydesktop.org/Preliminary_Stable_Builds, http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-sb/dists/). I'm not sure the specifics, but something like:
- Add the Debian Trinity Repository sources (2 lines)
deb http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-sb raspbian-buster deps-r14 main-r14 deb-src http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-sb raspbian-buster deps-r14 main-r14
- Add the GPG signing key
wget http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-keyring.deb sudo dpkg -i trinity-keyring.deb
For your information, along with the release of R14.0.7, the official stable release packages are now also available for raspbian-stretch and raspbian-buster. If you don't want frequent updates of Trinity packages, you can switch from Preliminary Stable Builds to official release.
Cheers
-
Dave Lers -
deloptes -
Dr. Nikolaus Klepp -
Gene Heskett -
Janek Stolarek -
Michael -
Slávek Banko -
Thierry de Coulon