Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Latency numbers

gist.github.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Latency numbers

#11

Post by thrownaway2424 »

drdaeman wrote: post #6
thrownaway2424 wrote: post #3

The "TCP packet retransmit" one is interesting, because it's a parameter you can set in your socket library or kernel. On Linux the default minimum RTO is 200ms, even if the RTT of the connection is < 1ms. For local networking you really, really want to reduce the minimum RTO to a much smaller number. If you don't, random packet loss is going to dominate your tail latency.

For local networking, packet loss is, in most cases, a sign something somewhere isn't doing well. So, maybe, it's better notice it sooner than bump into possible unexpected problems later.

Not really. A busy network has a million little buffers and things where your packet might get dropped but succeed 1ms later.

Re: Latency numbers

#13

Post by e98cuenc »

Klinky wrote: post #9

Any document relating benchmarks or performance numbers should include the exact make/model of the hardware involved. So often I see performance numbers reported by developers without much detail on the actual hardware being used. It should be painfully obvious that numbers will vary greatly depending on hardware/platform.

These numbers are gold even without knowing the exact model of the hardware. I always use them when I want to get a rough estimate for a new system. Should I expect milliseconds, seconds or minutes for a given task in a new system?

I don't really care if my real system is 2x faster or slower than the quoted number.

Re: Latency numbers

#14

Post by wtallis »

thrownaway2424 wrote: post #11
drdaeman wrote: post #6

Earlier quoted context omitted.

For local networking, packet loss is, in most cases, a sign something somewhere isn't doing well. So, maybe, it's better notice it sooner than bump into possible unexpected problems later.

Not really. A busy network has a million little buffers and things where your packet might get dropped but succeed 1ms later.

But those buffers are also often huge and your packet could still come out the other end of one of them 20ms (or 2s, if it's a cable or DSL modem) later. You still want to treat it as evidence of congestion, though.

Re: Latency numbers

#15

Post by xxs »

adsche wrote: post #10

Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs Any reason why (arbitrarily?) take 2K here and not 1K?

2KiB is above the usual MTU which is probably suboptimal for standard packet size.
Post reply on HN