Linux Foundation Begins Major Focus on Real Time Linux
-
@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?
-
@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.
-
@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?
- 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.
-
@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?
- 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?
-
@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?
- 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.
-
