‘real time’ issues

[Paul Gr]

hello Leisha,

A small note on ‘real time’ issues:

Since marketing people like to use ‘sexy’ words to promote additional 
functionality or suggest superior specifications, we have to be a bit 
careful how to interpret the words ‘real time’ correctly. The actual meaning 
depends on the context: Most hardware and software engineers use the words 
‘real time’ to indicate that the time allowed to execute some kind of 
operation is limited to a known maximum. Some engineers also differentiate 
between so called hard and soft real time. In hard real time systems it is 
an absolute system failure if the real time criteria are not met. (Ie. the 
air bag in a car is definitely a hard real time system.) In soft real time 
systems the real time criteria are less strict. This is the case with EPrime 
where it is sufficient to keep track of such timing failures. (See also 
http://en.wikipedia.org/wiki/Real_time) Anyway, this kind of real time is 
about the response time limits of a system, not its execution speed or 
bandwidth.

Real time streaming media protocols on the other hand, are said to play 
media in ‘real time’ when it is possible to play the media stream at the 
correct speed (ie. not in slow motion.) So, in this case marketing people 
and engineers refer to the large bandwidth or execution speed of the system, 
not maximum response latency. In other words: even though Firewire and USB 
standards support large bandwidths, this does not mean that they support 
short (<1ms) transmission delays. Furthermore, the complex protocol stacks 
that are used to implement those communication systems make it almost 
impossible to realize short latencies. But even if you are willing to accept 
timing errors, it is not very trivial to develop hardware that connects 
through USB or Firewire. RS232 and parallel ports are much easier to use in 
both hard- and software.

There are some real time systems that use another common connection between 
de external hardware and the computer: Ethernet. A (dedicated) Ethernet 
connection supports high bandwidth and short transmission latencies. 
However, as with USB and Firewire, it is not very easy to develop hard- and 
software for such a connection. (Note that PST writes it will support some 
kind of Network Socket Device in version 2.)

Paul Groot



>From: Leisha Wharfield <leisha at decisionresearch.org>
>To: Alison Wright <alison.wright at kcl.ac.uk>,  'E-Prime' 
><eprime at mail.talkbank.org>
>Subject: Laptop replies + new issue #5
>Date: Thu, 05 Jan 2006 10:33:00 -0800
>
...
>
>5. A final issue to add: We use input devices that were made for our RT 
>experiments. They are large switches or buttons, one for each hand, that 
>can be pushed easily and give a solid clicking sound. They are wired into a 
>serial device because when we began this series of RT computer experiments, 
>we were told that the serial port was the cleanest, quickest way to get to 
>the processor and we are measuring very fine time differences. Now serial 
>ports are hard to come by on laptops, and when I read about new laptop 
>connectors I find that the now-standard FireWire IEEE 1394 is a port that 
>was designed for using a computer in "real time," that is, to play 3D games 
>or to interact with streaming video. Wouldn't this now be the best port for 
>measuring very fine time differences? Or is serial still the best way to 
>go?
>
>I'll post another synopsis of replies received.
>
>Thanks for all your help.
>
>Leisha
>