I/O latency for systems not using a RTOS

I've been implementing custom devices for stage music use for several years, 
using small SBCs that run a basic RTOS that I code up myself. The input and 
output  is MIDI, coded music tokens (not digitised audio) at a serial data 
rate of 31.25 KB. Even with the maximum amount of processing involved, 
latency time between receipt of a byte and its associated transmission was 
never more than a millisecond or so.

The main limitation has been HMI, for that reason I'm looking at moving to a 
SBC that can support USB so that I can connect to a tablet or palm device. 
What I'm finding is that boards that support the sort of interfaces that 
will talk to eg. a tablet, are often really slow in comparison. Based on 
information I've managed to glean, many of these systems are likely to 
introduce throughput delays of 30mS or longer, even for a 2-line program 
loop read char/send char.That's getting to be too long for music.

The OS involved, usually Linux, is one contributor, random processing 
holdups of > 10mS for system housekeeping are cited. One system I checked 
out doesn't use interrupts for the serial ports that MIDI uses, it just 
polls them at about 100 Hz, adding another potentially 20mS to the round 
trip.

What I'm after is a small SBC that has reasonable support for USB comms, and 
also can guarantee turnround of only a few mS for low level I/O such as 
serial comms. Does anyone have any suggestions? TIA 

On 19/01/2012 13:11, Bruce Varley wrote:
> I've been implementing custom devices for stage music use for several years,
> using small SBCs that run a basic RTOS that I code up myself. The input and
> output  is MIDI, coded music tokens (not digitised audio) at a serial data
> rate of 31.25 KB. Even with the maximum amount of processing involved,
> latency time between receipt of a byte and its associated transmission was
> never more than a millisecond or so.
>
> The main limitation has been HMI, for that reason I'm looking at moving to a
> SBC that can support USB so that I can connect to a tablet or palm device.
> What I'm finding is that boards that support the sort of interfaces that
> will talk to eg. a tablet, are often really slow in comparison. Based on
> information I've managed to glean, many of these systems are likely to
> introduce throughput delays of 30mS or longer, even for a 2-line program
> loop read char/send char.That's getting to be too long for music.
>
> The OS involved, usually Linux, is one contributor, random processing
> holdups of>  10mS for system housekeeping are cited. One system I checked
> out doesn't use interrupts for the serial ports that MIDI uses, it just
> polls them at about 100 Hz, adding another potentially 20mS to the round
> trip.
>
> What I'm after is a small SBC that has reasonable support for USB comms, and
> also can guarantee turnround of only a few mS for low level I/O such as
> serial comms. Does anyone have any suggestions? TIA
>

USB serial ports will always have a few milliseconds latency.  One thing 
to be careful of is that they like to send data in packets, so often 
have relatively long timeouts between the last character coming in, and 
the packet being sent to the PC.  This can often be tuned (FTDI devices 
let you tune this, and they have good support for Linux).  But if you 
have the option of using an onboard UART, go for that.

With Linux, you can choose the level of real time "hardness".  There is 
always a balance between aiming for minimal latency and aiming for 
maximal throughput.  Kernels targeted for servers are usually at the 
"throughput" end, while desktop/tablet kernels are more balanced. 
Embedded systems often choose to minimise latency, as do specialised 
desktop distributions like Dynabolic and Ubuntu Studio.  Of course, if 
you are happy compiling the kernel yourself then you can make your own 
choices here.  Linux is never "hard" real time, but it can certainly be 
pretty "solid" real time and good enough for uses like this.  In 
particular, with kernel pre-emption enabled, it is very rare that 
"housekeeping" will delay a real-time priority task.

Another useful trick when you have a process that you want to be minimal 
latency, is to have a processor with at least two cores.  Then you can 
give your important process a real-time priority and be confident that 
if there are other "housekeeping" tasks, they will run on the other 
processor.

Bruce Varley wrote:

> I've been implementing custom devices for stage music use for several
> years, using small SBCs that run a basic RTOS that I code up myself. The
> input and
> output  is MIDI, coded music tokens (not digitised audio) at a serial data
> rate of 31.25 KB. Even with the maximum amount of processing involved,
> latency time between receipt of a byte and its associated transmission was
> never more than a millisecond or so.
> 
> The main limitation has been HMI, for that reason I'm looking at moving to
> a SBC that can support USB so that I can connect to a tablet or palm
> device. What I'm finding is that boards that support the sort of
> interfaces that will talk to eg. a tablet, are often really slow in
> comparison. Based on information I've managed to glean, many of these
> systems are likely to introduce throughput delays of 30mS or longer, even
> for a 2-line program loop read char/send char.That's getting to be too
> long for music.

I've worked on things that sent blocks of hundreds of bytes at a rate of 200 
blocks/second, and latency well inside that 5msec limit.  The key seemed to 
be to use USB CDC protocol.  In the Linux host system we were dealing with 
device paths like /dev/ttyUSB0 or /dev/ttyACM0.  The I/O device hardware 
coded a USB stack inside PIC32; I think earlier hardware had used FT232 on a 
PIC18 and got similar performance.

	Mel.

David Brown <david@westcontrol.removethisbit.com> wrote:


> choices here.  Linux is never "hard" real time, but it can certainly be
> pretty "solid" real time and good enough for uses like this.  In 

well, actually you can use some patch to make linux hard real time.
For example Linux-RTAI <https://www.rtai.org/>

Bye Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

>I've been implementing custom devices for stage music use for several
years, 
>using small SBCs that run a basic RTOS that I code up myself. The input
and 
>output  is MIDI, coded music tokens (not digitised audio) at a serial data

>rate of 31.25 KB. Even with the maximum amount of processing involved, 
>latency time between receipt of a byte and its associated transmission was

>never more than a millisecond or so.
>
>The main limitation has been HMI, for that reason I'm looking at moving to
a 
>SBC that can support USB so that I can connect to a tablet or palm device.

>What I'm finding is that boards that support the sort of interfaces that 
>will talk to eg. a tablet, are often really slow in comparison. Based on 
>information I've managed to glean, many of these systems are likely to 
>introduce throughput delays of 30mS or longer, even for a 2-line program 
>loop read char/send char.That's getting to be too long for music.
>
>The OS involved, usually Linux, is one contributor, random processing 
>holdups of > 10mS for system housekeeping are cited. One system I checked

>out doesn't use interrupts for the serial ports that MIDI uses, it just 
>polls them at about 100 Hz, adding another potentially 20mS to the round 
>trip.
>
>What I'm after is a small SBC that has reasonable support for USB comms,
and 
>also can guarantee turnround of only a few mS for low level I/O such as 
>serial comms. Does anyone have any suggestions? TIA 
>
>
>

Could you explain a bit more about your HIM implementation and how is your
SBC  hardware? In general you can set the priority of your music process to
maximum, and the HIM managin to your left time. In general, you can set
some sort of DMA to always transfer your image buffer to the display. So
all you got do is uptdate your display buffer at RAM. The user inputs would
be handled by a interrupt, but just effectively processed when you got time
left. I belive that is the most common implementation.

Cya	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On 19 Jan., 17:08, pip...@disney.com (Jack) wrote:
> David Brown <da...@westcontrol.removethisbit.com> wrote:
> > choices here. =A0Linux is never "hard" real time, but it can certainly =
be
> > pretty "solid" real time and good enough for uses like this. =A0In
>
> well, actually you can use some patch to make linux hard real time.
> For example Linux-RTAI <https://www.rtai.org/>
>

usb will always have a latency of atleast 1ms, thats the frame rate.

must be possible doing hard realtime in windows too, cnc programs like
mach3
does 10s of kHz on the parallelport


-Lasse

On 20/01/2012 03:42, langwadt@fonz.dk wrote:
> On 19 Jan., 17:08, pip...@disney.com (Jack) wrote:
>> David Brown<da...@westcontrol.removethisbit.com>  wrote:
>>> choices here.  Linux is never "hard" real time, but it can certainly be
>>> pretty "solid" real time and good enough for uses like this.  In
>>
>> well, actually you can use some patch to make linux hard real time.
>> For example Linux-RTAI<https://www.rtai.org/>
>>

There are a few systems that let you use Linux in a hard real time 
system.  But they are, in a sense, a cheat - they work by using an 
independent hard real time OS on the bottom, and running Linux as a 
low-priority task on the RTOS.

The normal Linux RT options (such as kernel preemption) are good enough 
for most uses - if you need something with tigher control you are 
usually best with a separate microcontroller for the critical stuff.

>
> usb will always have a latency of atleast 1ms, thats the frame rate.
>
> must be possible doing hard realtime in windows too, cnc programs like
> mach3
> does 10s of kHz on the parallelport
>

No, that is not hard realtime.  You can do sort-of real time on Windows, 
and there are third-party extensions that make it a bit better (though 
never "hard").  Remember, there is a big difference between "running 
fast" and "realtime".  Yes, you can run the parallel port fast on 
Windows (or Linux) - but you can't guarantee that it will /always/ run 
fast.  Sometimes the program will be delayed unexpectedly - hence it is 
not real time.

>
> -Lasse

>On 19 Jan., 17:08, pip...@disney.com (Jack) wrote:
>> David Brown <da...@westcontrol.removethisbit.com> wrote:
>> > choices here. =A0Linux is never "hard" real time, but it can certainly
=
>be
>> > pretty "solid" real time and good enough for uses like this. =A0In
>>
>> well, actually you can use some patch to make linux hard real time.
>> For example Linux-RTAI <https://www.rtai.org/>
>>
>
>usb will always have a latency of atleast 1ms, thats the frame rate.
>
>must be possible doing hard realtime in windows too, cnc programs like
>mach3
>does 10s of kHz on the parallelport
>
>
>-Lasse
>

Well that is not totally true. If you go for a bulk communication you can
send more than one message per frame, so if you got a continuously
communication is possible to have a latecy smaller than 1ms between
messages. But as a drawback there is not garantee that you will have any
bandwidth so it is not usable. For a real time communication there is the
isochronous transfer, but if your OS cannot behave within your real time
specs, you got no garantees at all.

Cya	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On 2012-01-19, langwadt@fonz.dk <langwadt@fonz.dk> wrote:
>>
>> well, actually you can use some patch to make linux hard real time.
>> For example Linux-RTAI <https://www.rtai.org/>
>>
>
> usb will always have a latency of atleast 1ms, thats the frame rate.
>

While it was 1ms back in the UHCI days, the polling interval for EHCI has
been reduced to 125us.

As someone else here pointed out to me not so long ago, EHCI latency can be
reduced further under certain circumstances.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Thu, 19 Jan 2012 20:11:03 +0800, Bruce Varley wrote:

> I've been implementing custom devices for stage music use for several
> years, using small SBCs that run a basic RTOS that I code up myself. The
> input and output  is MIDI, coded music tokens (not digitised audio) at a
> serial data rate of 31.25 KB. Even with the maximum amount of processing
> involved, latency time between receipt of a byte and its associated
> transmission was never more than a millisecond or so.
> 
> The main limitation has been HMI, for that reason I'm looking at moving
> to a SBC that can support USB so that I can connect to a tablet or palm
> device. What I'm finding is that boards that support the sort of
> interfaces that will talk to eg. a tablet, are often really slow in
> comparison. Based on information I've managed to glean, many of these
> systems are likely to introduce throughput delays of 30mS or longer,
> even for a 2-line program loop read char/send char.That's getting to be
> too long for music.
> 
> The OS involved, usually Linux, is one contributor, random processing
> holdups of > 10mS for system housekeeping are cited. One system I
> checked out doesn't use interrupts for the serial ports that MIDI uses,
> it just polls them at about 100 Hz, adding another potentially 20mS to
> the round trip.
> 
> What I'm after is a small SBC that has reasonable support for USB comms,
> and also can guarantee turnround of only a few mS for low level I/O such
> as serial comms. Does anyone have any suggestions? TIA

You seem to be bounding your question as "How can I get real-time 
performance from USB on a computer with an OS that's not real-time".

Perhaps you should ask "How can I get USB functionality on a processor 
that doesn't need any stinkin' OS?"

I haven't had the need to implement anything, but I notice that quite a 
few of the available embedded processors that have USB hardware also have 
USB software available.  Most is free, some is even included in ROM in 
the chip.

There may be a path to success here that involves continuing to use your 
existing home-rolled RTOS, but with some processor's USB hardware and 
software in the mix.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com