 AHAHAHAHAHA! I've finally done it! 10 terabytes of memory! And I can download as much as I want! Fly with this power! I can... I can... Tell you about our sponsor... BuildRedux! Thanks BuildRedux for sponsoring this video! BuildRedux creates PCs for gamers who want to win and want high frame rates without breaking the bank. They're backed by a 2-year parts and labor warranty, so you're covered. You can click the link down below to start creating your PC today. When we saw this tweet from TJ Horner, first we were like... Whaaaaat? And then we were like, nooooo! And then we were like... well, maybe. Using our unlimited Google Drive storage, we followed the instructions on TJ Horner's blog, which you can check out down below, and upgraded this computer to 10 terabytes of system memory. Behold! But wait, obviously you can't actually download more dynamic random access memory. It's a physical thing. Looks a little something like this. So, what's going on here? Well, if you look closely, you can see that while our 10 terabytes of cloud storage does get lumped into the same pool as our DRAM, it's actually broken out under a separate heading called system swap. What is that, you might ask? Well, a swap space, or a page file for our Windows friends, is a small partition on your SSD or hard drive that prevents the system from crashing outright if you fill up your real memory. That sounds great, right? Free RAM! Well, not exactly. And to understand why, we need to talk about memory hierarchy. Directly on your CPU are your registers. That's where the processor stores what it immediately needs to work on. As well as your caches, which contain data that the CPU is likely to need very soon or very often. Most modern chips have multiple tiers of these caches that get progressively slower, but also larger. Next up, we've got your DRAM. Fast, directly attached storage that gives the CPU quick access to the data for running programs and applications. Then from there, we go to SSDs and hard drives, which are your long-term permanent storage, your local network, and finally the internet, or the cloud. But the thing is, while Windows gets all uppity about knowing your role, Linux actually allows us to flip the traditional hierarchy on its head by manually assigning cloud storage as working memory. Leaving only the question of, how will that perform? So our system here has only 8 gigs of RAM, along with a high-performance Threadripper CPU. Poor thing. TJ's configuration uses our clone then to mount a Google Drive as a local storage space, where we configure our swap space, effectively turning Google Drive into memory. But then the moment we set up our swap space, it tries to write to it and crashes immediately. Now how am I supposed to buy an overpriced pillow on LTTstore.com? What happened here is that Google Drive straight up will not accept random reads and writes. Seemingly this is to prevent customers from running programs off of Google Drive, which makes sense since that would be much harder on their infrastructure than just basic storage. So that didn't go very well, but it doesn't mean that we're done. We've got some ideas for how to apply this concept in a way that could work. But first, let's explain what went wrong. Running a program out of Google Drive, even if they allowed you to do it, would have been a terrible experience. And we can actually prove that with math. Let's start by doing a quick Ida64 memory benchmark on our Ryzen Threadripper system, where it manages 44 gigabytes per second of throughput. Even compared to a premium residential internet connection, that is 350 times faster. So with Google Drive RAM, you could be conceivably waiting six hours for GTA V to load, which might not feel any different, but it is. But what if we could move our storage a little closer to home? Come with me. This is our high-speed video editing server, and we can connect to it from just about anywhere in the office at 10 gigabit per second. That's still 1.35 the speed of RAM, but I mean, it might be usable, right? Now we're back on our machine and we're going to run a different script. Instead of mounting a Google Drive partition as our swap space, we're going to mount a one terabyte partition of SSD space off of that server. There you go, swapping on, boop, one terabyte of swap. And this is just a little script that like fires up a bunch of stuff. It renders an image and, oh, it's supposed to launch a browser. Ooh. Hmm. Are we using our swap? We are. We're actually using it. It's working. It's working very slowly. You can see we've run completely out of memory. 98.3% of our memory is full and we're writing only two MIDI bytes out of our one terabyte of swap. Oh, is this crashed? And we're back. Our best guess as to what happened there was that the processor would have been queuing up a bunch of data to be shuffled over to the memory. So it would have done that on its limited 8 gigs of RAM. But because of how slow that dumping process was, it actually ran out of memory just trying to ready the data. So the bottom line is if we try to write too much at once, the system hard crashes. We actually got as high as I think 100 megabytes of swap when we kind of trickled data into it. So maybe there's a way to make this configuration work. But the point stands that it's pretty dumb. Here's why. Just like any car enthusiast will tell you there's more to life than raw horsepower. The performance of a storage device cannot be represented by bandwidth numbers alone. Let's talk about latency. The CPU expects RAM accesses to happen quickly, like nanoseconds quickly, with AIDA64 pegging our system at about 62 nanoseconds. By comparison, our access latency to WANIX servers is somewhere in the neighborhood of around one millisecond round trip. That is 16,000 times longer. So from the CPU's perspective, that's like your dad popping out for 15 minutes to buy cigarettes and not coming back for about five months. And there are multiple factors causing this. First is physical distance. System memory is just inches from the CPU socket because the signal timing has to be absolutely perfect to run at those kinds of speeds. Following that up is the fact that our server's SSDs are much, much slower than DRAM. And then finally, our server communicates using the SMB protocol, which doesn't handle random reads and writes very well due to its high latency. But that doesn't mean that swap space is completely stupid. Why don't we try using it the way that it is supposed to be used with a locally attached SSD? Switching over to local swap. Almost out of real memory. Wow, that's interesting. It actually doesn't hit the real memory as hard because the swap is actually working. There we go. We've got about a gig in the swap now. It works. Buying more RAM is officially stupid when you can just put a big fat SSD in your system and use it as an overflow, right? Well, no. I mean, it doesn't crash, which is an improvement, but it's also much slower, especially multitasking like this. And if we just had 128 gigabytes of actual RAM, so we don't run out. Now, what's interesting is with our 8 gig stick and our swap space, our game still ran pretty well despite the fact that our RAM was filled up to the brim. Why is that? Well, this is interesting. The operating system in the background still keeps the memory hierarchy in mind when we're running programs. And it'll actually keep the most called on programs, like say, for example, our actively running game in RAM. And then it'll take other programs like our web browser and relegate them to the swap space. So even if we were to fill up 128 gigs, it has so much wiggle room to move what we need currently into our 128 gigs that the performance hit of over utilizing your memory is very slight. Unless you have one application like a scientific analysis application or something like that, that really needs all of it and more. One curious thing is that even running the exact same benchmarks with a swap file and with a massive amount of memory, we didn't see the same amount of total usage. It was somewhere in the neighborhood of 80 gigs when we had RAM, but we're only seeing about 12 gigs of usage. We've seen as high as 17 when we're using a swap. So what gives? The thing is that writing to swap isn't much faster than just leaving stuff on the disk in the first place. In fact, they're about the same. So there's no real reason to write to the swap file when you could just leave it there in the first place. Another thing we're seeing is our processor being slowed down in the meantime. It's called thrashing. And thrashing happens when the CPU is unable to perform work efficiently because it's bogged down moving data around in virtual memory. Did it just crash? Whoops. Okay, well apparently it can crash in these cases. Because our RAM is filled up, we need to constantly read and write data between the RAM and the swap space instead of spending that time getting work done. That's a big part of why many users recommend not using a swap space at all. I'll mention this. RAM is relatively cheap these days and it's easy to add to your system. So for now, we're gonna stick to buying sticks and putting it in our computers instead of trying to download it. Or we could stick to buying something from our sponsor. Squarespace. Do you need a website but don't have the know-how? Squarespace makes it easy. There's a wide selection of award-winning templates and all are optimized for mobile. So they'll look great on any device. You can create members-only content for extra revenue using Squarespace's members area and grow and engage your audience with their powerful and easy-to-use email campaign system. If you ever need additional help, Squarespace also offers webinars, a full series of help guides, or you can contact their 24-7 customer support via live chat and email. So get started today and head to squarespace.com forward slash LTT to get 10% off your first purchase. Clearly RAM is a pretty complex topic. So if you want to learn more about it, check out our video about RAM density and how manufacturers could be trying to rip you off on your PC.