Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: David James Naffin <dnaffin@i-...> - 2003-01-10 18:22:36
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?
From: brian gerkey <bgerkey@us...> - 2003-01-11 18:27:47
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?
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
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
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.