Author Topic: Why don't desktop computers have realtime subsystems?  (Read 6667 times)

0 Members and 1 Guest are viewing this topic.

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Why don't desktop computers have realtime subsystems?
« Reply #25 on: November 10, 2018, 09:25:42 pm »
You need a Real Time OS (like QNX) on top of the hardware.  Windows/Linux are not RT OS.

QNX was the first thing I thought of as well.  Back then I remember a company (VentrureComm (SP)) who obtained the source for parts of Windows NT in order to create a RT version of the OS.  In return MS would get their source code.   Then again, that has been a VERY long time ago.   My old LeCroy uses an Intel 486DX and they ran PSOS on it.   

I've used Windows for various synchronous control systems.   At the time I made this video, still had a P4 running Windows XP.  I hate upgrading PCs. I broke down and bought a new PC a couple of years ago.  The amount of computing power is incredible.  I ended up changing the whole software architecture.     

https://youtu.be/Lqa2lnxoIsU?list=PLZSS2ajxhiQBvWvqMVLdRQMjGofKpQUJr

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Why don't desktop computers have realtime subsystems?
« Reply #26 on: November 10, 2018, 09:36:43 pm »
The original IBM PCs had near non-existent audio, even compared to other computers of that era it's pathetic.
Sound cards were an afterthought, both in hardware and software.

I wonder if the 10ms latency comes from IRQ polling, or is a byproduct of the sample rate.

While that's true, the IBM PC was designed as a business machine, not a toy. I can hardly fault the engineers for not bothering to include better sound capabilities. The mainframes and terminals that dominated businesses of the day didn't have fancy audio capabilities either, that was only in the home computers and was used almost exclusively for games. The Macintosh was one of the first PCs aimed at professionals to have decent audio playback abilities but even then it was some time before they offered audio input to get sounds onto the computer.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #27 on: November 10, 2018, 09:56:37 pm »
Because they never considered real-time applications worthy of dedicating resources to at the start. So both OS and driver writers have tons of tools which can just lock the CPU for aeons with the absolute knowledge they won't be interrupted and they have made a lot of use of those tools. Fixing this after the fact means fixing a whole lot of code and deprecating a lot of old drivers, for a small niche application. Microsoft has never considered it important enough.

That said, Linux is getting there with preempt-rt as long as you stick with mainline (NVIDIA for all their supposed embedded focus frequently makes a mess of it). There's also Xenomai Cobalt which is a realtime co-kernel for Linux, which just takes control away from the kernel and drivers whenever it wants, which needs a lot of patching of the kernel (and some prayers for third party drivers). Also it's a tough environment to develop for and doesn't do much good for existing Linux applications ... Bela did it for audio, but you'll have to write your own effects for their framework.
« Last Edit: November 10, 2018, 10:01:02 pm by Marco »
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 8973
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: Why don't desktop computers have realtime subsystems?
« Reply #28 on: November 10, 2018, 10:25:19 pm »
Case in point: pulseaudio.  It runs in userland like any other process and shims itself between the kernel's audio system (ALSA) and your programs.  The only way it can do this reliably is by introducing more latency.  This allows it lots of time to apply effects and features whilst not requiring any special privileges or changes to your kernel.  Sidenote: pulseaudio sucks for many reasons, avoid it if you can, latency is only one of its common issues.
I have had just plain ALSA on my PC since it's easier to get bit perfect playback that way.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Why don't desktop computers have realtime subsystems?
« Reply #29 on: November 10, 2018, 11:42:04 pm »
Real-time kernels/real-time scheduling are not adapted to general-purpose desktop computing. That's the essential and main reason.
Another reason is that the use cases where low latency is really important are still kind of secondary on desktop computers: you'll need that for real-time playing of virtual instruments or audio effects. If you're just recording/playing, latency doesn't matter as it gets compensated by software. Whereas real-time playing of virtual instruments and effects is becoming a thing, we can still largely do without it by using dedicated hardware.

