[Xenomai] Possible sync problem with timerfd and application

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Mon Dec 21 13:40:07 CET 2015


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