ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Linux Foundation Begins Major Focus on Real Time Linux

    News
    linux linux foundation real time linux
    6
    26
    4.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • DashrenderD
      Dashrender @scottalanmiller
      last edited by

      @scottalanmiller said:

      My dad @SonshineAcres used to do hard core real time systems (no operating system.) They did RT systems so sensitive that they could not have code to log what was happening as the logging would break the real time latency needs. So to see what performance issues were happening they would need to put an oscilloscope on the CPU as different CPU commands produce different voltages. Since the CPU was cycling commands you could set the oscilloscope to repeat on a timer (frequency) which would show a CPU voltage pattern and you could tell if the command sequence had been chanced.

      That seems old school, I'm assuming today that a hand off to a second processor could handle the monitoring such as to not affect the RT function?

      scottalanmillerS 1 Reply Last reply Reply Quote 0
      • scottalanmillerS
        scottalanmiller @MattSpeller
        last edited by

        @MattSpeller said:

        @scottalanmiller I did similar in college with QNX RTOS (later made famous by RIM) and (ancient / decrepit by today's standards) PIC microprocessors.

        Been a while but I ran QNX back in the day too.

        1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @Dashrender
          last edited by

          @Dashrender said:

          @scottalanmiller said:

          My dad @SonshineAcres used to do hard core real time systems (no operating system.) They did RT systems so sensitive that they could not have code to log what was happening as the logging would break the real time latency needs. So to see what performance issues were happening they would need to put an oscilloscope on the CPU as different CPU commands produce different voltages. Since the CPU was cycling commands you could set the oscilloscope to repeat on a timer (frequency) which would show a CPU voltage pattern and you could tell if the command sequence had been chanced.

          That seems old school, I'm assuming today that a hand off to a second processor could handle the monitoring such as to not affect the RT function?

          1. Second processor cannot do what you are thinking, though. It has no way to talk to the first processor like that without interrupting it. So while CPUs have tons more power today, they would introduce the overhead by talking to each other still.
          DashrenderD 1 Reply Last reply Reply Quote 0
          • DashrenderD
            Dashrender @scottalanmiller
            last edited by

            @scottalanmiller said:

            @Dashrender said:

            @scottalanmiller said:

            My dad @SonshineAcres used to do hard core real time systems (no operating system.) They did RT systems so sensitive that they could not have code to log what was happening as the logging would break the real time latency needs. So to see what performance issues were happening they would need to put an oscilloscope on the CPU as different CPU commands produce different voltages. Since the CPU was cycling commands you could set the oscilloscope to repeat on a timer (frequency) which would show a CPU voltage pattern and you could tell if the command sequence had been chanced.

            That seems old school, I'm assuming today that a hand off to a second processor could handle the monitoring such as to not affect the RT function?

            1. Second processor cannot do what you are thinking, though. It has no way to talk to the first processor like that without interrupting it. So while CPUs have tons more power today, they would introduce the overhead by talking to each other still.

            wow, even that single cycle would be to much, eh?

            scottalanmillerS 1 Reply Last reply Reply Quote 0
            • scottalanmillerS
              scottalanmiller @Dashrender
              last edited by

              @Dashrender said:

              @scottalanmiller said:

              @Dashrender said:

              @scottalanmiller said:

              My dad @SonshineAcres used to do hard core real time systems (no operating system.) They did RT systems so sensitive that they could not have code to log what was happening as the logging would break the real time latency needs. So to see what performance issues were happening they would need to put an oscilloscope on the CPU as different CPU commands produce different voltages. Since the CPU was cycling commands you could set the oscilloscope to repeat on a timer (frequency) which would show a CPU voltage pattern and you could tell if the command sequence had been chanced.

              That seems old school, I'm assuming today that a hand off to a second processor could handle the monitoring such as to not affect the RT function?

              1. Second processor cannot do what you are thinking, though. It has no way to talk to the first processor like that without interrupting it. So while CPUs have tons more power today, they would introduce the overhead by talking to each other still.

              wow, even that single cycle would be to much, eh?

              Depends, when you are pushed to the limits of the CPU, more than it can handle is still... more. But it is a lot more than a cycle too. Doing something like logging or relaying a bit of information is a lot of cycles. If you are trying to use zero extra, this would be a lot extra. All relative.

              1 Reply Last reply Reply Quote 0
              • scottalanmillerS
                scottalanmiller
                last edited by

                Here it is: Understanding the Tradeoffs in Latency and Throughput

                1 Reply Last reply Reply Quote 1
                • 1
                • 2
                • 2 / 2
                • First post
                  Last post