[Xenomai] Possible sync problem with timerfd and application

Umair Ali ali.umair at tut.fi
Mon Dec 21 15:29:07 CET 2015


I am very sorry for disturbing you for many basic and stupid questions. Actually i am new to linux and xenomai therefore i really appreciate you patience. Please forgive me.

>The problem is not the type of j. The problem is that if you test
>j < size
>
>and then use j + something
>
>j + something may well be above size.

I have printed the value of j in every turn of the while loop. I have found that the j has a value always less than size. the maximum size is 602198442 and the  last value of j is 602198334. Therefore i dont think the value of j is higher or above the size at any time.

>As far as I know, there is no problem with sending UDP packets over
>RTnet, actually, I verified the round trip time of two machines
>running RTnet over several hours, and it did not have any issue.
>Neither has the timerfd system, as tested by the latency test.

>I was just trying to signal you that you came on that list asking
>for a way of sending raw packets, I replied you with an example
>program doing exactly that, but now you have rewritten a program
>using UDP packets (keeping some parts of the program I sent you
>which are now useless, namely retrieving the MAC address of the
>network card). You are not sending raw packets.

Its true that i have just modified same code, as you send me for raw ethernet packets, for UDP packets. i have a UDP server running in embedded hardware named dSPACE. When i run the code i can see the UDP traffic and the server (in dSPACE) is able to receive the packets also. Therefore i was sure that it is also the way to send UDP packets. Do you think this can still be the problem. I have gone through the link (https://xenomai.org/rtnet-programming/). This is for xenomai 2 but not for xenomai 3. Is there any similar link for programming Rtnet with xenomai 3.

I am very confused what can be problem. Do you have idea how to trace back the problem. 

I think i should now work in the kernel space and take the advice of the kernel timers. Please guide me to use the RTnet module in kernel space app.

Thanks & Br
Ali

 



________________________________________
From: Gilles Chanteperdrix [gilles.chanteperdrix at xenomai.org]
Sent: Monday, December 21, 2015 2:40 PM
To: Umair Ali
Cc: Xenomai list ‎[xenomai at xenomai.org]‎
Subject: Re: [Xenomai] Possible sync problem with timerfd and application

On Mon, Dec 21, 2015 at 12:06:10PM +0000, Umair Ali wrote:
> Hello Gilles, Thanks for the reply.
>
> > I am using the timerfd to produce the required sleep function for
> > sending the raw ethernet packets using rtnet driver periodically.
> > I read the file using the mmap() function and
> > mlockall(MCL_CURRENT|MCL_FUTURE). My code is attached with this
> > email. Gilles have already explained me with the jitter problem
> > with timerfd but it is acceptable so far with me. Now the problem
> > is that the code runs ok for more or less 30 secs. For this period
> > of running of code the jitter is acceptable. But after some time
> > the jitter increases very much and causes problem. I thought that
> > this may be because the timerfd has lost the synchronization with
> > application.
>
> >The "read" call on a timerfd reads the number of timer ticks since the last read, so you can know whether an overrun occurred by checking the variable named "exp" in your program.
>
> I have printed the value of variable 'exp' which is 1 every time. I believe that there is no overrun..
>
> > Or timerfd is not working fine. I tried to use the
> > poll() and epoll() also but the problem persist. Can you guide me
>
> > poll() is not a wrapped call, so causes a switch to secondary mode.Did not you see that with slackspot? Xenomai only wraps the "select"call.
>
> >Yeah it is my mistake that i used poll() or epoll() and you are right that it will change to secondary mode. I will try >to use the select() function. But what do you think that it can avoid the problem.
>
> >Also note that by using the AF_INET family, you are no longer
> >sending raw packets but UDP packets.
>
> >And finally I do not know what your ugly memcpy with hardcoded
> >lengths do exactly, but the check (j < size) looks insufficient,
> >as the memcpys are accessing data beyond j. If you receive a signal doing
> >this, this would certainly cause a switch to secondary mode.
>
> Basically what i am doing is that i have pcap file of the IEC
> 61850 Sampled values (SV). I want to playback the pcap file in the
> network as real time with deterministic behaviour. There is UDP
> module for the Rtnet. As in the packet of Sampled value the data
> is 64bytes in the tail of the frame of the SV and length of SV
> frames are constant. Therefore I am taking the data directly from
> the SV frame by using memcpy() and hard length memory access.
> Trying to encapsulate in the UDP packet to send it over the
> network. As the data of SV is sampled values of the voltages and
> currents of the phases of power systems which are sampled at the
> 80 sample per cycle and frequency is 50 Hz. Therefore i need to
> send the data at 0.250msec or 250µsec.
>
> I have change the type of variable 'j' into unsigned long long int
> but still the problem presist.
>
> Can you guide me how i can use the UDP module of Rtnet to send UDP
> packets.

The problem is not the type of j. The problem is that if you test
j < size

and then use j + something

j + something may well be above size.

As far as I know, there is no problem with sending UDP packets over
RTnet, actually, I verified the round trip time of two machines
running RTnet over several hours, and it did not have any issue.
Neither has the timerfd system, as tested by the latency test.

I was just trying to signal you that you came on that list asking
for a way of sending raw packets, I replied you with an example
program doing exactly that, but now you have rewritten a program
using UDP packets (keeping some parts of the program I sent you
which are now useless, namely retrieving the MAC address of the
network card). You are not sending raw packets.

--
                                            Gilles.
https://click-hack.org



More information about the Xenomai mailing list