Forums

I/O latency for systems not using a RTOS

Started by Bruce Varley January 19, 2012
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