From: FatScouser on
Hi,

I have a motion control system comprising a realtime component and a
non-realtime component. Simple 2D data (position/time) is being streamed
from the non-realtime area into a FIFO queue in the realtime area. I have a
few things that I'm hoping someone could help me with:

The realtime component needs to keep running at all cost. Thus, when data
is delayed, my buffer is in danger of running dry.

There may be several options, and I'm unsure which one is best:

1. Ensure the buffer is N elements deep before I allow the realtime
component to start popping off the queue. N is determined by
trial-and-error testing and will be the number of cycles in an assumed
maximum delay. E.g. by assuming the non-realtime component will never delay
beyond 5 cycles, I can start the realtime component when the buffer reaches
5: it will then never run dry.

2. Add a second 'backup' buffer that holds predicted data (of fixed
arbitrary size M) beyond the end of what's available in the first buffer.
The realtime component will then switch to this backup if the first buffer
runs dry; it will switch back as data becomes available. The backup buffer
needs to dynamically update every cycle, e.g. as new real data comes in.

3. An alternative method?

Is there a standard way for transferring data from non-realtime to
realtime, ensuring realtime always has something to work on?

Thanks in advance!


From: John on
On Jan 20, 7:27 am, "FatScouser" <john.ha...(a)truebit.co.uk> wrote:
> Hi,
>
> I have a motion control system comprising a realtime component and a
> non-realtime component. Simple 2D data (position/time) is being streamed
> from the non-realtime area into a FIFO queue in the realtime area. I have a
> few things that I'm hoping someone could help me with:
>
> The realtime component needs to keep running at all cost. Thus, when data
> is delayed, my buffer is in danger of running dry.
>
> There may be several options, and I'm unsure which one is best:
>
> 1. Ensure the buffer is N elements deep before I allow the realtime
> component to start popping off the queue. N is determined by
> trial-and-error testing and will be the number of cycles in an assumed
> maximum delay. E.g. by assuming the non-realtime component will never delay
> beyond 5 cycles, I can start the realtime component when the buffer reaches
> 5: it will then never run dry.
>
> 2. Add a second 'backup' buffer that holds predicted data (of fixed
> arbitrary size M) beyond the end of what's available in the first buffer.
> The realtime component will then switch to this backup if the first buffer
> runs dry; it will switch back as data becomes available. The backup buffer
> needs to dynamically update every cycle, e.g. as new real data comes in.
>
> 3. An alternative method?
>
> Is there a standard way for transferring data from non-realtime to
> realtime, ensuring realtime always has something to work on?
>
> Thanks in advance!

To make sure the FIFO stays around the half-full mark, you could
consider varying the rate at which it is filled as a function of how
full it is. If it starts to get empty, fill it faster. If it starts to
get full, fill it slower. This would be a crude phase locked loop.
Search terms include "elastic store", "jitter buffer", "rate locked
loop".

John
From: FatScouser on
>On Jan 20, 7:27=A0am, "FatScouser" <john.ha...(a)truebit.co.uk> wrote:
>> Hi,
>>
>> I have a motion control system comprising a realtime component and a
>> non-realtime component. Simple 2D data (position/time) is being
streamed
>> from the non-realtime area into a FIFO queue in the realtime area. I
have=
> a
>> few things that I'm hoping someone could help me with:
>>
>> The realtime component needs to keep running at all cost. Thus, when
data
>> is delayed, my buffer is in danger of running dry.
>>
>> There may be several options, and I'm unsure which one is best:
>>
>> 1. Ensure the buffer is N elements deep before I allow the realtime
>> component to start popping off the queue. N is determined by
>> trial-and-error testing and will be the number of cycles in an assumed
>> maximum delay. E.g. by assuming the non-realtime component will never
del=
>ay
>> beyond 5 cycles, I can start the realtime component when the buffer
reach=
>es
>> 5: it will then never run dry.
>>
>> 2. Add a second 'backup' buffer that holds predicted data (of fixed
>> arbitrary size M) beyond the end of what's available in the first
buffer.
>> The realtime component will then switch to this backup if the first
buffe=
>r
>> runs dry; it will switch back as data becomes available. The backup
buffe=
>r
>> needs to dynamically update every cycle, e.g. as new real data comes
in.
>>
>> 3. An alternative method?
>>
>> Is there a standard way for transferring data from non-realtime to
>> realtime, ensuring realtime always has something to work on?
>>
>> Thanks in advance!
>
>To make sure the FIFO stays around the half-full mark, you could
>consider varying the rate at which it is filled as a function of how
>full it is. If it starts to get empty, fill it faster. If it starts to
>get full, fill it slower. This would be a crude phase locked loop.
>Search terms include "elastic store", "jitter buffer", "rate locked
>loop".
>
>John
>

I see - thanks John.
From: Tim Wescott on
On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote:

> Hi,
>
> I have a motion control system comprising a realtime component and a
> non-realtime component. Simple 2D data (position/time) is being streamed
> from the non-realtime area into a FIFO queue in the realtime area. I
> have a few things that I'm hoping someone could help me with:
>
> The realtime component needs to keep running at all cost. Thus, when
> data is delayed, my buffer is in danger of running dry.
>
> There may be several options, and I'm unsure which one is best:
>
> 1. Ensure the buffer is N elements deep before I allow the realtime
> component to start popping off the queue. N is determined by
> trial-and-error testing and will be the number of cycles in an assumed
> maximum delay. E.g. by assuming the non-realtime component will never
> delay beyond 5 cycles, I can start the realtime component when the
> buffer reaches 5: it will then never run dry.
>
> 2. Add a second 'backup' buffer that holds predicted data (of fixed
> arbitrary size M) beyond the end of what's available in the first
> buffer. The realtime component will then switch to this backup if the
> first buffer runs dry; it will switch back as data becomes available.
> The backup buffer needs to dynamically update every cycle, e.g. as new
> real data comes in.
>
> 3. An alternative method?
>
> Is there a standard way for transferring data from non-realtime to
> realtime, ensuring realtime always has something to work on?
>
> Thanks in advance!

If a part of the system has a hard deadline (i.e. "so much data in so
much time") then it is hard real time, whether or not you're calling it
that.

So solution 1 is out.

Only you know if 2 will work.

I have a suggestion that may do, depending on your problem. If your 2D
trajectories can be broken down into segments that allows the mechanism
to stop when they are done, then you can terminate each segment with a
delimiter that basically says "it's OK to stop here".

Then make sure that your buffer is big enough for the longest such
segment, and never start such a segment until you've received the
delimiter.

Or go down path '1' and just keep making the buffer deeper and deeper,
chasing a solution that never gets fully implemented but rather just
makes the problem less and less likely to happen but always leaves it
latent.

--
www.wescottdesign.com
From: FatScouser on
>On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote:
>
>> Hi,
>>
>> I have a motion control system comprising a realtime component and a
>> non-realtime component. Simple 2D data (position/time) is being
streamed
>> from the non-realtime area into a FIFO queue in the realtime area. I
>> have a few things that I'm hoping someone could help me with:
>>
>> The realtime component needs to keep running at all cost. Thus, when
>> data is delayed, my buffer is in danger of running dry.
>>
>> There may be several options, and I'm unsure which one is best:
>>
>> 1. Ensure the buffer is N elements deep before I allow the realtime
>> component to start popping off the queue. N is determined by
>> trial-and-error testing and will be the number of cycles in an assumed
>> maximum delay. E.g. by assuming the non-realtime component will never
>> delay beyond 5 cycles, I can start the realtime component when the
>> buffer reaches 5: it will then never run dry.
>>
>> 2. Add a second 'backup' buffer that holds predicted data (of fixed
>> arbitrary size M) beyond the end of what's available in the first
>> buffer. The realtime component will then switch to this backup if the
>> first buffer runs dry; it will switch back as data becomes available.
>> The backup buffer needs to dynamically update every cycle, e.g. as new
>> real data comes in.
>>
>> 3. An alternative method?
>>
>> Is there a standard way for transferring data from non-realtime to
>> realtime, ensuring realtime always has something to work on?
>>
>> Thanks in advance!
>
>If a part of the system has a hard deadline (i.e. "so much data in so
>much time") then it is hard real time, whether or not you're calling it
>that.
>
>So solution 1 is out.
>
>Only you know if 2 will work.
>
>I have a suggestion that may do, depending on your problem. If your 2D
>trajectories can be broken down into segments that allows the mechanism
>to stop when they are done, then you can terminate each segment with a
>delimiter that basically says "it's OK to stop here".
>
>Then make sure that your buffer is big enough for the longest such
>segment, and never start such a segment until you've received the
>delimiter.
>
>Or go down path '1' and just keep making the buffer deeper and deeper,
>chasing a solution that never gets fully implemented but rather just
>makes the problem less and less likely to happen but always leaves it
>latent.
>
>--
>www.wescottdesign.com
>

Thanks Tim - that all sounds good. Unfortunately I can't demand the thing
to stop. I really need the crystal-ball type of extrapolator that no-one
has invented yet!

I wonder whether inserting a dynamic resampler is the way to go - that
upsamples the input as the buffer dries up, and downsamples as it fills?