That said, both Windows and Linux (I don't know MacOS well, but I'd guess that it's the same) have improved a lot regarding average latency. Getting a reliable 10 ms audio latency is usually no problem with decent hardware. Software, beyond the OS, also plays an important role: you'll get reliable performance only with well written drivers and well written application software. Not all audio software is created equal!

As for me, I find that a 10 ms latency is acceptable for real-time playing. Anything above this starts becoming noticeable. Of course this will depend on each individual to a degree.

If you want to get latencies under that in a reliable manner, you can use Linux and a Linux real-time kernel such as linux-rt. I've done real-time audio processing on Linux with linux-rt and you can get latencies as low as 2-3 ms RELIABLY (no drop-out) even with USB audio interfaces (as long as they are not crap).

There are other real-time oriented OSs out there, but frankly Linux with a linux-rt kernel does the job and is a good start.

 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Why don't desktop computers have realtime subsystems?
« Reply #30 on: November 10, 2018, 11:46:19 pm »
When people say that desktop machines should have hard real time capabilities as standard, they aren't really allowing for the huge impact cache has on the performance of modern machines. Turn off the caches and its easy to make something hard real time, but rather slow. Turn on the caches, and you turn on a bunch of difficulties.
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: Why don't desktop computers have realtime subsystems?
« Reply #31 on: November 11, 2018, 12:21:37 am »
Cache, TLB, thermal throttling (Including weird things like thermal throttling the dram, yes it is a thing!), SMM mode, PCI bus contention (Graphics card driver authors, looking at YOU), cackhanded driver authors generally... The pain goes on.

Fortunately, for audio we don't really need  formal hard realtime, a missed deadline once every few weeks will not kill anyone.

Regards, Dan.
 

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 4391
  • Country: dk
Re: Why don't desktop computers have realtime subsystems?
« Reply #32 on: November 11, 2018, 12:48:08 am »
I don't see the problem. 10ms an order of a magnitude is faster than the reaction time of a human.

The problem is real, especially when someone plays an instrument and the sound does not come when the brain expects it.

If the delay is too big, even the speech is impaired severely.  Just for the fun of it:



 :-DD

I've heard that people who stutter don't when they hear themselves delayed enough, something about it "breaking"
the feedback loop between speech and ear 


 
The following users thanked this post: RoGeorge

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Why don't desktop computers have realtime subsystems?
« Reply #33 on: November 11, 2018, 02:37:21 am »
LITTLE TRICK FOR MIDI LATENCY WHEN USING AN FTDI RS232 converter with generic midi-RS232 interface:
See screenshot photo below:
Go into hardware 'Device manager', 'USB serial comport', 'Port Settings', 'Advance' and select '1 ms' for 'Latency Timer' and your RS232 port will respond 16x as fast!

However, it does eat up around 1% of a cpu core whenever the port is in use, regardless of the software, it can make other tasks jitter or slow down since the RS232 port will take priority.  2ms delay solves this problem, but then it is only 8x as responsive as the default 16.

Also, your RS232 port will now transmit and receive even single byte fast enough to create a motor speed control loop regulator by PC controlled loop.  (I know this is a dumb method, but, I was once in a spot where I needed a quick fix for testing before re-programming an external microcontroller and with a sub 1ms loop for a treadmill size motor with flywheel, it worked)
« Last Edit: November 11, 2018, 02:53:16 am by BrianHG »
 
The following users thanked this post: nugglix, RoGeorge

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Why don't desktop computers have realtime subsystems?
« Reply #34 on: November 11, 2018, 02:47:41 am »
When recording live music this 10ms delay makes it difficult or impossible to to do real-time monitoring as the musician gets perturbed by the lag which affects their timing.
I don't see the problem. 10ms an order of a magnitude is faster than the reaction time of a human. It's also quicker than anyone can physically press a button or key. Take a digital stop watch, reset it to zero and press the start/stop button twice, as quickly as possible. If you can start and stop the clock in under 0.03s, that's 30ms, then you're doing well.

Don't be too sure.  In my father's office, we were forced to keep his secretary's computer running 'today' on Win98 with a PS2 keyboard, because, when she entered invoice numerical prices while typing invoice values, she typed too fast for the keyboard to respond in time and even display the figures on modern 32 bit or 64 bit OSs.  When I say fast, I mean you could not see her finger key contacts with your eyes and the audible sound was nothing but a rattle of noise.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16545
  • Country: us
  • DavidH
Re: Why don't desktop computers have realtime subsystems?
« Reply #35 on: November 12, 2018, 01:08:13 am »
I don't see the problem. 10ms an order of a magnitude is faster than the reaction time of a human. It's also quicker than anyone can physically press a button or key. Take a digital stop watch, reset it to zero and press the start/stop button twice, as quickly as possible. If you can start and stop the clock in under 0.03s, that's 30ms, then you're doing well.

10 milliseconds may be faster than the reaction time but it is 2 orders of magnitude larger than the difference in time that the human nervous system can anticipate which is what a musician does when keeping time.

https://www.electronicdesign.com/defense/whats-all-why-stuff-anyhow

If a ball at the end of your arm, at a radius of 3 ft., is moving at 90 mph or 132 ft./s, it will change its ANGLE by 0.0044 radians, or 0.252°, every 100 µs. And an angle of 0.0044 radians corresponds with an uncertainty of 6.4 in. (±3.2 in.), after the ball—or rock—has gone 60 ft.

Don't be too sure.  In my father's office, we were forced to keep his secretary's computer running 'today' on Win98 with a PS2 keyboard, because, when she entered invoice numerical prices while typing invoice values, she typed too fast for the keyboard to respond in time and even display the figures on modern 32 bit or 64 bit OSs.  When I say fast, I mean you could not see her finger key contacts with your eyes and the audible sound was nothing but a rattle of noise.

I touch type fast enough for this to be a problem including on the forums here which trash the performance of the browser with scripts and animations.  Modern computers are *slower* when interface latency is measured.  The 32-bit 50MHz ARM based HP50g is *slower* than the ancient 4-bit 2MHz Saturn based HP48g.  Tell me again how ARM processors are power competitive with the 8-bit processors they replace; they are not.



A real time operating system is not incompatible with desktop or workstation usage; check out BeOS.  But relaxed timing and increased buffering has minor performance advantages and makes things easier.  Some delays like going through an FIR filter are unavoidable.

« Last Edit: November 12, 2018, 01:17:02 am by David Hess »
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Why don't desktop computers have realtime subsystems?
« Reply #36 on: November 12, 2018, 02:26:26 am »
I'm not so sure that's due to any fault with the processor. More likely it's a matter of the newer processor being so powerful that developers don't think they need to bother optimizing anything. The software industry as a whole has been in a race to the bottom, the goal now being to make things just good enough that people will still pay for them.
 
The following users thanked this post: drussell

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #37 on: November 12, 2018, 10:19:16 am »
People get deep deep sub millisecond latency with preemp-rt on SBCs ... it's not the processor, it's a problem of the complexity of the OS and the tools which have been given to driver and OS subsystem writers.

Basically real time inverts the way things are done normally. Users get real-time, driver and OS developers get screwed with unbounded latencies for any section of their code ... while they have been used to be able to take control for milliseconds at a time. They don't like that, they are lazy bums like the rest of us.
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #38 on: November 12, 2018, 01:28:28 pm »
Computers can do sub-ms timing, but not predictably and are tuned for the average-case performance.

In Windows/C#.NET you can call Thread.Sleep(1), but have Windows return to your thread after 1ms, but also after 16ms. I think 16ms was the lower bound for which behaviour is defined (anything above works pretty well).

In real-time you want to bound the worst-case, which is a whole different task. Most RTOS are capable of more accurate timing than PCs, but may still get stuck on shared resource problems and priority inversion (which is more of a software design problem than something an RTOS will fix for you).


When recording live music this 10ms delay makes it difficult or impossible to to do real-time monitoring as the musician gets perturbed by the lag which affects their timing.
I don't see the problem. 10ms an order of a magnitude is faster than the reaction time of a human. It's also quicker than anyone can physically press a button or key. Take a digital stop watch, reset it to zero and press the start/stop button twice, as quickly as possible. If you can start and stop the clock in under 0.03s, that's 30ms, then you're doing well.

Don't be too sure.  In my father's office, we were forced to keep his secretary's computer running 'today' on Win98 with a PS2 keyboard, because, when she entered invoice numerical prices while typing invoice values, she typed too fast for the keyboard to respond in time and even display the figures on modern 32 bit or 64 bit OSs.  When I say fast, I mean you could not see her finger key contacts with your eyes and the audible sound was nothing but a rattle of noise.


USB devices need buffers to bridge the gap between the USB host polling the device. A PS2 keyboard doesn't have a buffer and will output a serial code straight to the machine, which will need to handle an IRQ and process the key. Maybe thats the problem.. too much software for the hardware to handle. Gamers still love PS2 keyboards for this IRQ-like response time, because even configuring the USB host to 1000Hz / 1ms poll intervals is not good enough for them.

I've seen sub-10ms timing between keystrokes (muscle memory) while typing myself, and I can reach ~600 - 700 keystrokes per minute on a good day.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #39 on: November 12, 2018, 02:33:00 pm »
Computers can do sub-ms timing, but not predictably and are tuned for the average-case performance.
I thought it was obvious from context, but when I said people get deep deep sub millisecond latency with preemp-rt on SBCs I meant they get that as max latency.
 

Offline glarsson

  • Frequent Contributor
  • **
  • Posts: 814
  • Country: se
Re: Why don't desktop computers have realtime subsystems?
« Reply #40 on: November 12, 2018, 02:51:01 pm »
Computers can do sub-ms timing, but not predictably and are tuned for the average-case performance.
I thought it was obvious from context, but when I said people get deep deep sub millisecond latency with preemp-rt on SBCs I meant they get that as max latency.
I have been doing real time systems for many years. For me one millisecond is a long time.
Example of an application that has been in use for over ten years: Hardware is a SPARC T2 server with Solaris operating system. Application runs ten threads and each thread needs to react to events, and do I/O, with a latency of max 64us. All ten threads runs in one CPU core. Note that all ten threads might need to do I/O in the same 64us "slot".
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #41 on: November 12, 2018, 04:58:21 pm »
Computers can do sub-ms timing, but not predictably and are tuned for the average-case performance.
I thought it was obvious from context, but when I said people get deep deep sub millisecond latency with preemp-rt on SBCs I meant they get that as max latency.
I wasn't commenting to preemp-rt in particular, but yes agreed. A "computer" (as in desktops, laptops, tablets, smartphones) and SBC with RT kernels are totally different worlds.

Even then, a RTOS can't provide miracles neither to any application. In desktops we're used (or like to see!) full utilization of CPU and hardware resources when we strive the optimal average case performance. For real-time that would be a very bad thing to do.

Most schedulers used today in real-time environments need "spare" CPU time to meet their deadlines. Optimal schedulers exist.. but unfortunately they aren't available in preempt-rt (by default). Or in fact many of the industry RTOS, because we're not used to programming with "deadlines" in mind (which, admittedly, would be relatively easy to implement for periodic tasks).
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #42 on: November 12, 2018, 06:33:28 pm »
It's just a question of being cooperative, almost all of the code in OS's which doesn't allow itself to be interrupted does so unnecessarily ... you don't really lose anything by designing it to be realtime compatible, except needing to pay better developers and bullying the laziest ones.

As glarsson reminded us, Solaris did realtime on the desktop a long time ago.
 

Offline John B

  • Frequent Contributor
  • **
  • Posts: 795
  • Country: au
Re: Why don't desktop computers have realtime subsystems?
« Reply #43 on: November 12, 2018, 08:42:02 pm »
I usually run a buffer of 128 samples at 48kHz. Its a good compromise for real time performing, while still allowing for non-predictable tasks that suddenly take CPU run time, causing sample drop outs.

My software gives me the following info:

Input latency: 3.6ms
Processing latency: 2.7ms (128 samples @ 48kHz)
Output latency: 0.9ms

Total: 7.2ms

Ill echo what's said previously. Even 7.2ms is borderline acceptable, depending on the instrument. Percussive sounds are the most demanding on latency.
 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 6202
  • Country: de
Re: Why don't desktop computers have realtime subsystems?
« Reply #44 on: November 12, 2018, 08:53:36 pm »
Quote
Why don't desktop computers have realtime subsystems?
The closest we can get (without dropping a modern OS) is a kernel that lets us cheat the normal process scheduler.

Didn't the NeXT computers have 56000 DSP subsystems for audio processing, back in the early 90s? I have no idea what software the 56000 was running, however. (The NeXT itself obviously was running NeXtStep, a Unix derivative.)
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Why don't desktop computers have realtime subsystems?
« Reply #45 on: November 12, 2018, 09:02:22 pm »
Didn't the NeXT computers have 56000 DSP subsystems for audio processing, back in the early 90s? I have no idea what software the 56000 was running, however. (The NeXT itself obviously was running NeXtStep, a Unix derivative.)
The NeXT machines did have a 56k in them, but I don't think they ever got it doing very much. There was a surge of activity in about 1993, where DSP makers, including Motorola with the 56k, worked closely with MS to make a hardware DSP block a normal adjunct function in Windows machines. It never went very far, and the DSP functions, like soft modems, ended up running on the main CPU.
 

Offline jmelson

  • Super Contributor
  • ***
  • Posts: 2758
  • Country: us
Re: Why don't desktop computers have realtime subsystems?
« Reply #46 on: November 12, 2018, 11:23:19 pm »
I ask this question because Windows/Linux/IOS/Android all have a 10ms or thereabouts latency when it comes to doing real-time audio processing.
There are at least THREE real time options on some Linux kernels.  RTAI, Xenomai and RT-Preempt.  At one time, RTAI was far superior, but now at least RT_Preempt has caught up.  Generally, latency can be down to a couple microseconds, with +/- 10 us jitter using RT_Preempt.  On SOME X86 hardware, the jitter can be down to +/- 5 us with RTAI.

I use RTAI and RT_Preempt with the LinuxCNC motion control (CNC) system.

The results on the Beagle Board Black show about twice the jitter figures given above, which is still pretty good.

Note that due to BIOS features, some specific hardware models (motherboards) perform horribly in this regard, and others that seem quite similar do very well.  The above RT packages have latency/jitter tests that can tell you very quickly how well a specific combo of OS/RT package/CPU/BIOS perform.

Jon
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16545
  • Country: us
  • DavidH
Re: Why don't desktop computers have realtime subsystems?
« Reply #47 on: November 13, 2018, 12:40:56 am »
There is something which I forgot to mention which is a major problem with x86 systems as far as latency and real time performance.

SMM (System Management Mode) completely trashes real time performance independent of what the operation system and hardware is capable of.  There are special BIOSes which keep this under control for applications where real time performance matters but the performance of consumer systems is random leaning toward as bad as they can get away with.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: Why don't desktop computers have realtime subsystems?
« Reply #48 on: November 13, 2018, 02:55:15 am »
There are special BIOSes which keep this under control for applications where real time performance matters but the performance of consumer systems is random leaning toward as bad as they can get away with.
Asus Chromebox 3 should be pretty good, comes with Google's version of coreboot and can be reflashed with normal coreboot.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Why don't desktop computers have realtime subsystems?
« Reply #49 on: November 13, 2018, 05:02:38 am »
With ISA based sound cards, or even the appropriate USB ones on a dedicated channel, it should be possible to trick Windows OS and get real-time microsecond performance, however, it would only be in your own app, there would be no windows system audio without extra programming and 1 cpu core would be pretty much eaten alive stuck at around 10% usage all the time.  Though, you would never need to worry about buffer under-run errors if programmed properly.


Note, 5 years ago, In Win7 64 bit, I had a test display rendering tool where I manually swapped the video-cards full graphics screen buffer timed to one of the system's precision timers which operate in the microsecond range.  I was able to swap page buffers on specific lines of video on the screen with other tasks running.  Meaning, a valid Window  app can time and interrupt to call system functions and control connected hardware with accuracy down to a 65Khz line of video without fail.  With this, you can make an audio driver which responds within 2 to 4 audio samples if you care to write your own sound driver.

So, there is no need for a real-time OS to make a super fast/short sound buffer sound driver.
« Last Edit: November 13, 2018, 05:10:22 am by BrianHG »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf