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

Reply to
Bruce Varley
Loading thread data ...

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.

Reply to
David Brown

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.

Reply to
Mel Wilson

well, actually you can use some patch to make linux hard real time. For example Linux-RTAI

Bye Jack

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

years,

and

a

and

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

formatting link

Reply to
Sink0

be

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

Reply to
langwadt

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.

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.

Reply to
David Brown

=

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

formatting link

Reply to
Sink0

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
Reply to
Simon Clubley

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.
 Click to see the full signature
Reply to
Tim Wescott

Thanks for the information, everyone, it's very useful. I've already purchased hardware that I thought would serve, only to find that timing issues have probably invalidated its use. As per the request/suggestion above, here'a bit more info on the situation.

My envisaged config will have two components, a 'client' which will be a SBC, and a 'Master', which will be a tablet. The musical signals that need controlled latency will come into the client via a UART, and leave the same way. The client does some fairly rudimentary processing, such as as interspersing control sequences.

The USB is purely for communication between the client and the master tablet, things like selecting instrumentation and manual stop/starts. None of the information passing between these is particularly time critical. My concern is delays that (reportedly) can occur from UART input to UART output within the client, running Linux.

Why am I considering USB at all? Because AFAIAA, tablets don't come with any alternative interfaces that will easily connect to a SBC micro.

Thanks again to everyone who took the time to input.

Reply to
Bruce Varley

There are several real-time extensions for Windows (like INtime) that are basically RTOSes running Windows (or Linux) basically as a low priority process. I've been involved with some projects that used those extensions. The real problem is not so much the software, but the PC hardware. On one PC you get very predicable timing, on another it is all over the place, even when the RTOS is assigned its own core and hardware resources. In modern PC's there are a lot things the affect the response time (power management features, shared busses, busmaster DMA, caches...etc), some you can control others you can't or don't even really know about.

15 years a ago on a project we used an home-brew embedded board clocked at 15MHz with a home-brew OS. We understood the hardware and the processor very well (because it was so simple) and could guarantee response times within a few cycles. On that board we ran applications with hard real-time requirements that even on todays PC's with hundreds of times more processing power difficult if not impossible to do, simply because it is hard, if not impossible, to guarantee response times in the uS range on an arbitrary PC platform, regardless what software you use. As systems become more complex it becomes exceedingly more difficult to give hard guarantees.
Reply to
Dombo

So the master talks to the client via USB, and the client talks to some unnamed device via UART?

You could go with a plain-vanilla SBC without on-board USB, and use a serial-to-USB converter. This will save you from delay problems on the client side -- but as most tablet PCs either run Android (which is Linux), or Windows (which is a horror), you're right back to the same worries about delay.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.