Needs desperately a 2012 label in the title!
How “latency numbers everybody should know” decreased from 1990–2020
181–190 of 225 posts
Re: How “latency numbers everybody should know” decreased from 1990–2020
#182Not 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…
Your definition of "storage" must be including memory, because the page says memory has been speeding up.
Re: How “latency numbers everybody should know” decreased from 1990–2020
#183Not 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…
Actually, this data is all false from 2012 onwards. The code was written back in 2012 and is using numbers from back then to _guess_ what future numbers would look like! (I was fooled by it too) See https://github.com/colin-scott/interactive_latencies/issues/...
Yeah, I was wondering where the heck 2ms disk seek times came from. That's not a thing and will never be a thing; disks only spin so fast, and nobody even uses >7200RPM drives any more (because we've all moved to SSDs instead).
Re: How “latency numbers everybody should know” decreased from 1990–2020
#184Earlier quoted context omitted.
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."
Yeah, but the faster speed of light through vacuum can still be enough to make up for the longer path. Back-of-the-envelope calculation: at an altitude of 550km and minimum elevation of 25 degrees above the horizon, a single Starlink hop could cover a maximum of 1880km of distance along the earth's surface, with a ground-satellite-ground length of 2068km. So the total distance traveled through space is about 10% fart…
Speed of light delay puts a lower bound on latency, but the actual delay depends on transmission error rate, buffer size, bandwidth, and utilisation.
Assuming that the link is close to saturated, real life latency will be determined by how big the buffers are at each hop.
Traditionally, internet providers have been optimising for bandwidth at the cost of latency. I wonder what Starlink does.
Re: How “latency numbers everybody should know” decreased from 1990–2020
#185Earlier quoted context omitted.
Yeah... SSDs are so much faster than spinning disk it's not even funny. I literally refuse to run a machine that boots its main OS from spinning disk anymore. The 60 bucks to throw an SSD into it is so incredibly cheap for what you get. My wife's work gave her a (fairly basic but still fine) thinkpad - except they left the main drive as a fucking 5400rpm hdd. Then acted like assclowns when we repeatedly showed them t…
You're a good husband. I did the same for my wife, and her 2012 core I7 HP Elitebook acted like it was ten years younger. But I went a step further: the mother-in-law. She had a lower grade I3 laptop from around 2008 that took 20 minutes to boot Windows 10. It now boots in 15 seconds with a stock 512GB SSD. I am being rewarded by both (but in very different ways).
>I am being rewarded by both (but in very different ways).
I'm going to hell for this.
Re: How “latency numbers everybody should know” decreased from 1990–2020
#186Latency is everything. I believe that sometime around 2010 we peaked on the best software solution for high performance, low-latency processing of business items when working with the style of computer architecture we have today. https://lmax-exchange.github.io/disruptor/disruptor.html I have been building systems using this kind of technique for a few years now and I still fail to wrap my brain around just how fast…
> made myself to do it the "stupid" way first. Turns out I was definitely wasting my time
I think you put into words something that has been apparent for a while now with all the bloated software out there.
Software has become stupid.
Not because we're not capable of doing it smart, rather it's a accumulation of small instances of 'I'll do it fast and stupid' like that import, which 10-20 years ago would have been a long enough delay for the developer to do something about it.
Then across the multiple dependencies and imports you end up with an overall slow system since every one of those was implemented with a 'stupid but fast enough for this' mindset.
Re: How “latency numbers everybody should know” decreased from 1990–2020
#187Not 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…
Something else to consider is that the data doesn't seem consistent. For example, the top right label, "Read 1,000,000 bytes sequentially from SSD" shows as 31,000ns when I load the page, but when I move the slider to the left and back to 2020, it shows a different value, 49,000ns. This happens for about half of the values for the data labels in chrome, firefox, and safari. The initially shown values are neven shown…
Good catch. It's because the initial value for year is:
var year = new Date().getFullYear();
Re: How “latency numbers everybody should know” decreased from 1990–2020
#188Earlier quoted context omitted.
> Yet somehow this is fairly obscure knowledge unless you're into serious game programming or a similar field. Because the impact in optimizing hardware like that can be not so important in many applications. Getting the absolute most out of your hardware is very clearly important in game programming, but web apps where scale being served is not huge (vast majority)? Not so much. And in this context developer time is…
IMO we are only scratching the surface of cloud gaming so far. Right now it’s pretty much exclusively lift-and-shift, hosted versions of the same game, in many cases running on consumer GPUs. Cloud gaming allows for the development of cloud-native games that are so resource intensive (potentially architected so that more game state is shared across users) that they would not possible to implement on consumer hardware…
If the "metaverse" ever gets anywhere beyond Make Money Fast and reaches AAA title quality, running the client in "the cloud" may be useful. Mostly because the clients can have more bandwidth to the asset servers. You need more bandwidth to render locally than to render remotely.
The downside is that VR won't work with that much network latency.
Re: How “latency numbers everybody should know” decreased from 1990–2020
#189Earlier quoted context omitted.
Actually, this data is all false from 2012 onwards. The code was written back in 2012 and is using numbers from back then to _guess_ what future numbers would look like! (I was fooled by it too) See https://github.com/colin-scott/interactive_latencies/issues/...
Yeah, I was wondering where the heck 2ms disk seek times came from. That's not a thing and will never be a thing; disks only spin so fast, and nobody even uses >7200RPM drives any more (because we've all moved to SSDs instead).
Oh 7200 drives are used. Mainly for large data storage. If you deal with high quality videos (RAW 4K or 8K), SSDs are way too expensive to store them.
Re: How “latency numbers everybody should know” decreased from 1990–2020
#190Not 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…
"And that means Amdahl's Law is more important than Moore's Law these days." idk, sure seems like we could have 1-2 cores (permanently pegged?) at 5 ghz for UI/UX then ($money / $costPerCores) number of cores for showing off/"performance" by now. But the OEMs haven't gone that way.
The problem is in the, "Pegged at 5ghz" part. 5Ghz is hard!
Not sure the OEM's have what it takes to do that without a serious rethink, and that is what an M1 basically is.
And say they do...
Amdhal's law is still going to be a thing because people are unlikely to believe having two cores running balls out whether essentially idling or pushing high priority interaction... they will see it very poor energy management, and would want tasks moved onto and off those always fast cores at a minimum to reduce what they see as waste.