select on udp recvfrom doesn't work ???

[Dave Cramer]

On Tue, Aug 10, 2010 at 7:52 PM, Dave Cramer <davec-zxk95TxsVYDyHADnj0MGvQC/G2K4zDHf at public.gmane.org> 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.
>>
So this was a bust. The rtc on this board a ts7260 cannot generate interrupts :(

The chip itself has an rtc and some internal timers that could
generate interrupts.

The question still remains how to get them synchronized to the same
place in time. Using a udp message which would arrive roughly at the
same time to all devices still seems plausible ?

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