select on udp recvfrom doesn't work ???

[Lennart Sorensen]

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

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

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

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.

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