Re: [beagleboard] Re: Real Time experience on Beagle?
Thank you very much. Those findings are very interesting and the videos make it easy to see the difference. On Wed, Oct 23, 2019 at 2:29 PM Shabaz Yousaf wrote: > > Hi Drew, > > Without the real time kernel, I didn't need to put any additional load and I > could see the jitter was large (on x86 in a VM). As soon as I did any > activity such as just open another terminal, the jitter shot even higher, so > I didn't deliberately add any further load, since it was clear I couldn't do > much machine control in this manner. > > I've just now repeated with BBB, and recorded a couple of videos (each video > is less than 2Mbyte, MP4 file). They are here to download: > https://app.box.com/s/hcax6malowe43ctxdg1x64r83yruklyg > > In the no-xenomai-gcc.mp4 video, you can see that I ran the cyclic test which > shows the Min/Actual(i.e. current)/Avg/Max latency values in usec. > I ran gcc as a real-world load. You can see that the latency shoots up to 591 > usec, i.e. jitter is higher than 500 usec. > > In the with-xenomai-gcc.mp4 file, I repeat things, but this time using a > cyclic test which is xenomai-enabled. > The video shows that the latency during the gcc load didn't exceed 62 usec, > so almost 10 times better : ) > > There's a third video there too, titled stress-xenomai.mp4. In that, I ran a > stress command, and also displayed the processes and top. Afterwards, I > stopped the cyclic test and you can see the difference in 'top' output too. > I don't know how useful this video is, because I don't know how good that > stress command is. I copied that command from some Pi stress-test document. > > Thanks, > > Shabaz. > > > > ____ > From: beagleboard@googlegroups.com on behalf > of Drew Fustini > Sent: 23 October 2019 11:53 > To: Beagle Board > Subject: Re: [beagleboard] Re: Real Time experience on Beagle? > > On Tue, Oct 15, 2019 at 6:16 PM shabaz wrote: > > By the way, > > > > I've put an oscilloscope trace of a Xenomai'd program on the BBB here in > > case you'd like to show it for your presentation: > > https://app.box.com/s/nfwlud613c7zoz7gu6rn9arfttticvvc > > > > For that trace, the BBB is just toggling a GPIO pin repeatedly, in a > > Xenomai'd thread. I left it running for several minutes and the statistics > > that were collected are at the bottom of the screenshot. > > The delta between the Max (66.34 usec) and Min (60.76 usec) values > > indicates that jitter was under 6 usec. > > Thanks very much for these instructions and your results. I will give a try. > > Did you run anything to put load on the system while you were collecting > stats? > > thanks, > drew > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAEf4M_CxW3m1QVennDZz%2Bu_fpUbxjDdOsi1Tt0DEur1td70dLw%40mail.gmail.com. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/DB6P18901MB0214F24846A34FD0CB0B9B9E846B0%40DB6P18901MB0214.EURP189.PROD.OUTLOOK.COM. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAEf4M_Bb4cMErXCPjrr1%3DYsCS2UgcFamk%3DVCSj%2BFxfmD6aPvXA%40mail.gmail.com.
Re: [beagleboard] Re: Real Time experience on Beagle?
Hi Drew, Without the real time kernel, I didn't need to put any additional load and I could see the jitter was large (on x86 in a VM). As soon as I did any activity such as just open another terminal, the jitter shot even higher, so I didn't deliberately add any further load, since it was clear I couldn't do much machine control in this manner. I've just now repeated with BBB, and recorded a couple of videos (each video is less than 2Mbyte, MP4 file). They are here to download: https://app.box.com/s/hcax6malowe43ctxdg1x64r83yruklyg In the no-xenomai-gcc.mp4 video, you can see that I ran the cyclic test which shows the Min/Actual(i.e. current)/Avg/Max latency values in usec. I ran gcc as a real-world load. You can see that the latency shoots up to 591 usec, i.e. jitter is higher than 500 usec. In the with-xenomai-gcc.mp4 file, I repeat things, but this time using a cyclic test which is xenomai-enabled. The video shows that the latency during the gcc load didn't exceed 62 usec, so almost 10 times better : ) There's a third video there too, titled stress-xenomai.mp4. In that, I ran a stress command, and also displayed the processes and top. Afterwards, I stopped the cyclic test and you can see the difference in 'top' output too. I don't know how useful this video is, because I don't know how good that stress command is. I copied that command from some Pi stress-test document. Thanks, Shabaz. From: beagleboard@googlegroups.com on behalf of Drew Fustini Sent: 23 October 2019 11:53 To: Beagle Board Subject: Re: [beagleboard] Re: Real Time experience on Beagle? On Tue, Oct 15, 2019 at 6:16 PM shabaz wrote: > By the way, > > I've put an oscilloscope trace of a Xenomai'd program on the BBB here in case > you'd like to show it for your presentation: > https://app.box.com/s/nfwlud613c7zoz7gu6rn9arfttticvvc > > For that trace, the BBB is just toggling a GPIO pin repeatedly, in a > Xenomai'd thread. I left it running for several minutes and the statistics > that were collected are at the bottom of the screenshot. > The delta between the Max (66.34 usec) and Min (60.76 usec) values indicates > that jitter was under 6 usec. Thanks very much for these instructions and your results. I will give a try. Did you run anything to put load on the system while you were collecting stats? thanks, drew -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAEf4M_CxW3m1QVennDZz%2Bu_fpUbxjDdOsi1Tt0DEur1td70dLw%40mail.gmail.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/DB6P18901MB0214F24846A34FD0CB0B9B9E846B0%40DB6P18901MB0214.EURP189.PROD.OUTLOOK.COM.
Re: [beagleboard] Re: Real Time experience on Beagle?
On Tue, Oct 15, 2019 at 6:16 PM shabaz wrote: > By the way, > > I've put an oscilloscope trace of a Xenomai'd program on the BBB here in case > you'd like to show it for your presentation: > https://app.box.com/s/nfwlud613c7zoz7gu6rn9arfttticvvc > > For that trace, the BBB is just toggling a GPIO pin repeatedly, in a > Xenomai'd thread. I left it running for several minutes and the statistics > that were collected are at the bottom of the screenshot. > The delta between the Max (66.34 usec) and Min (60.76 usec) values indicates > that jitter was under 6 usec. Thanks very much for these instructions and your results. I will give a try. Did you run anything to put load on the system while you were collecting stats? thanks, drew -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAEf4M_CxW3m1QVennDZz%2Bu_fpUbxjDdOsi1Tt0DEur1td70dLw%40mail.gmail.com.
Re: [beagleboard] Re: Real Time experience on Beagle?
Thanks for that! : )
I'm terrible at makefiles : )
On Tuesday, October 15, 2019 at 4:28:06 PM UTC+1, wharms wrote:
>
>
>
> Am 15.10.2019 16:06, schrieb shabaz:
> > Hi Drew,
> >
> > I hope you're well!
> >
> > I recently experimented briefly with both, here' s the steps I used to
> > install Xenomai (Rob Nelson helped me find the pre-built kernel, the
> link
> > to them is below).
> > Not all Xenomai APIs are enabled in the kernel. Anyway, I did get
> reduced
> > jitter when using one of the API sets called Alchemy, which I guess is
> > probably the easiest to code with. In a nutshell you can use the API to
> > create a task thread, and do your low-latency stuff there.
> >
> > For my experiment, I used this content in my makefile:
> >
> > XENO_CONFIG := /usr/xenomai/bin/xeno-config
> >
> > CFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --cflags)
> > LDFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --ldflags)
> >
>
> You can simplify your life just use:
>
> atest:
>
> clean:
> rm -f atest
>
>
> the %: %.c stuff is a build in rule CC should be a default
> to you local compiler.
>
> jm2c,
>
> re,
> wh
>
> > CC := gcc
> > EXECUTABLE := atest
> >
> > all: $(EXECUTABLE)
> >
> > %: %.c
> > $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
> >
> > clean:
> > rm -f $(EXECUTABLE)
> >
>
>
> > and, code needs to look like this:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > RT_TASK hello_task;
> >
> > // function to be executed by task
> > // this is your stuff for which you want low jitter
> > void helloWorld(void *arg)
> > {
> > RT_TASK_INFO curtaskinfo;
> > printf("Hello World!\n");
> >
> > // inquire current task
> > rt_task_inquire(NULL,);
> >
> > // print task name
> > printf("Task name : %s \n", curtaskinfo.name);
> >
> > while(1)
> > {
> > // do your stuff here in a forever loop if you like
> >
> > // use this sleep command if you need to use any sleep. This sleep
> has
> > low jitter:
> > rt_task_sleep(5);
> > }
> >
> > }
> >
> > int main(int argc, char* argv[])
> > {
> > char str[10];
> >
> > printf("start task\n");
> > sprintf(str,"hello");
> >
> > /* Create task
> >* Arguments: ,
> >*name,
> >*stack size (0=default),
> >*priority,
> >*mode (FPU, start suspended, ...)
> >*/
> > rt_task_create(_task, str, 0, 99, 0);
> >
> > /* Start task
> >* Arguments: ,
> >*task function,
> >*function argument
> >*/
> > rt_task_start(_task, , 0);
> > while(1)
> > {
> > sleep(10);
> > }
> > }
> >
> > To test latency I ran this:
> > cyclictest -n -p 90 -i 1000
> > and the result was:
> > T: 0 ( 2914) P:90 I:1000 C: 31719 Min: 6 Act: 19 Avg: 18 Max:
>
> > 51
> > which was about ten times lower for the Max value, compared to PREEMPT
> RT.
> > And it was far lower than x86 Linux running a standard kernel with
> Ubuntu.
> > The x86 Linux was a virtual machine on ESXi on an Intel NUC.
> > It was all over the place with that - especially if I tried opening
> another
> > terminal to do something. With Xenomai, it was stable.
> > In summary, provided one is willing to code for Xenomai, then the jitter
> > difference is large - still no-where as good as PRU or a microcontroller
> of
> > course, but fantastic for Linux.
> > Also, it seems that the pre-built Machinekit images use PREMPT RT, not
> > Xenomai : ( I've no idea if Machinekit is coded to support Xenomai, I've
> > not really investigated too far currently.
> >
> > Installing pre-built Xenomi kernel:
> >
> >
> > https://github.com/beagleboard/linux/releases
> >
> >
> >
> > cd /opt/scripts/tools/
> >
> > git pull
> >
> > As root user:
> >
> > ./update_kernel.sh --ti-xenomai-channel --lts-4_14
> >
> >
> >
> > as non-root user:
> >
> > cd development
> >
> > mkdir xenomi
> >
> > cd xenomi
> >
> > wget
> >
> https://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.9.tar.bz2
> >
> > bunzip2 xenomai-3.0.9.tar.bz2
> >
> > tar xvf xenomai-3.0.9.tar
> >
> > cd xenomai-3.0.9
> >
> > ./configure --enable-smp CFLAGS="-march=armv7-a -mfpu=vfp3"
> > LDFLAGS="-march=armv7-a -mfpu=vfp3"
> >
> > make
> >
> > As root user:
> >
> > make install
> >
> >
> >
> > Testing it:
> >
> > /usr/xenomai/bin/xeno-test
> >
> >
> >
> >
> >
> >
> > Development/xtest
> >
> > make -f Mafefile-a
> >
> > as root user:
> >
> > export LD_LIBRARY_PATH=/usr/lib:/usr/xenomai/lib
> >
> > ./atest
> >
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Re: [beagleboard] Re: Real Time experience on Beagle?
Can you use bela (https://bela.io/about) ?
On Tue, Oct 15, 2019 at 4:28 PM walter harms wrote:
>
>
> Am 15.10.2019 16:06, schrieb shabaz:
> > Hi Drew,
> >
> > I hope you're well!
> >
> > I recently experimented briefly with both, here' s the steps I used to
> > install Xenomai (Rob Nelson helped me find the pre-built kernel, the
> link
> > to them is below).
> > Not all Xenomai APIs are enabled in the kernel. Anyway, I did get
> reduced
> > jitter when using one of the API sets called Alchemy, which I guess is
> > probably the easiest to code with. In a nutshell you can use the API to
> > create a task thread, and do your low-latency stuff there.
> >
> > For my experiment, I used this content in my makefile:
> >
> > XENO_CONFIG := /usr/xenomai/bin/xeno-config
> >
> > CFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --cflags)
> > LDFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --ldflags)
> >
>
> You can simplify your life just use:
>
> atest:
>
> clean:
> rm -f atest
>
>
> the %: %.c stuff is a build in rule CC should be a default
> to you local compiler.
>
> jm2c,
>
> re,
> wh
>
> > CC := gcc
> > EXECUTABLE := atest
> >
> > all: $(EXECUTABLE)
> >
> > %: %.c
> > $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
> >
> > clean:
> > rm -f $(EXECUTABLE)
> >
>
>
> > and, code needs to look like this:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > RT_TASK hello_task;
> >
> > // function to be executed by task
> > // this is your stuff for which you want low jitter
> > void helloWorld(void *arg)
> > {
> > RT_TASK_INFO curtaskinfo;
> > printf("Hello World!\n");
> >
> > // inquire current task
> > rt_task_inquire(NULL,);
> >
> > // print task name
> > printf("Task name : %s \n", curtaskinfo.name);
> >
> > while(1)
> > {
> > // do your stuff here in a forever loop if you like
> >
> > // use this sleep command if you need to use any sleep. This sleep
> has
> > low jitter:
> > rt_task_sleep(5);
> > }
> >
> > }
> >
> > int main(int argc, char* argv[])
> > {
> > char str[10];
> >
> > printf("start task\n");
> > sprintf(str,"hello");
> >
> > /* Create task
> >* Arguments: ,
> >*name,
> >*stack size (0=default),
> >*priority,
> >*mode (FPU, start suspended, ...)
> >*/
> > rt_task_create(_task, str, 0, 99, 0);
> >
> > /* Start task
> >* Arguments: ,
> >*task function,
> >*function argument
> >*/
> > rt_task_start(_task, , 0);
> > while(1)
> > {
> > sleep(10);
> > }
> > }
> >
> > To test latency I ran this:
> > cyclictest -n -p 90 -i 1000
> > and the result was:
> > T: 0 ( 2914) P:90 I:1000 C: 31719 Min: 6 Act: 19 Avg: 18 Max:
>
> > 51
> > which was about ten times lower for the Max value, compared to PREEMPT
> RT.
> > And it was far lower than x86 Linux running a standard kernel with
> Ubuntu.
> > The x86 Linux was a virtual machine on ESXi on an Intel NUC.
> > It was all over the place with that - especially if I tried opening
> another
> > terminal to do something. With Xenomai, it was stable.
> > In summary, provided one is willing to code for Xenomai, then the jitter
> > difference is large - still no-where as good as PRU or a microcontroller
> of
> > course, but fantastic for Linux.
> > Also, it seems that the pre-built Machinekit images use PREMPT RT, not
> > Xenomai : ( I've no idea if Machinekit is coded to support Xenomai, I've
> > not really investigated too far currently.
> >
> > Installing pre-built Xenomi kernel:
> >
> >
> > https://github.com/beagleboard/linux/releases
> >
> >
> >
> > cd /opt/scripts/tools/
> >
> > git pull
> >
> > As root user:
> >
> > ./update_kernel.sh --ti-xenomai-channel --lts-4_14
> >
> >
> >
> > as non-root user:
> >
> > cd development
> >
> > mkdir xenomi
> >
> > cd xenomi
> >
> > wget
> >
> https://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.9.tar.bz2
> >
> > bunzip2 xenomai-3.0.9.tar.bz2
> >
> > tar xvf xenomai-3.0.9.tar
> >
> > cd xenomai-3.0.9
> >
> > ./configure --enable-smp CFLAGS="-march=armv7-a -mfpu=vfp3"
> > LDFLAGS="-march=armv7-a -mfpu=vfp3"
> >
> > make
> >
> > As root user:
> >
> > make install
> >
> >
> >
> > Testing it:
> >
> > /usr/xenomai/bin/xeno-test
> >
> >
> >
> >
> >
> >
> > Development/xtest
> >
> > make -f Mafefile-a
> >
> > as root user:
> >
> > export LD_LIBRARY_PATH=/usr/lib:/usr/xenomai/lib
> >
> > ./atest
> >
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5DA5E576.8090602%40bfs.de.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this
Re: [beagleboard] Re: Real Time experience on Beagle?
Am 15.10.2019 16:06, schrieb shabaz:
> Hi Drew,
>
> I hope you're well!
>
> I recently experimented briefly with both, here' s the steps I used to
> install Xenomai (Rob Nelson helped me find the pre-built kernel, the link
> to them is below).
> Not all Xenomai APIs are enabled in the kernel. Anyway, I did get reduced
> jitter when using one of the API sets called Alchemy, which I guess is
> probably the easiest to code with. In a nutshell you can use the API to
> create a task thread, and do your low-latency stuff there.
>
> For my experiment, I used this content in my makefile:
>
> XENO_CONFIG := /usr/xenomai/bin/xeno-config
>
> CFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --cflags)
> LDFLAGS := $(shell $(XENO_CONFIG) --posix --alchemy --ldflags)
>
You can simplify your life just use:
atest:
clean:
rm -f atest
the %: %.c stuff is a build in rule CC should be a default
to you local compiler.
jm2c,
re,
wh
> CC := gcc
> EXECUTABLE := atest
>
> all: $(EXECUTABLE)
>
> %: %.c
> $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
>
> clean:
> rm -f $(EXECUTABLE)
>
> and, code needs to look like this:
>
> #include
> #include
> #include
> #include
> #include
>
> RT_TASK hello_task;
>
> // function to be executed by task
> // this is your stuff for which you want low jitter
> void helloWorld(void *arg)
> {
> RT_TASK_INFO curtaskinfo;
> printf("Hello World!\n");
>
> // inquire current task
> rt_task_inquire(NULL,);
>
> // print task name
> printf("Task name : %s \n", curtaskinfo.name);
>
> while(1)
> {
> // do your stuff here in a forever loop if you like
>
> // use this sleep command if you need to use any sleep. This sleep has
> low jitter:
> rt_task_sleep(5);
> }
>
> }
>
> int main(int argc, char* argv[])
> {
> char str[10];
>
> printf("start task\n");
> sprintf(str,"hello");
>
> /* Create task
>* Arguments: ,
>*name,
>*stack size (0=default),
>*priority,
>*mode (FPU, start suspended, ...)
>*/
> rt_task_create(_task, str, 0, 99, 0);
>
> /* Start task
>* Arguments: ,
>*task function,
>*function argument
>*/
> rt_task_start(_task, , 0);
> while(1)
> {
> sleep(10);
> }
> }
>
> To test latency I ran this:
> cyclictest -n -p 90 -i 1000
> and the result was:
> T: 0 ( 2914) P:90 I:1000 C: 31719 Min: 6 Act: 19 Avg: 18 Max:
> 51
> which was about ten times lower for the Max value, compared to PREEMPT RT.
> And it was far lower than x86 Linux running a standard kernel with Ubuntu.
> The x86 Linux was a virtual machine on ESXi on an Intel NUC.
> It was all over the place with that - especially if I tried opening another
> terminal to do something. With Xenomai, it was stable.
> In summary, provided one is willing to code for Xenomai, then the jitter
> difference is large - still no-where as good as PRU or a microcontroller of
> course, but fantastic for Linux.
> Also, it seems that the pre-built Machinekit images use PREMPT RT, not
> Xenomai : ( I've no idea if Machinekit is coded to support Xenomai, I've
> not really investigated too far currently.
>
> Installing pre-built Xenomi kernel:
>
>
> https://github.com/beagleboard/linux/releases
>
>
>
> cd /opt/scripts/tools/
>
> git pull
>
> As root user:
>
> ./update_kernel.sh --ti-xenomai-channel --lts-4_14
>
>
>
> as non-root user:
>
> cd development
>
> mkdir xenomi
>
> cd xenomi
>
> wget
> https://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.9.tar.bz2
>
> bunzip2 xenomai-3.0.9.tar.bz2
>
> tar xvf xenomai-3.0.9.tar
>
> cd xenomai-3.0.9
>
> ./configure --enable-smp CFLAGS="-march=armv7-a -mfpu=vfp3"
> LDFLAGS="-march=armv7-a -mfpu=vfp3"
>
> make
>
> As root user:
>
> make install
>
>
>
> Testing it:
>
> /usr/xenomai/bin/xeno-test
>
>
>
>
>
>
> Development/xtest
>
> make -f Mafefile-a
>
> as root user:
>
> export LD_LIBRARY_PATH=/usr/lib:/usr/xenomai/lib
>
> ./atest
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/5DA5E576.8090602%40bfs.de.
