• Ephera
    link
    fedilink
    arrow-up
    3
    ·
    2 years ago

    I mean, sometimes knowing ‘normal’ timing values can help you debug stuff.

    For example, we recently were debugging why we sometimes didn’t get data in time from a network sensor. And we probably wouldn’t have thought much about the logs saying it took 300 ms to ping that sensor, if we didn’t know 50 ms is enough to ping many webpages.

    But yeah, unless you’re a performance tester, I cannot imagine why you would need to know all of these values, rather than just their rough relation to each other.

    • Helix 🧬@feddit.de
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      but can’t you just ping some other thing you know works properly adjacent to that sensor? So for example, if you have two servers, one behaving normally, the other weirdly, just compare them?

      • Ephera
        link
        fedilink
        arrow-up
        3
        ·
        2 years ago

        You could do that, if you’re actively checking ping roundtrip times. It was in a local network and generally, the connection was working, so we didn’t think the ping or roundtrip times would be relevant.

        Our software was just routinely logging ping+RTT and when scrolling through the logs, we noticed more or less by chance that the RTT is 300 ms, which is absurdly high for that context.

        And well, this is just one example. If you’re doing time-sensitive stuff, it’s useful to know the timings of what you’re dealing with. It’s not usually essential, and you especially don’t need to know it for every possible context. But it can make your life easier.