Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 01/21/2013 03:42 PM, Jens Köhler wrote: > Hi Gilles, > >> Using a Linux semaphore causes a switch to secondary mode, which means >> potentially unbounded latencies. > > Yes, I have no problem with the secondary mode. I have only the > problem that linux kernel not restarts sleeping task as fast as > expected. Instead 3 ms -> 50 ms. And it happens only when a linux > semaphore is in use. Do you have an idea why this happens and how to > find reason? If this issue is not due to xenomai, then the xenomai mailing list may not be the best place to ask. > > > >> Please keep the list in CC. > What means CC ? Carbon Copy -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 01/21/2013 01:06 PM, Jens Köhler wrote: > Hello Gilles, > > I did not understand your latests statement. What do you mean with "If > you expect a task using a Linux semaphore to have bounded latencies, > you misunderstood the way Xenomai works." > > Do you think it should work without problems, without delays, latencies? > Do you know if someone has already used linux semaphores in a xenomai thread? > What do you recommend to find reason and a solution? Using a Linux semaphore causes a switch to secondary mode, which means potentially unbounded latencies. Please keep the list in CC. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
Hi, > If you expect a task using a Linux semaphore to have bounded latencies, > you misunderstood the way Xenomai works. I have not so a deep knowledge about linux semaphores and xenomai. A linux semaphore controls access to a linux shared memory. The Xenomai task is the only task which writes to shared memory. Several linux applications reading from shared memory. The task of semaphore is to prevent that during data reading the Xenomai task could write to shared memory. I understand Xenomai has highest priority. What does xenomai/ linux when xenomai task tries to write to shared memory, but semaphore blocks writing? best regards, Jens ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 12/03/2012 08:59 AM, Jens Köhler wrote: > Hello, > > I found following additionaly out: > One of the Xenomai tasks writes cyclically to a shared linux memory > (its not a Xenomai shared memory). Write and read access is controlled > by Linux semaphores. If shared memory writing is out-commented is > there never a delay problem. If you expect a task using a Linux semaphore to have bounded latencies, you misunderstood the way Xenomai works. > > I found following explanation about Xenomai in internet. Could it > reason for problem? > > "If an interrupt arrives while a Xenomai thread executes in secondary > mode, it is not forwarded to Linux! The mechanism works as follows: > When a Xenomai thread is executed in secondary mode, the interrupt > shield domain is activated All Linux interrupts are stalled, until the > Xenomai thread completes execution. The interrupts will be served > again when Linux goes back to execute in background mode." The interrupt shield no longer exists. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
Hello, I found following additionaly out: One of the Xenomai tasks writes cyclically to a shared linux memory (its not a Xenomai shared memory). Write and read access is controlled by Linux semaphores. If shared memory writing is out-commented is there never a delay problem. I found following explanation about Xenomai in internet. Could it reason for problem? "If an interrupt arrives while a Xenomai thread executes in secondary mode, it is not forwarded to Linux! The mechanism works as follows: When a Xenomai thread is executed in secondary mode, the interrupt shield domain is activated All Linux interrupts are stalled, until the Xenomai thread completes execution. The interrupts will be served again when Linux goes back to execute in background mode." Best regards, Jens 2012/11/19, Gilles Chanteperdrix : > On 11/19/2012 02:29 PM, Jens Köhler wrote: >> Hello, >> >> Now is Xenomai 2.6 installed. But I have sometimes still delays in >> user space applications. >> >> Delay: 0.003064 >> Delay: 0.003066 >> Delay: 0.003504 >> Delay: 0.003066 >> Delay: 0.003066 >> Delay: 0.003066 >> Delay: 0.003090 >> Delay: 0.003064 >> Delay: 0.003066 >> Delay: 0.003067 >> Delay: 0.053807 <- 53 ms instead 3ms >> Delay: 0.003067 >> Delay: 0.003067 >> >> I found out that problem depends from a real time queue between two >> Xenomai tasks. >> >> retval = rt_queue_create(&RtMeasureData, "RtMeasureData", 1000 * 256, >> Q_UNLIMITED, Q_FIFO | Q_SHARED); >> >> A real time task writes measurement data every 2 ms to a rt_queue. >> retval = rt_queue_write(&RtMeasureData, &FifoMeasureData, 256, Q_NORMAL); >> >> Another Xenomai task reads all measured data from queue and makes them >> available for user land applications. (Task is not real time, context >> switches) >> >> retval = rt_queue_read(&RtMeasureData, &FifoMeasureData, 256, >> TM_NONBLOCK); >> >> When nothing is written to queue is there also never an unexpected delay. >> >> Any ideas or recommendations to find reason for problem? > > Without seeing any code, there is strictly nothing we can do. > If you are able to reduce the code to a simple, self-contained test case > we can run anywhere, then we can have a look at it. > If not, then use the I-pipe tracer. > > -- > Gilles. > ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 11/19/2012 02:29 PM, Jens Köhler wrote: > Hello, > > Now is Xenomai 2.6 installed. But I have sometimes still delays in > user space applications. > > Delay: 0.003064 > Delay: 0.003066 > Delay: 0.003504 > Delay: 0.003066 > Delay: 0.003066 > Delay: 0.003066 > Delay: 0.003090 > Delay: 0.003064 > Delay: 0.003066 > Delay: 0.003067 > Delay: 0.053807 <- 53 ms instead 3ms > Delay: 0.003067 > Delay: 0.003067 > > I found out that problem depends from a real time queue between two > Xenomai tasks. > > retval = rt_queue_create(&RtMeasureData, "RtMeasureData", 1000 * 256, > Q_UNLIMITED, Q_FIFO | Q_SHARED); > > A real time task writes measurement data every 2 ms to a rt_queue. > retval = rt_queue_write(&RtMeasureData, &FifoMeasureData, 256, Q_NORMAL); > > Another Xenomai task reads all measured data from queue and makes them > available for user land applications. (Task is not real time, context > switches) > > retval = rt_queue_read(&RtMeasureData, &FifoMeasureData, 256, TM_NONBLOCK); > > When nothing is written to queue is there also never an unexpected delay. > > Any ideas or recommendations to find reason for problem? Without seeing any code, there is strictly nothing we can do. If you are able to reduce the code to a simple, self-contained test case we can run anywhere, then we can have a look at it. If not, then use the I-pipe tracer. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
Hello, Now is Xenomai 2.6 installed. But I have sometimes still delays in user space applications. Delay: 0.003064 Delay: 0.003066 Delay: 0.003504 Delay: 0.003066 Delay: 0.003066 Delay: 0.003066 Delay: 0.003090 Delay: 0.003064 Delay: 0.003066 Delay: 0.003067 Delay: 0.053807 <- 53 ms instead 3ms Delay: 0.003067 Delay: 0.003067 I found out that problem depends from a real time queue between two Xenomai tasks. retval = rt_queue_create(&RtMeasureData, "RtMeasureData", 1000 * 256, Q_UNLIMITED, Q_FIFO | Q_SHARED); A real time task writes measurement data every 2 ms to a rt_queue. retval = rt_queue_write(&RtMeasureData, &FifoMeasureData, 256, Q_NORMAL); Another Xenomai task reads all measured data from queue and makes them available for user land applications. (Task is not real time, context switches) retval = rt_queue_read(&RtMeasureData, &FifoMeasureData, 256, TM_NONBLOCK); When nothing is written to queue is there also never an unexpected delay. Any ideas or recommendations to find reason for problem? Jens ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/04/2012 01:45 PM, Jens Köhler wrote: The Xenomai application runs every 2ms for about 150 us and sends/ receives an udp packet.Rtnet socket is used for udp communication. /proc/xenomai/stat: CPU PID MSW CSW PF STAT%CPU NAME 00 0 272362 0 0050008093.8 ROOT 00 0 13475 0 00820.0 rtnet-stack 00 0 1 0 00820.0 rtnet-rtpc 018431 11677 0 003001820.1 SgbmReceive 018441 67501 0 003001844.7 SgbmSend 0184563111 63304 0 003003800.3 SgbmUserSpaceComm This thread seems to be switching modes a lot. Does it do this frequently? Each mode switch involves a task switch linux-wise. 018461 134963 0 003001840.5 SgbmTimer 00 0 67500 0 0.3 IRQ19: rteth0 00 0 298425 0 0.3 IRQ233: [timer] Application was ported from RTAI to Xenomai. With Rtai was never a problem with select. Is it supposed to give us any hint? Jens 2012/7/4, Philippe Gerum : On 07/04/2012 10:45 AM, Gilles Chanteperdrix wrote: On 07/04/2012 10:36 AM, Jens Köhler wrote: Thank you for your response Gilles. I set thread to SCHED_FIFO policy with chrt command, Prio 99. But there is no improvement. Also nanosleep do not help. The kernel is 2.6.26. What could be reason that kernel is not restart thread when time is over? It could be that the xenomai activity, if any, is running for long periods of time and causing linux ticks to be delayed. As usual, it would help if you could provide a self-contained test-case allowing us to reproduce the issue. /proc/xenomai/stat as well, in case the rt activity changes mode a lot. -- Philippe. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/04/2012 03:10 PM, Jens Köhler wrote: > Linux: 2.6.26. > Xenomai:2.4.10 > adeos-i-pipe: 2.6.26.7 This is not the first time you ask this question, last time Jan asked you to try a more recent version, this is still true. But before you do that, I suggest you try to reduce the problem to its simplest expression. For instance trying to run the latency test concurrently with the select loop, measuring the select loop latency. If the bug happens to trigger in these conditions, then you do not need to port all the needed drivers on xenomai latest release to test it. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
No posix skin Jens 2012/7/4, Jens Köhler : > Linux: 2.6.26. > Xenomai:2.4.10 > adeos-i-pipe: 2.6.26.7 > > Jens > ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
Linux: 2.6.26. Xenomai:2.4.10 adeos-i-pipe: 2.6.26.7 Jens ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/04/2012 02:49 PM, Jens Köhler wrote: > Linux: 2.6.26. > Xenomai: 2.4.10 > adeos-i-pipe: 2.6.26.7 Last question: are you compiling for the posix skin? -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/04/2012 01:45 PM, Jens Köhler wrote: > The Xenomai application runs every 2ms for about 150 us and sends/ > receives an udp packet.Rtnet socket is used for udp communication. > > /proc/xenomai/stat: > > CPU PID MSW CSW PF STAT%CPU NAME > 0 0 0 272362 0 0050008093.8 ROOT > 0 0 0 13475 0 00820.0 rtnet-stack > 0 0 0 1 0 00820.0 rtnet-rtpc > 0 18431 11677 0 003001820.1 SgbmReceive > 0 18441 67501 0 003001844.7 SgbmSend > 0 184563111 63304 0 003003800.3 SgbmUserSpaceComm > 0 18461 134963 0 003001840.5 SgbmTimer > 0 0 0 67500 0 0.3 IRQ19: rteth0 > 0 0 0 298425 0 0.3 IRQ233: [timer] > > Application was ported from RTAI to Xenomai. With Rtai was never a > problem with select. What version of linux, the I-pipe patch, and xenomai are you using ? -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
The Xenomai application runs every 2ms for about 150 us and sends/ receives an udp packet.Rtnet socket is used for udp communication. /proc/xenomai/stat: CPU PID MSW CSW PF STAT%CPU NAME 0 0 0 272362 0 0050008093.8 ROOT 0 0 0 13475 0 00820.0 rtnet-stack 0 0 0 1 0 00820.0 rtnet-rtpc 0 18431 11677 0 003001820.1 SgbmReceive 0 18441 67501 0 003001844.7 SgbmSend 0 184563111 63304 0 003003800.3 SgbmUserSpaceComm 0 18461 134963 0 003001840.5 SgbmTimer 0 0 0 67500 0 0.3 IRQ19: rteth0 0 0 0 298425 0 0.3 IRQ233: [timer] Application was ported from RTAI to Xenomai. With Rtai was never a problem with select. Jens 2012/7/4, Philippe Gerum : > On 07/04/2012 10:45 AM, Gilles Chanteperdrix wrote: >> On 07/04/2012 10:36 AM, Jens Köhler wrote: >>> Thank you for your response Gilles. I set thread to SCHED_FIFO policy >>> with chrt command, Prio 99. But there is no improvement. Also >>> nanosleep do not help. The kernel is 2.6.26. What could be reason that >>> kernel is not restart thread when time is over? >> >> It could be that the xenomai activity, if any, is running for long >> periods of time and causing linux ticks to be delayed. As usual, it >> would help if you could provide a self-contained test-case allowing us >> to reproduce the issue. >> > > /proc/xenomai/stat as well, in case the rt activity changes mode a lot. > > -- > Philippe. > > > ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/04/2012 10:45 AM, Gilles Chanteperdrix wrote: On 07/04/2012 10:36 AM, Jens Köhler wrote: Thank you for your response Gilles. I set thread to SCHED_FIFO policy with chrt command, Prio 99. But there is no improvement. Also nanosleep do not help. The kernel is 2.6.26. What could be reason that kernel is not restart thread when time is over? It could be that the xenomai activity, if any, is running for long periods of time and causing linux ticks to be delayed. As usual, it would help if you could provide a self-contained test-case allowing us to reproduce the issue. /proc/xenomai/stat as well, in case the rt activity changes mode a lot. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/04/2012 10:36 AM, Jens Köhler wrote: > Thank you for your response Gilles. I set thread to SCHED_FIFO policy > with chrt command, Prio 99. But there is no improvement. Also > nanosleep do not help. The kernel is 2.6.26. What could be reason that > kernel is not restart thread when time is over? It could be that the xenomai activity, if any, is running for long periods of time and causing linux ticks to be delayed. As usual, it would help if you could provide a self-contained test-case allowing us to reproduce the issue. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
Thank you for your response Gilles. I set thread to SCHED_FIFO policy with chrt command, Prio 99. But there is no improvement. Also nanosleep do not help. The kernel is 2.6.26. What could be reason that kernel is not restart thread when time is over? Jens 2012/7/3, Gilles Chanteperdrix : > On 07/03/2012 03:30 PM, Jens Köhler wrote: >> Hello all, >> >> I have a normal linux application running. Application waits in >> following loop normally about 8 ms. Delay time of 8ms is reliable. >> >> do >>{ >> remain(&remainTime); >> >> if ((remainTime.tv_sec != 0L) || (remainTime.tv_usec != 0L)) >> result = select(0, NULL, NULL, NULL, &remainTime); >> else >> break; >>} >>while ((result == -1) && (errno == EINTR)); >> >> If there is running in parallel a Xenomai application the wait time >> could be up to 40 ms accidentally. What could be the reason? > > Are you sure the "select" service guarantees delays with the version of > the linux kernel you use? Is the thread running with SCHED_FIFO policy? > If yes, what happens if you replace with nanosleep? > > -- > Gilles. > > ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
On 07/03/2012 03:30 PM, Jens Köhler wrote: > Hello all, > > I have a normal linux application running. Application waits in > following loop normally about 8 ms. Delay time of 8ms is reliable. > > do >{ > remain(&remainTime); > > if ((remainTime.tv_sec != 0L) || (remainTime.tv_usec != 0L)) > result = select(0, NULL, NULL, NULL, &remainTime); > else > break; >} >while ((result == -1) && (errno == EINTR)); > > If there is running in parallel a Xenomai application the wait time > could be up to 40 ms accidentally. What could be the reason? Are you sure the "select" service guarantees delays with the version of the linux kernel you use? Is the thread running with SCHED_FIFO policy? If yes, what happens if you replace with nanosleep? -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] Xenomai and normal linux application - Wait time with select() not reliable
Hello all, I have a normal linux application running. Application waits in following loop normally about 8 ms. Delay time of 8ms is reliable. do { remain(&remainTime); if ((remainTime.tv_sec != 0L) || (remainTime.tv_usec != 0L)) result = select(0, NULL, NULL, NULL, &remainTime); else break; } while ((result == -1) && (errno == EINTR)); If there is running in parallel a Xenomai application the wait time could be up to 40 ms accidentally. What could be the reason? Thanks and regards, Jens ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai