4 ms·

Of course those 2 GHz octocore computers with 4 GiB of RAM have no chance in hell to react to impulses within nanoseconds or operate anything at 100 MHz. All sa

Of course those 2 GHz octocore computers with 4 GiB of RAM have no chance in hell to react to impulses within nanoseconds or operate anything at 100 MHz. All sacrificed at the altar of throughput.

dragontamer 10y ago
Well, that's true. Cellphone chips don't do that. But lets say... a 1GHz DSP (specialized chip designed to perform "digital signal processing") implementing an optimized FIR or IIR filter most certainly react within nanoseconds and pick out signals in the 100MHz range. That's still a general-purpose processor too. Switch to FPGAs or even ASICs (the fastest and most expensive of digital-logic designs), and you can probably get even faster. ---------- Analog can only get better accuracy by literally creating temperature-controlled cases for various components. (Think I'm kidding? https://www.vectron.com/products/literature_library/OCXO.pdf https://www.vectron.com/products/literature_library/OCXO.pdf) Analog hit the noise-floor decades ago.
dekhn 10y ago
a dedicated 2-3GHz processor can definitely receive a signal, turn it into an interrupt, and respond to it within nanoseconds. it's the OS that prevents that from happening.
- dragontamer 10y ago
  > it's the OS that prevents that from happening. Not quite. Its more about the difficulty of writing the code. A lot of OSes aren't realtime which can be part of the problem, but a careful administrator can tune Windows or Linux to be "more realtime". Consider this: most hardware is set up to DMA to RAM through the northbridge. It never touches the CPU, the hardware just writes the data directly to RAM (indeed: this is a good thing. When the CPU is executing from L1 cache, it isn't touching the RAM anyway). Then, the CPU gets an interrupt, and then it can read from RAM. It takes roughly 60 ns alone to access DRAM on a modern processor (https://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf https://software.intel.com/sites/products/collateral/hpc/vtu...), plus whatever time it took for the DMA to happen. NOW the CPU finally has the data in its cache and can start calculating. ------------ To fix this issue, you DMA directly onto the CPU's cache itself. http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/data-direct-i-o-technology-overview-paper.pdf http://www.intel.com/content/dam/www/public/us/en/documents/... That takes special device drivers, a lot of optimizing, a lot of thinking about latency.
  - dekhn 10y ago
    Obviously I'm talking about code that is only using L1, and touching only registers.
    - dragontamer 10y ago
      I see your point, but raise you this thought: Exactly what "received signal" exists inside of a CPU's L1 cache and register? In practice, any I/O of a modern CPU / Microprocessor is going to run through the Northbridge and most likely be dumped into DDR3 / DDR4 RAM. That's already 60ns of delay minimum that you've introduced into the system and you haven't even done any math yet! Building a digital system that responds within nano-seconds is difficult, while a purely passive LRC filter... taught in maybe ~2nd year or ~3rd year Electrical Engineering classes, can indeed respond within nanoseconds! -------------- I guess what I'm saying is... building Digital systems that respond within nanoseconds is certainly possible, but its specialized knowledge and requires specialized CPUs (aka: a Digital Signal Processor). Most programmers don't need to do that after all (write a damn login page again) I'm not exactly an expert on the ways of the DSP. I just know people who moved in that direction. Its an intriguing field and takes lots of study to be effective.
      - dekhn 10y ago
        I don't think we were talking about DSP... at least when I originally replied I was making the official point that a high frequency CPU doing single-clock-cycle reads of GPIOs, can respond in nanoseconds. I think you are talking about something different... The GPIOs are pins that are directly attached to the CPU. They are accessible by the CPU without requiring access to cache. Not denying that it's hard to do on a general purpose Intel CPU with its absurdly high clock rate. But anybody with a fast oscilloscope can tell you that fast microcontrollers have that kind of response time, too (10s of ns), because ops take a clock cycle, and 100MHz = 1ns.
        revelation 10y ago
        They tried this on an AM335x, a modern ARM Cortex A8 used on the BeagleBone Black for example. Clocked at 1 GHz and doing nothing else other than toggle a GPIO pin - it took 200 ns. This is for a fully integrated SoC. Merely due to various levels of interconnect within the CPU. Here is the slide for reference: http://imgur.com/a/sWyH5 http://imgur.com/a/sWyH5

Of course those 2 GHz octocore computers with 4 GiB of RAM have no chance in hell to react to impulses within nanoseconds or operate anything at 100 MHz. All sacrificed at the altar of throughput.

dragontamer 10y ago

Well, that's true. Cellphone chips don't do that. But lets say... a 1GHz DSP (specialized chip designed to perform "digital signal processing") implementing an optimized FIR or IIR filter most certainly react within nanoseconds and pick out signals in the 100MHz range. That's still a general-purpose processor too. Switch to FPGAs or even ASICs (the fastest and most expensive of digital-logic designs), and you can probably get even faster. ---------- Analog can only get better accuracy by literally creating temperature-controlled cases for various components. (Think I'm kidding? https://www.vectron.com/products/literature_library/OCXO.pdf https://www.vectron.com/products/literature_library/OCXO.pdf) Analog hit the noise-floor decades ago.

dekhn 10y ago

a dedicated 2-3GHz processor can definitely receive a signal, turn it into an interrupt, and respond to it within nanoseconds. it's the OS that prevents that from happening.

dragontamer 10y ago
> it's the OS that prevents that from happening. Not quite. Its more about the difficulty of writing the code. A lot of OSes aren't realtime which can be part of the problem, but a careful administrator can tune Windows or Linux to be "more realtime". Consider this: most hardware is set up to DMA to RAM through the northbridge. It never touches the CPU, the hardware just writes the data directly to RAM (indeed: this is a good thing. When the CPU is executing from L1 cache, it isn't touching the RAM anyway). Then, the CPU gets an interrupt, and then it can read from RAM. It takes roughly 60 ns alone to access DRAM on a modern processor (https://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf https://software.intel.com/sites/products/collateral/hpc/vtu...), plus whatever time it took for the DMA to happen. NOW the CPU finally has the data in its cache and can start calculating. ------------ To fix this issue, you DMA directly onto the CPU's cache itself. http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/data-direct-i-o-technology-overview-paper.pdf http://www.intel.com/content/dam/www/public/us/en/documents/... That takes special device drivers, a lot of optimizing, a lot of thinking about latency.
- dekhn 10y ago
  Obviously I'm talking about code that is only using L1, and touching only registers.
  - dragontamer 10y ago
    I see your point, but raise you this thought: Exactly what "received signal" exists inside of a CPU's L1 cache and register? In practice, any I/O of a modern CPU / Microprocessor is going to run through the Northbridge and most likely be dumped into DDR3 / DDR4 RAM. That's already 60ns of delay minimum that you've introduced into the system and you haven't even done any math yet! Building a digital system that responds within nano-seconds is difficult, while a purely passive LRC filter... taught in maybe ~2nd year or ~3rd year Electrical Engineering classes, can indeed respond within nanoseconds! -------------- I guess what I'm saying is... building Digital systems that respond within nanoseconds is certainly possible, but its specialized knowledge and requires specialized CPUs (aka: a Digital Signal Processor). Most programmers don't need to do that after all (write a damn login page again) I'm not exactly an expert on the ways of the DSP. I just know people who moved in that direction. Its an intriguing field and takes lots of study to be effective.
    - dekhn 10y ago
      I don't think we were talking about DSP... at least when I originally replied I was making the official point that a high frequency CPU doing single-clock-cycle reads of GPIOs, can respond in nanoseconds. I think you are talking about something different... The GPIOs are pins that are directly attached to the CPU. They are accessible by the CPU without requiring access to cache. Not denying that it's hard to do on a general purpose Intel CPU with its absurdly high clock rate. But anybody with a fast oscilloscope can tell you that fast microcontrollers have that kind of response time, too (10s of ns), because ops take a clock cycle, and 100MHz = 1ns.
      - revelation 10y ago
        They tried this on an AM335x, a modern ARM Cortex A8 used on the BeagleBone Black for example. Clocked at 1 GHz and doing nothing else other than toggle a GPIO pin - it took 200 ns. This is for a fully integrated SoC. Merely due to various levels of interconnect within the CPU. Here is the slide for reference: http://imgur.com/a/sWyH5 http://imgur.com/a/sWyH5