select on udp recvfrom doesn't work ???

[Lennart Sorensen]

On Tue, Aug 10, 2010 at 07:52:59PM -0400, Dave Cramer wrote:
> On Tue, Aug 10, 2010 at 6:49 PM, Lennart Sorensen
> <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> > On Tue, Aug 10, 2010 at 05:50:02PM -0400, Dave Cramer wrote:
> >> On Tue, Aug 10, 2010 at 5:29 PM, Lennart Sorensen
> >> <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> >> > On Tue, Aug 10, 2010 at 05:25:03PM -0400, Dave Cramer wrote:
> >> >> Is there some reason that doing using select does not see the data
> >> >> coming to a udp socket that is not connected, but is bound and is
> >> >> listening.
> >> >>
> >> >> I am broadcasting data to the socket. I have confirmed that if I don't
> >> >> use select that it receives data.
> >> >>
> >> >> What I am trying to do is synchronize multiple linux embedded systems
> >> >> to within 10ms. My thought is to use a UDP broadcast to start the
> >> >> synchronization then use the internal clocks. If anyone has any
> >> >> interesting ideas I'm open to suggestions.
> >> >
> >> > Have you heard of ntp?  It does just that, and way more accurately,
> >> > and is done by people that understand time synchronization.  Don't try
> >> > to reinvent a wheel, when you don't know how a wheel works.
> >> >
> >>
> >> That was pleasant .... if ntp worked I would use it. Yes it will
> >> synchronize the clocks but then what do you do.
> >
> > OK, and if you explained why ntp doesn't work, that might get better
> > answers.  If you ask for timesync and don't say ntp doesn't work, then
> > you get stupid answers (like mine).
> 
> Agreed
> 
> >
> >> Lets say you want to do something on the same  125ms on multiple
> >> machines. Your first problem is getting a starting point. One would
> >> think you could just do gettimeofday until you get to the 0th
> >> millisecond of the second, however you quickly find out that
> >> gettimeofday can't be called that quickly. So how do you set the start
> >> point ? I have thought about this a little more than your flippant
> >> response.
> >
> > It's just that it can be hard to predict the variability in the network
> > stack and even the network.  ntp does lots of complicated things (that
> > I sure don't understand in any detail) to compensate for that.  Now a
> > more complicated solution that is apparently even better is ieee1588,
> > but that tends to require hardware support to work.
> 
> I can control the network, I'm not trying to solve the general case.
> >
> > gettimeofday is an "expensive" system call.  Best not to use that.
> >
> > Now are you just trying to set the clock once and then let it run with
> > whatever crappy accuracy the system clock has or do you intend to update
> > it regularly and try to maintain the drift on the system clock?
> >
> > Now when you say syncrhonize, it just occoured to me that perhaps you
> > don't care what time it is, but are in fact trying to get multiple
> > machines to work in sync with each other on some problem.
> 
> Yes, this is what I want to do. At this point this is an experiment to
> see what can be done.
> That's rather
> > tricky since linux isn't real time and only ever promises to delay at
> > least as long as you ask for.  It doesn't do 'trigger at this time'
> > unless you start using some interrupt source for it.  On x86 you can
> > do something like that using /dev/rtc, which I have seen mplayer and
> > a few other things use.  It allowes you to get woken up at a regular
> > consistent interval to do something.  If you ran the rtc at 1024hz
> > (as mplayer often does I believe), that would certainly allow you to be
> > within 10ms, and in fact close to 1ms. After all if you had each machine
> > check every rtc event if they received a start message yet and kept doing
> > that (1024 times per second) until they received the message, then you
> > would know you are within 1 or 2 ms of the receive time of the packet
> > (whether that is anywhere near the send time depends on your network
> > and such, but in general it should be).  If you then keep waking up on
> > the event and keep a count, then you can do your event at the interval
> > you want, as long as it is a multiple of the rtc interval.
> >
> Thanks, all good information.
> > The hpet is another source of such timer events that might work.
> >
> > I think you want to forget about gettimeofday though for such things,
> > and certainly forget sleep and such, and simply use one of the timer
> > methods that allows you to request a specific frequency of wakeups,
> > to ensure you are close enough to the desired time when you do youw work.
> >
> Thanks again.

Do you have any timer sources?  Do you want to do the sync from user
space or kernel space?

The rtc is just one possible source (although often x86 only).

Have a look at:

man 2 timer_create
man 2 timer_settime

Those allow creating a regularly scheduled timer that calls a function
at a regular interval.  It does allow fairly small timer intervals, so
perhaps you could make it run every 1ms or so and see if that is good
enough to do the job.

So if every time the timer fires you do a non blocking read on your
network socket to see if you got a start message, then you can start
from there.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists