* Re: [Xenomai] Xenomai Digest, Vol 11, Issue 55
[not found] <mailman.1.1364554801.30410.xenomai@xenomai.org>
@ 2013-04-01 12:54 ` 吴剑锋
2013-04-01 18:07 ` Gilles Chanteperdrix
0 siblings, 1 reply; 2+ messages in thread
From: 吴剑锋 @ 2013-04-01 12:54 UTC (permalink / raw)
To: xenomai
Hi
Somebody can help me how to use the rt_alarm function in xenomai native skin to make watchdog function ?
For example , we want to monitor a task and this task is use for a lot of calculation . Every calculation time is 50 ms ,so we want to check the calculation time at every Period . if the timer is longer than 50 ms, the calculation task should be forced to suspend and sent to a error signal.
So, we don’t know how to do it ?what’s meaning the “ALARM_VALUE ,ALARM_INTERVAL “ in the “usr_alarm.c” sample file ? How to setting ? maybe is there some codes to solve our issue ?
thanks very much!
nick
At 2013-03-29 19:00:01,xenomai-request@xenomai.org wrote:
>Send Xenomai mailing list submissions to
> xenomai@xenomai.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://www.xenomai.org/mailman/listinfo/xenomai
>or, via email, send a message with subject or body 'help' to
> xenomai-request@xenomai.org
>
>You can reach the person managing the list at
> xenomai-owner@xenomai.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xenomai digest..."
>
>
>Today's Topics:
>
> 1. Re: Decrease Latency (below 10 us) on x32 or x32_64?
> (Gilles Chanteperdrix)
> 2. Re: Decrease Latency (below 10 us) on x32 or x32_64?
> (Manuel Huber)
> 3. Re: Decrease Latency (below 10 us) on x32 or x32_64?
> (Gilles Chanteperdrix)
> 4. patch to src/utils/can/rtcansend.c to support data from a
> file (Daniel M. Drucker, Ph.D.)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 28 Mar 2013 13:46:05 +0100
>From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>To: Manuel Huber <manuel.h87@gmail.com>
>Cc: xenomai@xenomai.org
>Subject: Re: [Xenomai] Decrease Latency (below 10 us) on x32 or
> x32_64?
>Message-ID: <51543B8D.3000301@xenomai.org>
>Content-Type: text/plain; charset=UTF-8
>
>On 03/28/2013 11:06 AM, Manuel Huber wrote:
>
>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>
>>>> Hello!
>>>>
>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>> option for some minutes and afterwards captured the variables in
>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>> any difference.
>>>>
>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>> the trace, if you have time for it...
>>>
>>> The traces are too short. Try:
>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>
>>> There should be at least a "tick@" trace indicating the time when the
>>> timer was supposed to tick and when it did not, so that we have an idea
>>> of the latency.
>>>
>>> What is the period you use for the latency test?
>>>
>> Hello!
>>
>> Sorry, I have run the same tests again, just with back_trace_points
>> set to 1000. I've run the latency tool for 5 minutes with a period of
>> 100 us (default).
>
>
>Well, there is only one strange spot:
>:| # func -31 0.324 ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>:| # func -31+ 8.732 lapic_next_event+0x3 (ipipe_timer_set+0x77)
>:| # func -22+ 3.484 __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>:| # func -19+ 5.443 __xnlock_spin+0x9 (T.1349+0x55)
>:| # [ 1996] Xorg -1 -13 0.211 __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>
>Which would indicate that maybe the bus is busy with another core.
>But strangely the latency is around 36us as measure with the other traces.
>>From your traces, I do not see anything pathological.
>
>>
>> I don't think it's related, but xeno-test fails on the machine, and I
>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>> with a factor of 6 (as described here:
>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>
>
>And the error message is...?
>
>--
> Gilles.
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 28 Mar 2013 14:04:25 +0100
>From: Manuel Huber <manuel.h87@gmail.com>
>To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>,
> xenomai@xenomai.org
>Subject: Re: [Xenomai] Decrease Latency (below 10 us) on x32 or
> x32_64?
>Message-ID: <51543FD9.6080707@gmail.com>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>On 2013-03-28 13:46, Gilles Chanteperdrix wrote:
>> On 03/28/2013 11:06 AM, Manuel Huber wrote:
>>
>>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>>> option for some minutes and afterwards captured the variables in
>>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>>> any difference.
>>>>>
>>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>>> the trace, if you have time for it...
>>>> The traces are too short. Try:
>>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>>
>>>> There should be at least a "tick@" trace indicating the time when the
>>>> timer was supposed to tick and when it did not, so that we have an idea
>>>> of the latency.
>>>>
>>>> What is the period you use for the latency test?
>>>>
>>> Hello!
>>>
>>> Sorry, I have run the same tests again, just with back_trace_points
>>> set to 1000. I've run the latency tool for 5 minutes with a period of
>>> 100 us (default).
>>
>> Well, there is only one strange spot:
>> :| # func -31 0.324 ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>> :| # func -31+ 8.732 lapic_next_event+0x3 (ipipe_timer_set+0x77)
>> :| # func -22+ 3.484 __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>> :| # func -19+ 5.443 __xnlock_spin+0x9 (T.1349+0x55)
>> :| # [ 1996] Xorg -1 -13 0.211 __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>>
>> Which would indicate that maybe the bus is busy with another core.
>> But strangely the latency is around 36us as measure with the other traces.
>> From your traces, I do not see anything pathological.
>>
>>> I don't think it's related, but xeno-test fails on the machine, and I
>>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>>> with a factor of 6 (as described here:
>>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>>
>> And the error message is...?
>>
>Hello!
>
>> From your traces, I do not see anything pathological.
>Would you expect the timing to be better with a 64bit-Kernel? Could
>it be related to memory management overhead of the Kernel...
>
>> And the error message is...?
>Oh, sorry; The message was:
>ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
>I multiplied CONFIG_XENO_OPT_SYS_HEAPSZ and CONFIG_XENO_OPT_SYS_STACKPOOLSZ
>each by a factor of 6. The resulting values are:
>CONFIG_XENO_OPT_SYS_HEAPSZ = 1536
>CONFIG_XENO_OPT_SYS_STACKPOOLSZ = 768
>
>I got the info from an old posting you wrote and it fixed the
>problem as expected.
>
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Thu, 28 Mar 2013 21:24:34 +0100
>From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>To: Manuel Huber <manuel.h87@gmail.com>
>Cc: xenomai@xenomai.org
>Subject: Re: [Xenomai] Decrease Latency (below 10 us) on x32 or
> x32_64?
>Message-ID: <5154A702.8060307@xenomai.org>
>Content-Type: text/plain; charset=UTF-8
>
>On 03/28/2013 02:04 PM, Manuel Huber wrote:
>
>> On 2013-03-28 13:46, Gilles Chanteperdrix wrote:
>>> On 03/28/2013 11:06 AM, Manuel Huber wrote:
>>>
>>>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>>>> option for some minutes and afterwards captured the variables in
>>>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>>>> any difference.
>>>>>>
>>>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>>>> the trace, if you have time for it...
>>>>> The traces are too short. Try:
>>>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>>>
>>>>> There should be at least a "tick@" trace indicating the time when the
>>>>> timer was supposed to tick and when it did not, so that we have an idea
>>>>> of the latency.
>>>>>
>>>>> What is the period you use for the latency test?
>>>>>
>>>> Hello!
>>>>
>>>> Sorry, I have run the same tests again, just with back_trace_points
>>>> set to 1000. I've run the latency tool for 5 minutes with a period of
>>>> 100 us (default).
>>>
>>> Well, there is only one strange spot:
>>> :| # func -31 0.324 ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>>> :| # func -31+ 8.732 lapic_next_event+0x3 (ipipe_timer_set+0x77)
>>> :| # func -22+ 3.484 __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>>> :| # func -19+ 5.443 __xnlock_spin+0x9 (T.1349+0x55)
>>> :| # [ 1996] Xorg -1 -13 0.211 __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>>>
>>> Which would indicate that maybe the bus is busy with another core.
>>> But strangely the latency is around 36us as measure with the other traces.
>>> From your traces, I do not see anything pathological.
>>>
>>>> I don't think it's related, but xeno-test fails on the machine, and I
>>>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>>>> with a factor of 6 (as described here:
>>>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>>>
>>> And the error message is...?
>>>
>> Hello!
>>
>>> From your traces, I do not see anything pathological.
>> Would you expect the timing to be better with a 64bit-Kernel? Could
>> it be related to memory management overhead of the Kernel...
>
>
>You would probably have better latencies with using Xenomai on only one
>core. But 36us with the tracer on does not look so bad, does it?
>
>Did you try the configuration options I gave in the answer to your
>first mail?
>
>>
>>> And the error message is...?
>> Oh, sorry; The message was:
>> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
>> I multiplied CONFIG_XENO_OPT_SYS_HEAPSZ and CONFIG_XENO_OPT_SYS_STACKPOOLSZ
>> each by a factor of 6. The resulting values are:
>> CONFIG_XENO_OPT_SYS_HEAPSZ = 1536
>> CONFIG_XENO_OPT_SYS_STACKPOOLSZ = 768
>>
>> I got the info from an old posting you wrote and it fixed the
>> problem as expected.
>
>
>This is also documented in the TROUBLESHOOTING guide:
>http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_switchtest_fails_with_pthread_create_resource_temporarily_unavailable
>
>--
> Gilles.
>
>
>
>------------------------------
>
>Message: 4
>Date: Thu, 28 Mar 2013 18:00:53 -0400
>From: "Daniel M. Drucker, Ph.D." <dmd@interactive-motion.com>
>To: xenomai@xenomai.org
>Subject: [Xenomai] patch to src/utils/can/rtcansend.c to support data
> from a file
>Message-ID:
> <CAD1EtognG+9J_Bbo3x6AsBCJ4eU4SLrXQz=wDvJtFw0vCSZ8NQ@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>When sending a large number of CAN messages from a script (in our case, to
>initialize a servo), rtcansend can be somewhat slow because every message
>requires a setup and teardown.
>
>I added a --file flag to rtcansend which allows you to instead read bytes
>from a file (or stdin, using '-' as the filename). The file has one CAN
>message per line, in the same format (space-separated) as it would have
>been in the can-msg on the command line. Blank lines are ignored. Lines
>which start with a ' ' (space) or '#' (hash) character are ignored. If a
>filename is given, any can-msg specified on the command line is ignored.
>
>I hope this of use to someone, and it'd be really great if this could be
>merged!
>
>Thanks,
>Daniel
>
>https://gist.github.com/dmd/5267158 and inlined here:
>
>--- xenomai-2.6.2.1/src/utils/can/rtcansend.c 2013-01-22 14:37:05.000000000
>-0500
>+++ robot4/crob/rtcansendmulti.c 2013-03-28 17:47:21.436106822 -0400
>@@ -1,4 +1,5 @@
> #include <stdio.h>
>+#include <string.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <unistd.h>
>@@ -18,9 +19,10 @@
> static void print_usage(char *prg)
> {
> fprintf(stderr,
>- "Usage: %s <can-interface> [Options] <can-msg>\n"
>+ "Usage: %s <can-interface> [Options] [<can-msg>]\n"
> "<can-msg> can consist of up to 8 bytes given as a space separated
>list\n"
> "Options:\n"
>+ " -f, --file=FILENAME file to read bytes from instead of the command
>line. one list per line.\n"
> " -i, --identifier=ID CAN Identifier (default = 1)\n"
> " -r --rtr send remote request\n"
> " -e --extended send extended frame\n"
>@@ -45,7 +47,7 @@
> static nanosecs_rel_t timeout = 0;
> static struct can_frame frame;
> static struct sockaddr_can to_addr;
>-
>+const char* input_filename = NULL;
>
> void cleanup(void)
> {
>@@ -127,6 +129,7 @@
>
> struct option long_options[] = {
> { "help", no_argument, 0, 'h' },
>+ { "file", required_argument, NULL, 'f'},
> { "identifier", required_argument, 0, 'i'},
> { "rtr", no_argument, 0, 'r'},
> { "extended", no_argument, 0, 'e'},
>@@ -148,15 +151,20 @@
>
> frame.can_id = 1;
>
>- while ((opt = getopt_long(argc, argv, "hvi:l:red:t:cp:sL:",
>+ while ((opt = getopt_long(argc, argv, "hvi:l:red:t:cp:sL:f:",
> long_options, NULL)) != -1) {
> switch (opt) {
> case 'h':
> print_usage(argv[0]);
> exit(0);
>
>+ case 'f':
>+ input_filename = optarg;
>+ break;
>+
> case 'p':
> print = strtoul(optarg, NULL, 0);
>+ /* fall through */
>
> case 'v':
> verbose = 1;
>@@ -263,18 +271,6 @@
> }
> }
>
>- if (count)
>- frame.can_dlc = sizeof(int);
>- else {
>- for (i = optind + 1; i < argc; i++) {
>- frame.data[dlc] = strtoul(argv[i], NULL, 0);
>- dlc++;
>- if( dlc == 8 )
>- break;
>- }
>- frame.can_dlc = dlc;
>- }
>-
> if (rtr)
> frame.can_id |= CAN_RTR_FLAG;
>
>@@ -298,7 +294,49 @@
> goto failure;
> }
>
>- rt_task();
>+ if (input_filename != NULL) {
>+ if (!strcmp(input_filename, "-"))
>+ input_filename = "/dev/stdin";
>+
>+ FILE *file = fopen(input_filename, "r");
>+
>+ if (file != NULL) {
>+ char line [1024];
>+ while (fgets(line, sizeof line, file) != NULL) {
>+ // put the data into frame
>+ char * pch;
>+ if (line[0] == '#' || line[0] == ' ' || line[0] == '\n') continue;
>+ pch = strtok(line, " ");
>+ dlc = 0;
>+ while ((pch != NULL) && (dlc < 8)) {
>+ frame.data[dlc] = strtoul(pch, NULL, 0);
>+ pch = strtok(NULL, " ");
>+ dlc++;
>+ }
>+ frame.can_dlc = dlc;
>+ rt_task();
>+ }
>+ fclose(file);
>+ }
>+ else {
>+ perror(input_filename);
>+ goto failure;
>+ }
>+ }
>+ else {
>+ if (count)
>+ frame.can_dlc = sizeof(int);
>+ else {
>+ for (i = optind + 1; i < argc; i++) {
>+ frame.data[dlc] = strtoul(argv[i], NULL, 0);
>+ dlc++;
>+ if( dlc == 8 )
>+ break;
>+ }
>+ frame.can_dlc = dlc;
>+ }
>+ rt_task();
>+ }
>
> cleanup();
> return 0;
>
>
>------------------------------
>
>_______________________________________________
>Xenomai mailing list
>Xenomai@xenomai.org
>http://www.xenomai.org/mailman/listinfo/xenomai
>
>
>End of Xenomai Digest, Vol 11, Issue 55
>***************************************
^ permalink raw reply [flat|nested] 2+ messages in thread