select on udp recvfrom doesn't work ???

[Dave Cramer]

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.

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