FPGA Central

"Andor" <[email protected]> writes:

> Randy wrote:
>
>> A real-time system is a system that has a period and a well-defined
>> maximum amount of work to be done in that period and that can perform
>> that amount of work in that period.
>>
>> Latency is input to output delay.
>
> Now think about it: the work a system does is to transform an input
> into an output. And the "period" limits the amount of time that the
> system may spend on the work, ie. the amount of time the system has
> available to transform an input into an output. So, by your
> definition, a real-time system is a system that has bounded input/
> output latency.

Oh yeah. Hmmm. That's true, Andor. I agree. The two specifications
(that is, fixed-latency and deadline-meeting) are equivalent.

I guess I meant that requiring any *specific* amount of latency is a
separate issue than requiring a system to be real-time.

After I re-read Steve's post, I believe I'm just repeating his point:
The actual latency is completely undefined. The only requirement is
that the maximum latency (whatever it may be) is fixed.
--
% Randy Yates % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC % you still wander the fields of your
%%% 919-577-9882 % sorrow."
%%%% <[email protected]> % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr

On 22 Mrz., 16:26, Scott Seidman <namdiestt...@mindspring.com> wrote:
> "Andor" <andor.bari...@gmail.com> wrote in news:1174575643.840060.198170
> @e65g2000hsc.googlegroups.com:
>
> > On 22 Mrz., 15:50, Scott Seidman <namdiestt...@mindspring.com> wrote:
> >> "Andor" <andor.bari...@gmail.com> wrote in
>
> news:1174574771.790706.183280
>
>
>
>
>
> >> @p15g2000hsd.googlegroups.com:
>
> >> > Randy wrote:
>
> >> >> A real-time system is a system that has a period and a well-defined
> >> >> maximum amount of work to be done in that period and that can
> perform
> >> >> that amount of work in that period.
>
> >> >> Latency is input to output delay.
>
> >> > Now think about it: the work a system does is to transform an input
> >> > into an output. And the "period" limits the amount of time that the
> >> > system may spend on the work, ie. the amount of time the system has
> >> > available to transform an input into an output. So, by your
> >> > definition, a real-time system is a system that has bounded input/
> >> > output latency.
>
> >> I think the deadline definition is better than the latency definition.
>
> > What's the deadline definition?
>
> You have to accomplish what needs to be done in a certain period of time.
> Achieving a maximum value of latency has different connotations than
> maintaining a deadline.

Enlighten me!

Scott Seidman <[email protected]> writes:

> "Andor" <[email protected]> wrote in news:1174575643.840060.198170
> @e65g2000hsc.googlegroups.com:
>
>> On 22 Mrz., 15:50, Scott Seidman <namdiestt...@mindspring.com> wrote:
>>> "Andor" <andor.bari...@gmail.com> wrote in
> news:1174574771.790706.183280
>>> @p15g2000hsd.googlegroups.com:
>>>
>>> > Randy wrote:
>>>
>>> >> A real-time system is a system that has a period and a well-defined
>>> >> maximum amount of work to be done in that period and that can
> perform
>>> >> that amount of work in that period.
>>>
>>> >> Latency is input to output delay.
>>>
>>> > Now think about it: the work a system does is to transform an input
>>> > into an output. And the "period" limits the amount of time that the
>>> > system may spend on the work, ie. the amount of time the system has
>>> > available to transform an input into an output. So, by your
>>> > definition, a real-time system is a system that has bounded input/
>>> > output latency.
>>>
>>> I think the deadline definition is better than the latency definition.
>>
>> What's the deadline definition?
>>
>>
>
> You have to accomplish what needs to be done in a certain period of time.
> Achieving a maximum value of latency has different connotations than
> maintaining a deadline.

This _seems_ to contradict the conclusion I just came to with Andor. Aren't
the two equivalent?
--
% Randy Yates % "So now it's getting late,
%% Fuquay-Varina, NC % and those who hesitate
%%% 919-577-9882 % got no one..."
%%%% <[email protected]> % 'Waterfall', *Face The Music*, ELO
http://home.earthlink.net/~yatescr

Randy Yates <[email protected]> writes:

> "Andor" <[email protected]> writes:
>
>> Randy wrote:
>>
>>> A real-time system is a system that has a period and a well-defined
>>> maximum amount of work to be done in that period and that can perform
>>> that amount of work in that period.
>>>
>>> Latency is input to output delay.
>>
>> Now think about it: the work a system does is to transform an input
>> into an output. And the "period" limits the amount of time that the
>> system may spend on the work, ie. the amount of time the system has
>> available to transform an input into an output. So, by your
>> definition, a real-time system is a system that has bounded input/
>> output latency.
>
> Oh yeah. Hmmm. That's true, Andor. I agree. The two specifications
> (that is, fixed-latency and deadline-meeting) are equivalent.
>
> I guess I meant that requiring any *specific* amount of latency is a
> separate issue than requiring a system to be real-time.
>
> After I re-read Steve's post, I believe I'm just repeating his point:
> The actual latency is completely undefined. The only requirement is
> that the maximum latency (whatever it may be) is fixed.

Let me add that I believe it seems much clearer, from a human semantics
point-of-view, to define real-time using the dealine paradigm and then
to allow the bounded latency to fall out from that.
--
% Randy Yates % "I met someone who looks alot like you,
%% Fuquay-Varina, NC % she does the things you do,
%%% 919-577-9882 % but she is an IBM."
%%%% <[email protected]> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

Randy Yates <[email protected]> writes:
> [...]
> (that is, fixed-latency

Doh! I meant "fixed maximum latency," or better, "bounded latency."
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <[email protected]> % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr

Randy Yates <[email protected]> wrote in news:[email protected]:

> This _seems_ to contradict the conclusion I just came to with Andor.
> Aren't the two equivalent?
>

I thought I was agreeing with you by suggesting they're not equivalent.
Especially when the thread is about definitions, definitions should be
precise.

"Latency" can mean many things. Achieving a given task in a time-critical
manner is the sense that was meant here, and "achieving deadlines" is a
more explicit and less confusing way of saying this.

--
Scott
Reverse name to reply

Scott Seidman <[email protected]> writes:

> Randy Yates <[email protected]> wrote in news:[email protected]:
>
>> This _seems_ to contradict the conclusion I just came to with Andor.
>> Aren't the two equivalent?
>>
>
> I thought I was agreeing with you by suggesting they're not equivalent.
> Especially when the thread is about definitions, definitions should be
> precise.

I agree.

> "Latency" can mean many things. Achieving a given task in a time-critical
> manner is the sense that was meant here, and "achieving deadlines" is a
> more explicit and less confusing way of saying this.

Be careful! I didn't say "latency" - I said "bounded latency" (at least
eventually I said this...). That is, a real-time system can be defined
as one that has a bounded latency. Bounded latency implies that, given
there is a maximum amount of work per period, that the system must also
"achieve deadlines." It's an if and only if, I believe.
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <[email protected]> % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr

Randy Yates wrote:
> Scott Seidman <namdiestt...@mindspring.com> writes:
> > Randy Yates <y...@ieee.org> wrote innews:[email protected]:
>
> >> This _seems_ to contradict the conclusion I just came to with Andor.
> >> Aren't the two equivalent?
>
> > I thought I was agreeing with you by suggesting they're not equivalent.
> > Especially when the thread is about definitions, definitions should be
> > precise.
>
> I agree.
>
> > "Latency" can mean many things. Achieving a given task in a time-critical
> > manner is the sense that was meant here, and "achieving deadlines" is a
> > more explicit and less confusing way of saying this.
>
> Be careful! I didn't say "latency" - I said "bounded latency" (at least
> eventually I said this...). That is, a real-time system can be defined
> as one that has a bounded latency. Bounded latency implies that, given
> there is a maximum amount of work per period, that the system must also
> "achieve deadlines." It's an if and only if, I believe.

I think so too. Clearly, bounded latency implies bounded processing
time. The converse holds for a somewhat general definition of
"processing time" as well (if you include "storing" time as
"processing" time).

