How “latency numbers everybody should know” decreased from 1990

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

#221

Post by horsawlarway » Fri, Mar 04, 2022, 9:22 PM UTC

capitainenemo wrote: post #216

horsawlarway wrote: post #213

Earlier quoted context omitted.

Alright, fair enough - we might just have fairly different workloads. I absolutely notice a pretty major difference. If you don't - hey, if it's not broken, don't fix it I guess.

As I think about this, maybe it really is a Windows vs Linux thing. On raw read speeds, SSD is only about 2-3x faster than HDD. This is barely noticeable compared to the speed from RAM, or for almost anything you could reasonably launch. (Videos are huge, but those are basically streamed anyway) But, random access reads of many small files scattered across the disc, obviously SSD will do much better. Sequential reads…

I mean - I also run the ginormous cheap discs. I don't think anyone is saying to load your media library all onto an ssd, it just doesn't matter enough. But the OS/applications are a big deal.

And 2-3x faster is low. For my wife's machine, moving from a 5400rpm spinning disk to a relatively cheap samsung ssd made effective read times about 12x faster. Technically a 5400 rpm drive can do ~75mb/s, but that mostly ignores seek time, and assumes sequential reads. In reality, it was often doing less than 40mb/s. The SSD caps at about 540mb/s, but in reality it mostly does around 450.

It's the difference between having MS teams take ~5 seconds to load, vs more than a minute (locking most of the machine for that period as well).

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

#222

Post by horsawlarway » Fri, Mar 04, 2022, 9:25 PM UTC

capitainenemo wrote: post #218

capitainenemo wrote: post #216

Earlier quoted context omitted.

As I think about this, maybe it really is a Windows vs Linux thing. On raw read speeds, SSD is only about 2-3x faster than HDD. This is barely noticeable compared to the speed from RAM, or for almost anything you could reasonably launch. (Videos are huge, but those are basically streamed anyway) But, random access reads of many small files scattered across the disc, obviously SSD will do much better. Sequential reads…

Hmmm another thought. Linux also (typically and traditionally) does a lot more library reuse thanks to the open source ecosystem. So, there's less DLL hell and fragmentation there. That could be another reason for my not noticing. Most of my system libraries that any random app needs are already loaded and ready for use after boot.

Yeah - you might be onto something there - I suspect fragmentation matters a lot for the spinning disks. If you've got huge disks in there, you probably have mostly sequential reads for just about everything.

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

#223

Post by capitainenemo » Fri, Mar 04, 2022, 10:13 PM UTC

horsawlarway wrote: post #221

capitainenemo wrote: post #216

Earlier quoted context omitted.

As I think about this, maybe it really is a Windows vs Linux thing. On raw read speeds, SSD is only about 2-3x faster than HDD. This is barely noticeable compared to the speed from RAM, or for almost anything you could reasonably launch. (Videos are huge, but those are basically streamed anyway) But, random access reads of many small files scattered across the disc, obviously SSD will do much better. Sequential reads…

I mean - I also run the ginormous cheap discs. I don't think anyone is saying to load your media library all onto an ssd, it just doesn't matter enough. But the OS/applications are a big deal. And 2-3x faster is low. For my wife's machine, moving from a 5400rpm spinning disk to a relatively cheap samsung ssd made effective read times about 12x faster. Technically a 5400 rpm drive can do ~75mb/s, but that mostly ignor…

I just launched Microsoft Teams for Linux on this spinning rust work machine here. It launched a meeting link (letting me into the room) in between 2 and 3 seconds (one-onethousand two-onethousand)

I last launched Teams on this machine a couple of days ago.

For a "fair" comparison (keep in mind, again, the whole point I was making that RAM dominates these days), I then ran:

sync; echo 3 > /proc/sys/vm/drop_caches

And launched Teams again. It opened in between 8-10 seconds with ALL OS caching of disc dropped.

I think what you're seeing here is Windows being helped along by SSD making it usable...

It reminds me of the change we made in Hedgewars. We had no idea it was taking 20-30 seconds to launch our gui in Windows since it opened instantaneously in Linux even with all caches flushed. We had to add lazy page loading to get reasonable performance on Windows - it was probably all about NTFS being insanely slow (and maybe crap at laying out data reasonably).

*Edit - I updated my time estimate upwards slightly for teams after testing the flush several times and my own counting skills.

The flush was also a good test of launching firefox, since I did it once between to update nightly, it also opened very quickly post flush. Barely noticeable delay.

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

#224

Post by gxs » Sat, Mar 05, 2022, 12:14 AM UTC

warmwaffles wrote: post #29

Now we just need to either beat the speed of light, or speed light up. (thanks futurama)

It's cool to think about how as humans we're actually running into situations where we have to consider the speed of light.

Like, at some point we're really going to wish it were higher than it is.

Amazing, can you imagine a few hundred years ago worrying about how fast light travels?

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

#225

Post by peterfield » Mon, Mar 07, 2022, 5:02 AM UTC

deanmen wrote: post #176

peterfield wrote: post #148

Complete laggard questions: * Did SSD exist in 1993? * Why using an "approximately equal" sign (as opposed to a real = sign) between e.g. 1000ns and 1 micros ? (I would undersatnd between binary and decimal multiples of bytes...but decimal fractions of seconds don't work this way)

1024 ns = 1 micro second ;)

To my knowledge the second is still a metric system unit, not a "SW engineering geek system unit". Wikipedia agrees https://en.wikipedia.org/wiki/Nanosecond