Re: [Playerstage-developers] Player's Default Datamode

[brian g. <bg...@us...>]

On Fri, 10 Jan 2003, David James Naffin wrote:

> 	Working with the broadcast device(comms) I ran aground when attempting
> to send broadcast messages too quickly. It would seem that the default
> data transfer mode (i.e. PLAYER_DATAMDOE_PUSH_NEW) filters out messages.
> By explicitly setting the mode to PUSH_ALL I was able to resolve the
> problem. Talking with Andrew, he believes that PLAYER_DATAMODE_PUSH_ALL
> should be the default mode? BTW I am working with slightly out-sync CVS
> head version. Any thoughts?
>

Dave,

Well, the default data transfer mode, PLAYER_DATAMDOE_PUSH_NEW, does in a
sense filter out messages, but based on time.  That is, if the timestamp for a
device's data is the same as it was last time data was delivered to a
particular client, then that message won't be delivered.  The assumption is
that if two pieces of data are different then they will have different
timestamps.

In the case of the udpbroadcast driver, if consecutive messages have the same
received timestamp, I suppose that only the first one would actually be
delivered, although all of them would be dequeued and forgotten by the driver.
Interesting.  You would have to send the messages very fast, in order for them
to get the same timestamp, down to the microsecond.

Aha!  But if you're using Stage, then the clock, which is driven by the
simulator, ticks relatively slowly and with big ticks (probably at least
10ms).  All messages received between ticks would get the same timestamp,
causing all but one to be lost.

Never thought about this.  I still think that PLAYER_DATAMDOE_PUSH_NEW should
be the default mode, because it often saves a ton of bandwidth.  I would
suggest that you change to PLAYER_DATAMODE_PUSH_ALL when using the
udpbroadcast driver in Stage.  I'll put a note about that in the Player
manual.

An alternative would be to add precision to Stage's clock, but that's next to
impossible on OSs like Linux, whose schedulers have rather gross timeslices.

        brian.