I think he understands that he's talking about page fetch time to
an audience that won't believe that latency is like "latent
fingerprints": stuff that hasn't shown (up) yet.
Such folks annoy me (;-))
Note his quote usage in this:
IMPORTANT NOTE about the -c {concurrency} option: if you ask for -c 10, each "page" will consist of 10 parallel fetches of URL, and the "latency" will be the amount of time it takes to get the last bit from the last concurrent child fetch.
--dave
I was not aware that jim salter had really gone to town on measuring latency under load in the past year - notably the 4 stream 1024p + web browsing torture test used here: https://arstechnica.com/gadgets/2019/11/ars-puts-googles-new-nest-wi-fi-to-the-test/?itm_source=parsely-api https://arstechnica.com/gadgets/2019/12/amazons-inexpensive-eero-mesh-wi-fi-kit-is-shockingly-good/?comments=1 He considers under 500ms of browsing latency to be "good". Not entirely sure how he's calculating that, I think he's measuring page completion time rather than "latency" per se'. The tools he uses are here: https://github.com/jimsalterjrs/network-testing/blob/master/README.md
-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain