4 ms·

It all depends on your application. I worked on one which was required to respond to a packet from the network within 5 microseconds of the packet arriving. P

It all depends on your application. I worked on one which was required to respond to a packet from the network within 5 microseconds of the packet arriving. Please, don't assume all applications are mobile uis, webapps and corporate backends.

mnd999 5y ago
I very deliberately wrote “most applications”. Of course there are exceptions.
- lmilcin 5y ago
  Your operating system you are running is not just "an exception". Neither is software running in all your electronics. All these require software that has some different requirements that typically are incompatible with unpredictability of a garbage collected dynamic language.
kryptiskt 5y ago
Garbage collection is the least of your problems in that case. You can't use a standard OS for that kind of scenario either, Linux has far bigger jitter than that. And if you have a hard real-time system, you could have a hard real-time garbage collector too. Garbage collection gets a bad rep from garbage collectors that are tuned for throughput rather than latency, but there is no lower limit to latency for garbage collection and there are GCs out there that prove it (like Azul). If you can afford dynamic memory allocation, you can afford garbage collection. And if you can't afford it, you can just preallocate and turn off the garbage collector.
- lmilcin 5y ago
  > You can't use a standard OS for that kind of scenario either, Linux has far bigger jitter than that. Bullshit. We were using Linux and it was just fine. But I agree, it requires more knowledge than your run of the mill software dev will ever have.
  - saagarjha 5y ago
    Be kind; don’t be snarky. You’re here to share your knowledge, not sneer down at people who bring up fairly reasonable questions.
    - FpUser 5y ago
      >"not sneer down at people who bring up fairly reasonable questions" Downvoting reasonable posts that do not fit somebody's point of view without providing any constructive explanations is of course way better.
      - lmilcin 5y ago
        I don't care about downvotes. If somebody is here for votes then they should reassess their life's choices.
        FpUser 5y ago
        I do not care either. Real choices are made in real life. We are just talking here.
    - lmilcin 5y ago
      The person put a blank statement that the Linux is unusable for the task (without giving any more information) and I responded that it is usable because we are using it for it. As to "run of the mill software dev" this is not a snarky comment, this is just reality. Most devs have absolutely no idea how to configure Linux at all, other than to make their application work. Not to mention configure for real time operation. So I stand by my comment that comes from over two decades of experience in the field.
      - saagarjha 5y ago
        "Linux" as most people know it is unusable for this kind of task. They are correct that the standard scheduler will not really let you run anything that needs to run in real time. Your response to that is literally just "no, we did it, and you're just to dumb to understand". Imagine a third grader and and they told you that you can't take the square root of a negative number. Of course you know that imaginary numbers exist, but you'd be a jerk if you just replied to them with "you can actually but I guess some people just don't know how to do it". Hacker News is a site that values intellectual curiosity, not snark: you should have replied with an explanation of what you are actually doing to get that kind of thing out of the Linux kernel. What value is your experience in the field to this community if you refuse to share it with others? In this case my analogy is even stronger because you could argue that explaining imaginary numbers to a third grader may be difficult, but "I set CONFIG_whatever to this value and set the kernel to never schedule my application off this core" is exactly the kind of response that would be expected in this context.
- rigtorp 5y ago
  You're incorrect, garbage collection would be the biggest problem for that use case. You have to be really careful even with your C/C++ code, warming up the branch predictor between packets etc, see my article for some pitfalls: https://rigtorp.se/virtual-memory/ https://rigtorp.se/virtual-memory/
- erichocean 5y ago
  > You can't use a standard OS for that kind of scenario either, Linux has far bigger jitter than that. This is 100% false. It's easy to configure Linux itself to only occupy 1 or 2 cores (one real + the hyper-thread for that real core), and then pin your own application threads to the other cores where no other code will run. This setup has identical application performance (other than not having those two Linux cores) to having no OS at all. 100% predictable, ZERO jitter application code (including user-space networking). Except…you can still SSH in to your "no OS" Linux box, you have a file system, can run cron jobs, git, gdb, WireGuard, etc. So it's much, much better in practice and what actual high-performance network developers actually do. Essentially no one has run a literal "no OS" box for at least a decade; everyone who is running on normal hardware does what I just described with Linux because the cost is dirt cheap and it's way too convenient.
emidln 5y ago
This is possible with a mostly Java application (assuming you're willing to venture into user-space network stacks with either a JNI bridge or shared memory with a C/C++/Rust). You only really people go out of their way for this when doing HFT or very high throughput networking apps.
pjmlp 5y ago
You are right not all of them are, some control weapons systems on battleship fleets. https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-technology-at-the-of-aegis-the-shield-of-the-fleet https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te... Better deflect that incoming missile on time before the next GC pause.
- WJW 5y ago
  Let's do the math on that shall we. Aegis is built for defending against missiles going at most mach 4-5. Mach 5 is ~1700 m/s, so during a millisecond GC pause it will travel slightly under 2 meters. Ship-based SAMs will have proximity-fused fragmentation warheads and even back in the 70s those had a kill radius of >100m (see for example https://en.wikipedia.org/wiki/S-75_Dvina https://en.wikipedia.org/wiki/S-75_Dvina). So even a GC pause at the worst possible moment would not significantly impact the probability to hit the target. Even really fast things in the real world are really slow compared to computers. (Of course, in practice the Aegis system will only provide midcourse corrections to the missile. The fuse and end phase guidance control software would not interface much with the rest of the combat management system anyway.)
  - lmilcin 5y ago
    I think you don't appreciate how rockets kill other rockets. The rockets close head on (so the speeds add together) and then the rocket trying to kill the other one explodes at right distance to the side of the other rocket, exploding in a cone of debris. That cone of debris must intersect the other rocket at a right point. It can't just hit anywhere, to reliably kill it must hit a specific part of the other rocket. So, realistically, you have to time your explosion to something like tens of microseconds. Also getting there is a control loop problem and it requires very precise control. The more jitter in execution of the control loop the worse steering it will be and less chance it will get to the right place at the right time.
    - WJW 5y ago
      I was a weapons engineering officer for the Dutch navy for 14 years; I'm well aware of the mechanisms involved. First of all, a SM-2 will not use the flight path you describe as they tend to "dive down" on a sea skimming missile. But even the shorter range Sea Sparrow missiles that do behave as you describe use multiple guidance phases. In the early and mid-phase guidance phases, the radar reflections from the target missile will not be strong enough for the relatively small receiver in the missile, so the system must depend on midcourse guidance updates (little bit to the right, little bit up, etc) from the combat management system on board the launching vessel to navigate to a "close enough" location from where the sensors on board the missile can acquire the target. The end-phase guidance and fuse timings are quite critical, as you say, but they are also not really under command of the CMS but rather done by embedded systems on board the missile. Generation of the mid-course guidance updates is not nearly as time critical and won't suffer much from a 1 ms pause. The error in location estimation of the target due to sensor imperfections (limited angular resolution, clock jitter, athmospheric effects, etc etc) will be way larger than the 2 meter from the GC pause.
dagw 5y ago
Reminds me of an argument I witnessed at a meetup: Dev A "You should use X" Dev B "We tried X, it was way to slow" Dev A "You must be doing it wrong, I use X all the time and it's very fast" This went back and forth like this for a good 15 minutes before they realized they where both getting the same performance, but just had a very different definition of "fast" and "slow".
alex_smart 5y ago
>I worked on one which was required to respond to a packet from the network within 5 microseconds of the packet arriving. Sounds like HFT? But then your competitors are probably using an FPGA to respond in 300 nanoseconds, so good luck with that 5 microseconds tick-to-trade.
- da_chicken 5y ago
  No, that could be a lot of things. SCADA is what came to my mind.
- lmilcin 5y ago
  Why do you think everything has to be either manually submitted order or HFT?
  - alex_smart 5y ago
    Sending a response within 5 microseconds of receiving a packet seemed like a very HFT thing to me. I don't even know how you came to the conclusion that I think that "everything has to be either manually submitted order or HFT" but that's on you.

mnd999 5y ago

I very deliberately wrote “most applications”. Of course there are exceptions.

lmilcin 5y ago
Your operating system you are running is not just "an exception". Neither is software running in all your electronics. All these require software that has some different requirements that typically are incompatible with unpredictability of a garbage collected dynamic language.

kryptiskt 5y ago

Garbage collection is the least of your problems in that case. You can't use a standard OS for that kind of scenario either, Linux has far bigger jitter than that. And if you have a hard real-time system, you could have a hard real-time garbage collector too. Garbage collection gets a bad rep from garbage collectors that are tuned for throughput rather than latency, but there is no lower limit to latency for garbage collection and there are GCs out there that prove it (like Azul). If you can afford dynamic memory allocation, you can afford garbage collection. And if you can't afford it, you can just preallocate and turn off the garbage collector.

lmilcin 5y ago
> You can't use a standard OS for that kind of scenario either, Linux has far bigger jitter than that. Bullshit. We were using Linux and it was just fine. But I agree, it requires more knowledge than your run of the mill software dev will ever have.
- saagarjha 5y ago
  Be kind; don’t be snarky. You’re here to share your knowledge, not sneer down at people who bring up fairly reasonable questions.
  - FpUser 5y ago
    >"not sneer down at people who bring up fairly reasonable questions" Downvoting reasonable posts that do not fit somebody's point of view without providing any constructive explanations is of course way better.
    - lmilcin 5y ago
      I don't care about downvotes. If somebody is here for votes then they should reassess their life's choices.
      - FpUser 5y ago
        I do not care either. Real choices are made in real life. We are just talking here.
  - lmilcin 5y ago
    The person put a blank statement that the Linux is unusable for the task (without giving any more information) and I responded that it is usable because we are using it for it. As to "run of the mill software dev" this is not a snarky comment, this is just reality. Most devs have absolutely no idea how to configure Linux at all, other than to make their application work. Not to mention configure for real time operation. So I stand by my comment that comes from over two decades of experience in the field.
    - saagarjha 5y ago
      "Linux" as most people know it is unusable for this kind of task. They are correct that the standard scheduler will not really let you run anything that needs to run in real time. Your response to that is literally just "no, we did it, and you're just to dumb to understand". Imagine a third grader and and they told you that you can't take the square root of a negative number. Of course you know that imaginary numbers exist, but you'd be a jerk if you just replied to them with "you can actually but I guess some people just don't know how to do it". Hacker News is a site that values intellectual curiosity, not snark: you should have replied with an explanation of what you are actually doing to get that kind of thing out of the Linux kernel. What value is your experience in the field to this community if you refuse to share it with others? In this case my analogy is even stronger because you could argue that explaining imaginary numbers to a third grader may be difficult, but "I set CONFIG_whatever to this value and set the kernel to never schedule my application off this core" is exactly the kind of response that would be expected in this context.
rigtorp 5y ago
You're incorrect, garbage collection would be the biggest problem for that use case. You have to be really careful even with your C/C++ code, warming up the branch predictor between packets etc, see my article for some pitfalls: https://rigtorp.se/virtual-memory/ https://rigtorp.se/virtual-memory/
erichocean 5y ago
> You can't use a standard OS for that kind of scenario either, Linux has far bigger jitter than that. This is 100% false. It's easy to configure Linux itself to only occupy 1 or 2 cores (one real + the hyper-thread for that real core), and then pin your own application threads to the other cores where no other code will run. This setup has identical application performance (other than not having those two Linux cores) to having no OS at all. 100% predictable, ZERO jitter application code (including user-space networking). Except…you can still SSH in to your "no OS" Linux box, you have a file system, can run cron jobs, git, gdb, WireGuard, etc. So it's much, much better in practice and what actual high-performance network developers actually do. Essentially no one has run a literal "no OS" box for at least a decade; everyone who is running on normal hardware does what I just described with Linux because the cost is dirt cheap and it's way too convenient.

emidln 5y ago

This is possible with a mostly Java application (assuming you're willing to venture into user-space network stacks with either a JNI bridge or shared memory with a C/C++/Rust). You only really people go out of their way for this when doing HFT or very high throughput networking apps.

pjmlp 5y ago

You are right not all of them are, some control weapons systems on battleship fleets. https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-technology-at-the-of-aegis-the-shield-of-the-fleet https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te... Better deflect that incoming missile on time before the next GC pause.

WJW 5y ago
Let's do the math on that shall we. Aegis is built for defending against missiles going at most mach 4-5. Mach 5 is ~1700 m/s, so during a millisecond GC pause it will travel slightly under 2 meters. Ship-based SAMs will have proximity-fused fragmentation warheads and even back in the 70s those had a kill radius of >100m (see for example https://en.wikipedia.org/wiki/S-75_Dvina https://en.wikipedia.org/wiki/S-75_Dvina). So even a GC pause at the worst possible moment would not significantly impact the probability to hit the target. Even really fast things in the real world are really slow compared to computers. (Of course, in practice the Aegis system will only provide midcourse corrections to the missile. The fuse and end phase guidance control software would not interface much with the rest of the combat management system anyway.)
- lmilcin 5y ago
  I think you don't appreciate how rockets kill other rockets. The rockets close head on (so the speeds add together) and then the rocket trying to kill the other one explodes at right distance to the side of the other rocket, exploding in a cone of debris. That cone of debris must intersect the other rocket at a right point. It can't just hit anywhere, to reliably kill it must hit a specific part of the other rocket. So, realistically, you have to time your explosion to something like tens of microseconds. Also getting there is a control loop problem and it requires very precise control. The more jitter in execution of the control loop the worse steering it will be and less chance it will get to the right place at the right time.
  - WJW 5y ago
    I was a weapons engineering officer for the Dutch navy for 14 years; I'm well aware of the mechanisms involved. First of all, a SM-2 will not use the flight path you describe as they tend to "dive down" on a sea skimming missile. But even the shorter range Sea Sparrow missiles that do behave as you describe use multiple guidance phases. In the early and mid-phase guidance phases, the radar reflections from the target missile will not be strong enough for the relatively small receiver in the missile, so the system must depend on midcourse guidance updates (little bit to the right, little bit up, etc) from the combat management system on board the launching vessel to navigate to a "close enough" location from where the sensors on board the missile can acquire the target. The end-phase guidance and fuse timings are quite critical, as you say, but they are also not really under command of the CMS but rather done by embedded systems on board the missile. Generation of the mid-course guidance updates is not nearly as time critical and won't suffer much from a 1 ms pause. The error in location estimation of the target due to sensor imperfections (limited angular resolution, clock jitter, athmospheric effects, etc etc) will be way larger than the 2 meter from the GC pause.

dagw 5y ago

Reminds me of an argument I witnessed at a meetup: Dev A "You should use X" Dev B "We tried X, it was way to slow" Dev A "You must be doing it wrong, I use X all the time and it's very fast" This went back and forth like this for a good 15 minutes before they realized they where both getting the same performance, but just had a very different definition of "fast" and "slow".

alex_smart 5y ago

>I worked on one which was required to respond to a packet from the network within 5 microseconds of the packet arriving. Sounds like HFT? But then your competitors are probably using an FPGA to respond in 300 nanoseconds, so good luck with that 5 microseconds tick-to-trade.

da_chicken 5y ago
No, that could be a lot of things. SCADA is what came to my mind.
lmilcin 5y ago
Why do you think everything has to be either manually submitted order or HFT?
- alex_smart 5y ago
  Sending a response within 5 microseconds of receiving a packet seemed like a very HFT thing to me. I don't even know how you came to the conclusion that I think that "everything has to be either manually submitted order or HFT" but that's on you.