5 ms·

> I think what you're missing is that all of the overlapped I/O scenarios completions you describe all originate from a hardware interrupt from some device, lik

> I think what you're missing is that all of the overlapped I/O scenarios completions you describe all originate from a hardware interrupt from some device, like a network adapter. The comment literally says "packets came in from client machines". And they wanted to service these immediately, not 16ms later. Which is exactly what I'm describing. Timing requirements don't arise out of the void. Either they're externally mandated based on the wall clock (which is generally for human-oriented things like multimedia) in which case you should probably use something like a periodic multimedia timer, or they're based on other internal events (I/O, user input, etc.) that you can act on immediately. In neither case does Sleep() seem like the right solution, regardless of its accuracy... Very few real-world exceptions exist to this. In fact the only example I can think of off the top of my head (barring ones whose solution is busy-looping) is "I need to write a debugger that waits for a memory location to change and lets me know ASAP", in which case, I guess polling memory might be the way to go? But it would seem you would want event-based actions...

gambiting 6y ago
Well, (and I don't mean it sarcastically) clearly you know more about this that me or any of our engineers do, because we couldn't find a way to do this. Yes, I knew that packets coming in trigger a hardware interrupt that wakes up the thread processing them - but as we had multiple other threads actually decoding this data, there isn't a good way to wake those up from the receiving thread. The sleep(1) and check for work was the best solution, as every other method/API we tried had the same problem of ultimately being limited by the system timer interrupt, and we couldn't get around it in any way. I don't want to say that there definitely isn't a way to do this - but we never found it.
- mehrdadn 6y ago
  I see. It's hard to say if I'm missing something but given what I've heard so far I think what you want is I/O completion ports (though there are other ways to solve this). They're basically producer-consumer queues. I highly recommend looking into them if you do I/O in Windows. They're more complicated but they work very well. Here's a socket example: https://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancediomethod5i.html https://www.winsocketdotnetworkprogramming.com/winsock2progr...
  - vardump 6y ago
    I've written Windows device drivers, so I think I could say I'm rather intimately familiar with Windows I/O request (IRP) processing. Sounds like people in gambiting's company are the same. I/O completion ports is an API for getting better efficiency between kernel and userland I/O. Batching, better scheduling and avoiding WFMO bottleneck. It's great, but it doesn't really have anything to do with timers. The bottom line here is that Windows timer behavior has changed. This is terrifying.
    - mehrdadn 6y ago
      It "has nothing to do with timing" in the sense that it doesn't let you choose how much delay to incur. It most certainly does "have something to do with timing" in that it lets you do I/O immediately, without polling or incurring system timer interrupt delays... which is precisely what his description of the problem required. It's kind of bizarre to see you trying to interject into it to argue with me as if you know his situation better than himself while even contradicting his descriptions in the process. I feel like the discussion already concluded on that topic. I'll leave this as my last comment here.
      - vardump 6y ago
        > without polling or incurring system timer interrupt delays... which is precisely what his description of the problem required Except sometimes polling is your only option. Your scenario works great, if the hardware supports that use case and you're not using some intermediate software layer that prevents you from taking full advantage of the hardware. Other scenario is when Windows is being used to control something time critical. I fully agree one shouldn't do that, but sometimes you just have to. The new timer change really hurts here. In other words, we don't live in the perfect world, but still need to get the software working. I also feel like we're somewhat talking past each other. > It's kind of bizarre to see you trying to interject into it to argue with me as if you know his situation better than himself while even contradicting his descriptions in the process. I do know highly similar cases I've had to deal with. Not audio processing, but similarly tight deadlines. It was very painful to get it working correctly.
vardump 6y ago
Unfortunately, sometimes timing requirements do arise "out of the void" to adhere, because not all hardware is perfect. Also sometimes you just need to do timing sensitive processing. I guess you could argue one shouldn't use Windows for that, but unfortunately sometimes we developers don't really have a choice. Doing what you're told pays the bills. :-)
- mehrdadn 6y ago
  I think you misunderstood. If you want "timing sensitive processing", that's what you can and should expect to use events or multimedia timers for. That way you can actually expect to meet timing guarantees. Using Sleep() and depending on it for correctness in such situations (regardless of its accuracy) is kind of like using your spacebar to heat your laptop... it doesn't seem like the right way to go on its face, even if there was something to guarantee it would work: https://xkcd.com/1172/ https://xkcd.com/1172/
  - vardump 6y ago
    > that's what you can and should expect to use events or multimedia timers for I don't want to use a deprecated API call, timeSetEvent. > Using Sleep() and depending on it... Absolutely no one was using Sleep for timing. It just used to be that all Windows timer mechanisms are really the same thing, and Sleep(1) was an easy way to quickly test actual timing precision. Obviously Windows 10/2004 changed all this.
    - jlokier 6y ago
      > I don't want to use a deprecated API call, timeSetEvent. That's not what dataflow is saying to use. The phrase is "events or timers", not "timer events". gambiting describes this scenario: The hardware (network) does interrupt the CPU and supplies an incoming packet to the receiver thread, which does not use a timer. Then the receiver thread wants to send it to a worker thread. It sounds like gambiting's implementation has the worker threads polling a software queue using a sleep-based timer, to pick up work from the receiver thread. Unless there's something not being said in that picture, the receiver should be sending an event to a worker thread to wake the worker instantaneously, rather than writing to memory and letting the workers get around to polling it in their own sweet, timer-dependent, unnecessarily slow time. Given that it's described as audio data which must be processed with low latency, it seems strange to insert an avoidable extra 1ms delay into the processing time... This is kind of the point of events (and in windows, messages; not timers or timer-events). So that one thread can wake another thread immediately. The whole "if your hardware supports it" reply seems irrelevant to the scenario gambiting has described, as the only relevant hardware sounds like network hardware. Either that's interrupting on packet arrival or it isn't, but either way, a sleep(1) loop in the worker threads won't make packet handling faster, and is almost certainly making the responses slower than they need to be, no matter which version of Windows and which timer rate.(+) (+) (Except in some exotic multi-core setups, and it doesn't sound like that applies here).

gambiting 6y ago

Well, (and I don't mean it sarcastically) clearly you know more about this that me or any of our engineers do, because we couldn't find a way to do this. Yes, I knew that packets coming in trigger a hardware interrupt that wakes up the thread processing them - but as we had multiple other threads actually decoding this data, there isn't a good way to wake those up from the receiving thread. The sleep(1) and check for work was the best solution, as every other method/API we tried had the same problem of ultimately being limited by the system timer interrupt, and we couldn't get around it in any way. I don't want to say that there definitely isn't a way to do this - but we never found it.

mehrdadn 6y ago
I see. It's hard to say if I'm missing something but given what I've heard so far I think what you want is I/O completion ports (though there are other ways to solve this). They're basically producer-consumer queues. I highly recommend looking into them if you do I/O in Windows. They're more complicated but they work very well. Here's a socket example: https://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancediomethod5i.html https://www.winsocketdotnetworkprogramming.com/winsock2progr...
- vardump 6y ago
  I've written Windows device drivers, so I think I could say I'm rather intimately familiar with Windows I/O request (IRP) processing. Sounds like people in gambiting's company are the same. I/O completion ports is an API for getting better efficiency between kernel and userland I/O. Batching, better scheduling and avoiding WFMO bottleneck. It's great, but it doesn't really have anything to do with timers. The bottom line here is that Windows timer behavior has changed. This is terrifying.
  - mehrdadn 6y ago
    It "has nothing to do with timing" in the sense that it doesn't let you choose how much delay to incur. It most certainly does "have something to do with timing" in that it lets you do I/O immediately, without polling or incurring system timer interrupt delays... which is precisely what his description of the problem required. It's kind of bizarre to see you trying to interject into it to argue with me as if you know his situation better than himself while even contradicting his descriptions in the process. I feel like the discussion already concluded on that topic. I'll leave this as my last comment here.
    - vardump 6y ago
      > without polling or incurring system timer interrupt delays... which is precisely what his description of the problem required Except sometimes polling is your only option. Your scenario works great, if the hardware supports that use case and you're not using some intermediate software layer that prevents you from taking full advantage of the hardware. Other scenario is when Windows is being used to control something time critical. I fully agree one shouldn't do that, but sometimes you just have to. The new timer change really hurts here. In other words, we don't live in the perfect world, but still need to get the software working. I also feel like we're somewhat talking past each other. > It's kind of bizarre to see you trying to interject into it to argue with me as if you know his situation better than himself while even contradicting his descriptions in the process. I do know highly similar cases I've had to deal with. Not audio processing, but similarly tight deadlines. It was very painful to get it working correctly.

vardump 6y ago

Unfortunately, sometimes timing requirements do arise "out of the void" to adhere, because not all hardware is perfect. Also sometimes you just need to do timing sensitive processing. I guess you could argue one shouldn't use Windows for that, but unfortunately sometimes we developers don't really have a choice. Doing what you're told pays the bills. :-)

mehrdadn 6y ago
I think you misunderstood. If you want "timing sensitive processing", that's what you can and should expect to use events or multimedia timers for. That way you can actually expect to meet timing guarantees. Using Sleep() and depending on it for correctness in such situations (regardless of its accuracy) is kind of like using your spacebar to heat your laptop... it doesn't seem like the right way to go on its face, even if there was something to guarantee it would work: https://xkcd.com/1172/ https://xkcd.com/1172/
- vardump 6y ago
  > that's what you can and should expect to use events or multimedia timers for I don't want to use a deprecated API call, timeSetEvent. > Using Sleep() and depending on it... Absolutely no one was using Sleep for timing. It just used to be that all Windows timer mechanisms are really the same thing, and Sleep(1) was an easy way to quickly test actual timing precision. Obviously Windows 10/2004 changed all this.
  - jlokier 6y ago
    > I don't want to use a deprecated API call, timeSetEvent. That's not what dataflow is saying to use. The phrase is "events or timers", not "timer events". gambiting describes this scenario: The hardware (network) does interrupt the CPU and supplies an incoming packet to the receiver thread, which does not use a timer. Then the receiver thread wants to send it to a worker thread. It sounds like gambiting's implementation has the worker threads polling a software queue using a sleep-based timer, to pick up work from the receiver thread. Unless there's something not being said in that picture, the receiver should be sending an event to a worker thread to wake the worker instantaneously, rather than writing to memory and letting the workers get around to polling it in their own sweet, timer-dependent, unnecessarily slow time. Given that it's described as audio data which must be processed with low latency, it seems strange to insert an avoidable extra 1ms delay into the processing time... This is kind of the point of events (and in windows, messages; not timers or timer-events). So that one thread can wake another thread immediately. The whole "if your hardware supports it" reply seems irrelevant to the scenario gambiting has described, as the only relevant hardware sounds like network hardware. Either that's interrupting on packet arrival or it isn't, but either way, a sleep(1) loop in the worker threads won't make packet handling faster, and is almost certainly making the responses slower than they need to be, no matter which version of Windows and which timer rate.(+) (+) (Except in some exotic multi-core setups, and it doesn't sound like that applies here).