On Sun, Apr 14, 2013 at 1:21 AM, Matthew Dempsky <matt...@dempsky.org>wrote:
> On Sat, Apr 13, 2013 at 2:53 PM, Mihai Popescu <mih...@gmail.com> wrote: > > Can someone give me some hints in this direction, please, what exactly > > triggers usleep() internaly ? > > usleep() doesn't trigger anything, but usleep(1) doesn't mean "sleep > exactly 1us", it means "sleep at least 1us". In practice, your > process is probably sleeping for much longer than that because of the > scheduler clock's granularity. > > Try calling clock_gettime() immediately before and after the usleep() > to see how long you're actually sleeping. > Thank you, Matthew. That was the situation: usleep(1) takes something like 19 ms. This time is enough to transmit 19 bytes, more that enought for my case. I didn't expected to sleep exactly 1 us, but neither 19 ms. I replaced usleep() with a long for cycle and depending of the cycling length the receiving is varying accordingly. I think there are more friedly ways to accomplish this but for the moment i will stay with usleep().
