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

How “latency numbers everybody should know” decreased from 1990–2020

colin-scott.github.io

Post reply on HN
Print view View original

61–70 of 225 posts

Re: How “latency numbers everybody should know” decreased from 1990–2020

#61

Post by ChuckMcM »

ianai wrote: post #42
ChuckMcM wrote: post #34

Earlier quoted context omitted.

We probably see things differently. As I understand it, this is exactly the use case for "big/little" microarchitectures. Take a number of big fast cores that are running full bore, and a bunch of little cores that can do things for them when they get tasked. So far they've been symmetric but with chiplets they needn't be.

Yes, for 'computational' loads. I've read though UI/UX benefits the most from fastest response times. I'm talking about the cores which actually draw the GUI the user sees/uses being optimized for the task at the highest possible rate. Then have a pool of cores for the rest of it.

You are talking about the GPU? Okay, really random tidbit here; When I worked at Intel I was a validation engineer for the 82786 (which most people haven't heard about) but was a graphics chip that focused on building responsive, windowed user interfaces by using hardware features to display separate windows (so moving windows moved no actual memory, just updated a couple of registers) to draw the mouse, and to process character font processing for faster updates. Intel killed it but if you find an old "Number9 video card" you might find one to play with. It had an embedded RISC engine that did bitblit and other UI type things on chip.

EVERYTHING that chip did, could in fact be done with a GPU today. It isn't, for the most part, because window systems evolved to be CPU driven, although a lot of phones these days do the UI in the GPU, not the CPU for this same reason. There is a fun program for HW engineers called "glscopeclient" which basically renders its UI via the GPU.

So I'm wondering if I misread what you said and are advocating for a different GPU micro architecture or perhaps an integrated more general architecture on the chip that could also do UI like APUs?

Re: How “latency numbers everybody should know” decreased from 1990–2020

#64

Post by sigstoat »

the code appears to just do a smooth extrapolation from some past value.

it claims that (magnetic) disk seek is 2ms these days. since when did we get sub-4ms average seek time drives?

it also seems to think we're reading 1.115GiB/s off of drives now. transfer rate on the even the largest drives hasn't exceed 300MiB/s or so, last i looked.

("but sigstoat, nvme drives totally are that fast or faster!" yes, and i assume those fall under "SSD" on the page, not "drive".)

Re: How “latency numbers everybody should know” decreased from 1990–2020

#65

Post by genewitch »

aeyes wrote: post #58
skunkworker wrote: post #54

Earlier quoted context omitted.

Maybe if hollow core fiber is deployed we could see a 50% reduction in latency (from .66c to .99c). Past that physics take over, and unfortunately the speed of light is pretty slow.

Could LEO satellite networks like Starlink with inter-satellite links reduce the roundtrip time?

the radius of the arc in low earth orbit (or whatever) is going to be larger than the arc across the atlantic ocean.

As no one has ever said: "I'll take glass over gas, thanks."

Re: How “latency numbers everybody should know” decreased from 1990–2020

#66

Post by DonHopkins »

ChuckMcM wrote: post #17

Not an intuitive thing but the data is fascinating. A couple of notes of people who are confused by it: 1) The 'ns' next to the box is a graph legend not a data label (normally that would be in a box labeled legend to distinguish it from graph data) 2) The weird box and rectangle thing on the top is a slider, I didn't notice that until I was looking at the code and said "what slider?" 3) The only changes from 2005 to…

At what point did Joy's Law -- "2^(year-1884) MIPS" -- break with reality?

https://medium.com/@donhopkins/bill-joys-law-2-year-1984-mil...

https://en.wikipedia.org/wiki/Joy%27s_law_(computing)

Re: How “latency numbers everybody should know” decreased from 1990–2020

#67

Post by DonHopkins »

dweez wrote: post #62

Okay since we're not going to improve the speed of light any time soon, here's my idea for speeding up CA to NL roundtrip: let's straight shot a cable through the center of the earth.

We could really use some decent Mexican food here in the Netherlands.

https://idlewords.com/2007/04/the_alameda_weehawken_burrito_...

Re: How “latency numbers everybody should know” decreased from 1990–2020

#68

Post by almog »

dweez wrote: post #62

Okay since we're not going to improve the speed of light any time soon, here's my idea for speeding up CA to NL roundtrip: let's straight shot a cable through the center of the earth.

What's more, we can run that cable along a gravity train from CA to NL, saving the costs of digging another tunnel. :)

Re: How “latency numbers everybody should know” decreased from 1990–2020

#69

Post by genewitch »

jeffbee wrote: post #23

I doubt that same-facility RTT has been fixed at 500µs for 30 years. In EC2 us-east-1 I see function getDCRTT() { // Assume this doesn't change much? return 500000; // ns }

I show 180-350µs between various machines on my network, all of which have some fiber between them. devices with only a switch and copper between them somehow perform worse, but this is anecdotal because i'm not running something like smokeping!

Oh, additionally between VMs i'm getting 180µs, so that looks to be my lower bound, for whatever reason. my main switches are very old, so maybe that's why.

Re: How “latency numbers everybody should know” decreased from 1990–2020

#70

Post by genewitch »

bryanrasmussen wrote: post #12
csours wrote: post #3

Earlier quoted context omitted.

There's a slider at the top. It took me 2 minutes to find it.

It used to take 3 minutes, that's quite an improvement.

6×10^10 ns (that's a lot of zeros!)
Post reply on HN