On Mar 22, 4:38 pm, "Andor" <andor.bari...@gmail.com> wrote:
> Randy Yates wrote:
> > Scott Seidman <namdiestt...@mindspring.com> writes:
> > > Randy Yates <y...@ieee.org> wrote innews:[email protected]:
>
> > >> This _seems_ to contradict the conclusion I just came to with Andor.
> > >> Aren't the two equivalent?
>
> > > I thought I was agreeing with you by suggesting they're not equivalent.
> > > Especially when the thread is about definitions, definitions should be
> > > precise.
>
> > I agree.
>
> > > "Latency" can mean many things. Achieving a given task in a time-critical
> > > manner is the sense that was meant here, and "achieving deadlines" is a
> > > more explicit and less confusing way of saying this.
>
> > Be careful! I didn't say "latency" - I said "bounded latency" (at least
> > eventually I said this...). That is, a real-time system can be defined
> > as one that has a bounded latency. Bounded latency implies that, given
> > there is a maximum amount of work per period, that the system must also
> > "achieve deadlines." It's an if and only if, I believe.
>
> I think so too. Clearly, bounded latency implies bounded processing
> time. The converse holds for a somewhat general definition of
> "processing time" as well (if you include "storing" time as
> "processing" time).


just FYI, there is a USENET group that i used to hang out called
"comp.realtime" and they have a FAQ (
http://groups.google.com/group/comp....3f6d25088fc982
) and one of the FAQs in the FAQ is: "What exactly is meant by real-
time?"

check it out. (and, for real-time DSP you might see this "bounded
latency" concept in the FAQ.)

r b-j

On Mar 22, 1:32 am, "Rune Allnor" <all...@tele.ntnu.no> wrote:
> On 22 Mar, 10:15, "Andor" <andor.bari...@gmail.com> wrote:
>
> > Andreas Huennebeck wrote:
> > > minfitl...@yahoo.co.uk wrote:
> > > > What is considered real-time? How much latency would be necessary for
> > > > it to be no longer real-time?
>
> > > Real time is when the scheduler has a specified maximum context switch
> > > time.
>
> > Not every real-time system has a "scheduler" (in fact, a real-time
> > system doesn't even have to be a program).
>
> Ours is not. There is a crew of people who take part
> in the analysis, using various programs and systems.
> The 24hr limit still stands.

The word "computer" once described, not a hardware
device, but a job title (often held by a women with
a math/science degree and some dexterity at running
a mechanical desk calculator). The program consisted
of the "computers" assigned tasks and workflow. The
scheduler was the manager who made sure the right
number of people showed up at work on time for the
given task assigned to the group.

So, I'd say, yours is.

See "When Computers Were Human" by David Alan Grier
Princeton University Press (2005)


IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M

Ron N. wrote:

...

> The word "computer" once described, not a hardware
> device, but a job title (often held by a women with
> a math/science degree and some dexterity at running
> a mechanical desk calculator). The program consisted
> of the "computers" assigned tasks and workflow. The
> scheduler was the manager who made sure the right
> number of people showed up at work on time for the
> given task assigned to the group.
>
> So, I'd say, yours is.
>
> See "When Computers Were Human" by David Alan Grier
> Princeton University Press (2005)

My late wife Carolyn was a computer during WW II, calculating ballistics
tables for naval guns whose characteristics change with use. F or a
while after, she worked for Marchand Calculator, demonstrating and
teaching users as well as selling on occasion.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Randy Yates wrote:
> Randy Yates <[email protected]> writes:
>> [...]
>> (that is, fixed-latency
>
> Doh! I meant "fixed maximum latency," or better, "bounded latency."

What is the fixed maximum latency of the MPEG2 decoder in a TV? Each
frame must be decoded in time to follow the previous one in a hard real
time manner. That just means the latency of frames 2 to N must be no
greater than the latency of frame 1. The maximum for the latency of
frame 1 has no clear fixed maximum. Several days might make channel
changing a little tiresome. Something up to a second wouldn't really
hurt too much. I guess you can say the fixed maximum latency is
"whatever the first frame did", but that doesn't feel like much of a
definition.

Regards,
Steve

Jerry Avins wrote:
> Ron N. wrote:
>
> ...
>
>> The word "computer" once described, not a hardware
>> device, but a job title (often held by a women with
>> a math/science degree and some dexterity at running
>> a mechanical desk calculator). The program consisted
>> of the "computers" assigned tasks and workflow. The
>> scheduler was the manager who made sure the right
>> number of people showed up at work on time for the
>> given task assigned to the group.
>>
>> So, I'd say, yours is.
>>
>> See "When Computers Were Human" by David Alan Grier
>> Princeton University Press (2005)
>
> My late wife Carolyn was a computer during WW II, calculating ballistics
> tables for naval guns whose characteristics change with use. F or a
> while after, she worked for Marchand Calculator, demonstrating and
> teaching users as well as selling on occasion.

Selling? Isn't selling those computers called slavery? :-\

Steve

Andreas Huennebeck wrote:
> [email protected] wrote:
>
>> What is considered real-time? How much latency would be necessary for
>> it to be no longer real-time?
>
> Real time is when the scheduler has a specified maximum context switch
> time. This could be a month and still be real time.
>
> bye
> Andreas

I'm most used to implementing hard real time systems by making them
sweep repeated through their worst case activities, where it is easy to
ensure they can always keep up. Systems like this are very much hard
real time, very common, and have no scheduler at all.

No-OS - the choice of the embedded world. :-)

Regards,
Steve

Steve Underwood wrote:
> Jerry Avins wrote:
>> Ron N. wrote:
>>
>> ...
>>
>>> The word "computer" once described, not a hardware
>>> device, but a job title (often held by a women with
>>> a math/science degree and some dexterity at running
>>> a mechanical desk calculator). The program consisted
>>> of the "computers" assigned tasks and workflow. The
>>> scheduler was the manager who made sure the right
>>> number of people showed up at work on time for the
>>> given task assigned to the group.
>>>
>>> So, I'd say, yours is.
>>>
>>> See "When Computers Were Human" by David Alan Grier
>>> Princeton University Press (2005)
>>
>> My late wife Carolyn was a computer during WW II, calculating
>> ballistics tables for naval guns whose characteristics change with
>> use. F or a while after, she worked for Marchand Calculator,
>> demonstrating and teaching users as well as selling on occasion.
>
> Selling? Isn't selling those computers called slavery? :-\

There was an exception for anyone named Marchand.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Steve Underwood <[email protected]> writes:

> Randy Yates wrote:
>> Randy Yates <[email protected]> writes:
>>> [...]
>>> (that is, fixed-latency
>> Doh! I meant "fixed maximum latency," or better, "bounded latency."
>
> What is the fixed maximum latency of the MPEG2 decoder in a TV? Each
> frame must be decoded in time to follow the previous one in a hard
> real time manner. That just means the latency of frames 2 to N must be
> no greater than the latency of frame 1. The maximum for the latency of
> frame 1 has no clear fixed maximum. Several days might make channel
> changing a little tiresome. Something up to a second wouldn't really
> hurt too much. I guess you can say the fixed maximum latency is
> "whatever the first frame did", but that doesn't feel like much of a
> definition.

Steve,

You made me scratch my head.

I think the issue here is in interpreting the concept of "bounded
latency." It is difficult for me (and I think for humans in general)
to grasp, because it says nothing about what the actual maximum
latency is, but rather constrains the latency behavior.

So, to answer your question, it could be anything, from 1 frame to
1E12^1E12 millienia. The actual value depends on the implementation.
The only requirement for real-time is that, for any given
implementation, a maximum exists.

At least these are my thoughts. I'm open to correction.

I think there's something wrong with the "first frame latency"
idea. The problem I see is that the latency for the first frame may
not be the maximum, so that the latency at frame N, L_N, may be
greater than latency L_1.
--
% Randy Yates % "With time with what you've learned,
%% Fuquay-Varina, NC % they'll kiss the ground you walk
%%% 919-577-9882 % upon."
%%%% <[email protected]> % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr

On 22 Mrz., 22:17, "robert bristow-johnson"
<r...@audioimagination.com> wrote:
> On Mar 22, 4:38 pm, "Andor" <andor.bari...@gmail.com> wrote:
>
>
>
>
>
> > Randy Yates wrote:
> > > Scott Seidman <namdiestt...@mindspring.com> writes:
> > > > Randy Yates <y...@ieee.org> wrote innews:[email protected]:
>
> > > >> This _seems_ to contradict the conclusion I just came to with Andor.
> > > >> Aren't the two equivalent?
>
> > > > I thought I was agreeing with you by suggesting they're not equivalent.
> > > > Especially when the thread is about definitions, definitions should be
> > > > precise.
>
> > > I agree.
>
> > > > "Latency" can mean many things. Achieving a given task in a time-critical
> > > > manner is the sense that was meant here, and "achieving deadlines" is a
> > > > more explicit and less confusing way of saying this.
>
> > > Be careful! I didn't say "latency" - I said "bounded latency" (at least
> > > eventually I said this...). That is, a real-time system can be defined
> > > as one that has a bounded latency. Bounded latency implies that, given
> > > there is a maximum amount of work per period, that the system must also
> > > "achieve deadlines." It's an if and only if, I believe.
>
> > I think so too. Clearly, bounded latency implies bounded processing
> > time. The converse holds for a somewhat general definition of
> > "processing time" as well (if you include "storing" time as
> > "processing" time).
>
> just FYI, there is a USENET group that i used to hang out called
> "comp.realtime" and they have a FAQ (http://groups.google.com/group/comp..../thread/b43f6d...
> ) and one of the FAQs in the FAQ is: "What exactly is meant by real-
> time?"
>
> check it out. (and, for real-time DSP you might see this "bounded
> latency" concept in the FAQ.)

Indeed - added by his truly :-). Is that group active?

Randy Yates wrote:

> Steve Underwood <[email protected]> writes:

(snip)

>>What is the fixed maximum latency of the MPEG2 decoder in a TV? Each
>>frame must be decoded in time to follow the previous one in a hard
>>real time manner. That just means the latency of frames 2 to N must be
>>no greater than the latency of frame 1. The maximum for the latency of
>>frame 1 has no clear fixed maximum. Several days might make channel
>>changing a little tiresome. Something up to a second wouldn't really
>>hurt too much. I guess you can say the fixed maximum latency is
>>"whatever the first frame did", but that doesn't feel like much of a
>>definition.

The point being that once you start displaying frames you should be
able to continue at the frame rate. Note that a large latency
requires memory somewhere for the data. For disk/tape players one
can control the data rate, for RF input (air or cable) on can't.

> I think the issue here is in interpreting the concept of "bounded
> latency." It is difficult for me (and I think for humans in general)
> to grasp, because it says nothing about what the actual maximum
> latency is, but rather constrains the latency behavior.

> So, to answer your question, it could be anything, from 1 frame to
> 1E12^1E12 millienia. The actual value depends on the implementation.
> The only requirement for real-time is that, for any given
> implementation, a maximum exists.

There are obvious reasons it can't be too high, as I said above
data storage is one. But I agree it can be much longer than the
frame display time.

> At least these are my thoughts. I'm open to correction.

> I think there's something wrong with the "first frame latency"
> idea. The problem I see is that the latency for the first frame may
> not be the maximum, so that the latency at frame N, L_N, may be
> greater than latency L_1.

I agree, but one must be able to predict that in advance. Well,
you can probably get away with missing a small fraction of the
frames. I might assume a distribution with a long tail, so there
is a very small probability of a very long latency for a frame.

In the usual case the decoding algorithm is fixed and known in
advance. One can change the encoding algorithm, for example
depending on available processing power. The encoding, which
doesn't have to be real time, should be able to predict the
decoding latency and adapt to limit that latency.

-- glen

On Mar 23, 12:59 pm, "Andor" <andor.bari...@gmail.com> wrote:
>
> Indeed - added by his truly :-).

yeah, i know it was a cheap shot.

> Is that group active?

it really doesn't appear to be very active at all.

r b-j

Steve wrote:
....
> No-OS - the choice of the embedded world. :-)

Closely followed by WhileOne (TM).

:-)