4 ms·

That's a different and unrelated topic. If you're concerned about how fast device driver code can respond, well you can get a lot done in 0.5 ms even with the C

That's a different and unrelated topic. If you're concerned about how fast device driver code can respond, well you can get a lot done in 0.5 ms even with the CPU running at 800 MHz or whatever the idle clock is.

vardump 4y ago
Says someone who hasn't debugged a slow Windows graphics related ISR (interrupt), hogging the same CPU core where the your interrupt was supposed to be. (Also, whatever happened to that 50 µs ISR execution time limit? I guess it doesn't apply, if you're Microsoft. Then again, there was some GPU vendor code running as well in the call stack...) 0.5 ms is not really much on Windows.
- clamchowder 4y ago
  I meant it's unrelated to how fast a CPU clocks up. If something is taking longer than 0.5 ms, you shouldn't be doing it in the ISR. Queue up a DPC and do your longer running processing there, or send it to user space. And yeah it might not be your fault if another driver's ISR was hogging the CPU core. That's just a case of a badly written driver screwing up the world for everyone, because they're not supposed to be doing long running stuff in an ISR in the first place. https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/example-15--measuring-dpc-isr-time https://docs.microsoft.com/en-us/windows-hardware/drivers/de... says an ISR shouldn't run longer than 25 microseconds. 0.5 ms is an order of magnitude off. Not something going from 800 MHz to locked 4 GHz will fix.
  - vardump 4y ago
    My ISRs execute under 15 µs, some are as fast as 2 µs. I'm well aware of the DPC queueing. > ISR shouldn't run longer than 25 microseconds Weird, I think I read 50 microseconds somewhere else. Maybe I just remember it wrong? > 0.5 ms is an order of magnitude off. Not something going from 800 MHz to locked 4 GHz will fix. 0.5 ms is actually not that far fetched with higher priority interrupts masking and the delay for Windows ISR dispatching. There are also SMM missing time black holes occasionally. Windows isn't a real-time OS for sure! Although can't blame SMMs on Windows.
chaps 4y ago
The interrupts are whatever, but the linux scheduler can do some really strange things with thrashing cpu frequencies, all while moving from core to core. So if I have a program running a core at 100%, the scheduler decides to move it to another core, meaning context switching, cache misses, interrupts, frequency scaling, etc. It adds up!
LoganDark 4y ago
When my power supply isn't properly connected (i.e. partially but not fully), the CPU locks itself to 799.97MHz or so, until I reconnect it. Is that related to the idle clock you mention?
- jeffbee 4y ago
  That’s happening because your BMC is asserting PROCHOT which sends the CPU to its lowest possible clock speed.

vardump 4y ago

Says someone who hasn't debugged a slow Windows graphics related ISR (interrupt), hogging the same CPU core where the your interrupt was supposed to be. (Also, whatever happened to that 50 µs ISR execution time limit? I guess it doesn't apply, if you're Microsoft. Then again, there was some GPU vendor code running as well in the call stack...) 0.5 ms is not really much on Windows.

clamchowder 4y ago
I meant it's unrelated to how fast a CPU clocks up. If something is taking longer than 0.5 ms, you shouldn't be doing it in the ISR. Queue up a DPC and do your longer running processing there, or send it to user space. And yeah it might not be your fault if another driver's ISR was hogging the CPU core. That's just a case of a badly written driver screwing up the world for everyone, because they're not supposed to be doing long running stuff in an ISR in the first place. https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/example-15--measuring-dpc-isr-time https://docs.microsoft.com/en-us/windows-hardware/drivers/de... says an ISR shouldn't run longer than 25 microseconds. 0.5 ms is an order of magnitude off. Not something going from 800 MHz to locked 4 GHz will fix.
- vardump 4y ago
  My ISRs execute under 15 µs, some are as fast as 2 µs. I'm well aware of the DPC queueing. > ISR shouldn't run longer than 25 microseconds Weird, I think I read 50 microseconds somewhere else. Maybe I just remember it wrong? > 0.5 ms is an order of magnitude off. Not something going from 800 MHz to locked 4 GHz will fix. 0.5 ms is actually not that far fetched with higher priority interrupts masking and the delay for Windows ISR dispatching. There are also SMM missing time black holes occasionally. Windows isn't a real-time OS for sure! Although can't blame SMMs on Windows.

chaps 4y ago

The interrupts are whatever, but the linux scheduler can do some really strange things with thrashing cpu frequencies, all while moving from core to core. So if I have a program running a core at 100%, the scheduler decides to move it to another core, meaning context switching, cache misses, interrupts, frequency scaling, etc. It adds up!

LoganDark 4y ago

When my power supply isn't properly connected (i.e. partially but not fully), the CPU locks itself to 799.97MHz or so, until I reconnect it. Is that related to the idle clock you mention?

jeffbee 4y ago
That’s happening because your BMC is asserting PROCHOT which sends the CPU to its lowest possible clock speed.