[Xenomai] Possible sync problem with timerfd and application

[Xenomai] Possible sync problem with timerfd and application

[Umair Ali]

Hello there,

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. Or timerfd is not working fine. I tried to use the poll() and epoll() also but the problem persist.  Can you guide me how i can find the problem when running the application or do you need more information regarding this problem. Please feel free to ask for more.

Thanks and BR
Ali

P.S The size of readig file is 600MB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raw_udp_sv.c
Type: text/x-csrc
Size: 5695 bytes
Desc: raw_udp_sv.c
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151217/5eb89e90/attachment.c>

Re: [Xenomai] Possible sync problem with timerfd and application

[Philippe Gerum]

On 12/17/2015 03:07 PM, Umair Ali wrote:
> Hello there,
> 
> 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.

For the sake of clarity, Gilles told you about the requirement for
timerfd_create() to switch to secondary/linux mode for processing the
request, which may induce delays. He certainly did not told you that
reading from that Cobalt timerfd would induce jitter on a
well-performing Xenomai setup. You may convince yourself about this fact
by running the latency test: it is based on a sampling thread
synchronizing on a timerfd.

Unless you do observe high latencies with this test program, you should
probably assume a bug in the application rather than suspecting any core
operating system services, at least during the early stage of your
investigations.

 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. Or timerfd is not working fine. I tried to use the poll()
and epoll() also but the problem persist.  Can you guide me how i can
find the problem when running the application or do you need more
information regarding this problem. Please feel free to ask for more.
> 

Your code is wrong: mixing regular linux systems calls like sendto()
over an AF_INET socket with Cobalt rt system calls will necessarily
induce delays in your loop, up to the amount of jitter sendto() may
suffer from the regular kernel.

Actually, I don't understand the reasoning behind that code. You want to
send a packet each 249 us precisely, but you do so traversing a
non-deterministic network stack, most likely over a probabilistic
(time-wise) medium, assuming this is 802.3 under the hood. You may want
to consider RTNet instead.

You are using a dual kernel system: real-time behavior is achievable
only if your application exclusively uses services from the real-time
co-kernel during the time-critical phases.

This is explained here:
http://xenomai.org/start-here/#How_does_Xenomai_deliver_real-time

-- 
Philippe.

Re: [Xenomai] Possible sync problem with timerfd and application

[Umair Ali]

Hello Phillipe,

Thanks for you reply.

> For the sake of clarity, Gilles told you about the requirement for timerfd_create() to switch to secondary/linux mode for processing the request, which may induce delays. He certainly did not told you that reading from that Cobalt timerfd would induce jitter on a well-performing Xenomai setup

Yes Gilles told me that timerfd_create() causes switch to secondary mode. He told me to focus on the use of kernel timers for removing jitters. I hadshared the slackspot output file with him and he told me that timerfd_create() is called once in the code so after the creation it will work fine in the primary mode by reading the timerfd. Is there any way i can obtain the timer in userspace with very low jitter or  if i have to use kernel space timers for my purpose. What is suggestion or idea.

> You may convince yourself about this fact by running the latency test: it is based on a sampling thread synchronizing on a timerfd.

I have attached the latency test with this email for the reference. It will be nice of you if you look at the file and assure me if i have installed xenomai 3.0.1 correctly.

> Your code is wrong: mixing regular linux systems calls like sendto() over an AF_INET socket with Cobalt rt system calls will necessarily induce delays in your loop, up to the amount of jitter sendto() may suffer from the regular kernel.

> Actually, I don't understand the reasoning behind that code. You want to send a packet each 249 us precisely, but you do so traversing a non-deterministic network stack, most likely over a probabilistic (time-wise) medium, assuming this is 802.3 under the hood. You may want to consider RTNet instead.

I have followed the link https://xenomai.org/rtnet-programming/ for the UDP programming using Rtnet. More over i have read that "From an application point of view, using the Xenomai POSIX skin wrapped services allows for manipulation of file descriptors provided by the RTDM skin as if they were ordinary file descriptors" as in the link http://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/#Access_to_drivers. Therefore i thought that wrap function will automatically link the sendto() and socket() functions with Rtnet. Because before running the application, i have run the script attached with the email to bind the rt_8139too drivers and unmount the 8139too driver. Therefore i assume that rtnet is activated and i can link the application with the help of wrap function of xenomai POSIX skin

Please guide me how i can send the userdefined UDP packets using RTnet in Xenomai 3.0.1 or in other word avoid the jitter of sendto().

Thanks & BR
Ali
________________________________________
From: Philippe Gerum [rpm@xenomai.org]
Sent: Friday, December 18, 2015 11:22 AM
To: Umair Ali; =?UTF-8?Q?Xenomai_list_=e2=80=8e_[xenomai@
Subject: Re: [Xenomai] Possible sync problem with timerfd and application

On 12/17/2015 03:07 PM, Umair Ali wrote:
> Hello there,
>
> 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.

For the sake of clarity, Gilles told you about the requirement for
timerfd_create() to switch to secondary/linux mode for processing the
request, which may induce delays. He certainly did not told you that
reading from that Cobalt timerfd would induce jitter on a
well-performing Xenomai setup. You may convince yourself about this fact
by running the latency test: it is based on a sampling thread
synchronizing on a timerfd.

Unless you do observe high latencies with this test program, you should
probably assume a bug in the application rather than suspecting any core
operating system services, at least during the early stage of your
investigations.

 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. Or timerfd is not working fine. I tried to use the poll()
and epoll() also but the problem persist.  Can you guide me how i can
find the problem when running the application or do you need more
information regarding this problem. Please feel free to ask for more.
>

Your code is wrong: mixing regular linux systems calls like sendto()
over an AF_INET socket with Cobalt rt system calls will necessarily
induce delays in your loop, up to the amount of jitter sendto() may
suffer from the regular kernel.

Actually, I don't understand the reasoning behind that code. You want to
send a packet each 249 us precisely, but you do so traversing a
non-deterministic network stack, most likely over a probabilistic
(time-wise) medium, assuming this is 802.3 under the hood. You may want
to consider RTNet instead.

You are using a dual kernel system: real-time behavior is achievable
only if your application exclusively uses services from the real-time
co-kernel during the time-critical phases.

This is explained here:
http://xenomai.org/start-here/#How_does_Xenomai_deliver_real-time

--
Philippe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initial.sh
Type: application/x-shellscript
Size: 1858 bytes
Desc: initial.sh
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151218/91ecf2c1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: latency_test_output
Type: application/octet-stream
Size: 3042 bytes
Desc: latency_test_output
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151218/91ecf2c1/attachment.obj>

Re: [Xenomai] Possible sync problem with timerfd and application

[Gilles Chanteperdrix]

On Thu, Dec 17, 2015 at 02:07:20PM +0000, Umair Ali wrote:
> Hello there,
> 
> 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.

> 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.

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.


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

Re: [Xenomai] Possible sync problem with timerfd and application

[Umair Ali]

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.
__________
______________________________
From: Gilles Chanteperdrix [gilles.chanteperdrix@xenomai.org]
Sent: Sunday, December 20, 2015 5:03 PM
To: Umair Ali
Cc: Xenomai list ‎[xenomai@xenomai.org]‎
Subject: Re: [Xenomai] Possible sync problem with timerfd and application

On Thu, Dec 17, 2015 at 02:07:20PM +0000, Umair Ali wrote:
> Hello there,
>
> 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.

> 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.

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.


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

Re: [Xenomai] Possible sync problem with timerfd and application

[Gilles Chanteperdrix]

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

Re: [Xenomai] Possible sync problem with timerfd and application

[Umair Ali]

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@xenomai.org]
Sent: Monday, December 21, 2015 2:40 PM
To: Umair Ali
Cc: Xenomai list ‎[xenomai@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

Re: [Xenomai] Possible sync problem with timerfd and application

[Gilles Chanteperdrix]

On Mon, Dec 21, 2015 at 02:29:07PM +0000, Umair Ali wrote:
> 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.

The problem is that your code does not dereference j, but j plus
some offset. So I can see that j < size is always true, thanks to
the while loop. What I tell you is that this does not guarantee that
j + offset is less than size. This is an obvious, trivial flaw,
really.

> 
> >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.

I do not care why you send UDP packets. The point is I wanted to be
sure that you understood that you were no longer sending raw
packets.

> 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.

To be frank, I do not understand what your problem is. You tell us
that you have timing problems, but at the same time the timerfd does
not return you any overruns. How do you know you have timing
problems them? Is the receiving computer running RTnet? Because if
it is not running RTnet, you have no way of knowing if the problem
is not on the receiving side.

Also, it would be nice if you could avoid top-posting, as is
traditional on mailing lists.

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