How ggRock works

This article describes basic of ggRock diskless boot system, it's core concepts and absolute basics for beginners.

What is ggRock

ggRock is a foundational diskless boot system. It allows you to run your entire eSports Center floor from one server. You can completely remove the hard drives from all Client Machines, and the data will be fed into them over Ethernet cables.

Frame 2525-1

Above you can find a comparison between a "No Diskless" setup vs ggRock setup, as well as the most defining features of both setups.

As you can see, ggRock allows you to update any given application (or several applications) one time and then apply it to the Image, that is shared by all Machines. This is done via the mechanism called Writebacks, which we will explore later.

ggRock Array - why drives are important

For now you need to know about the requirements for the server. Since ggRock takes away all storage from the Machines and encapsulates it locally - it needs good drives. We require you to use at leas TLC SSDs. This means that neither HDDs nor QLC SSDs (i.e. Samsung 860 QVO) should ever be used.

One crucial point about ggRock setup is that all of your data, for all Machines is located on one storage Array. This means that if it fails - your entire center will go dark.

This is why we recommend to always opt in for a redundant ggRock Array (Stripe Type - Mirrored/Mirrored-Striped).

This is what it looks like fully configured:

This way even if any one of your drives fail - ggRock will be operational and will have no issues, giving you time to replace the failed drive. However, you will need to purchase double the capacity of drives for this redundancy.

Therefore, assuming you had 1TB Game SSDs in your Machines - you will need, in general, 4x1TB SSDs to make up your ggRock Array.

It's a good rule to have

60GB + Games Size + (Number of Machines * 10) + 15% total 

capacity of free space in the Array, rounded down for reserve. Assuming we want to run 40 Machines and our Game Library is 1TB we need:

60 + 1000 + 40*10 + 15% = 1717GB or ~ 1.8TB of space

4x1TB drives in RAID10 (Mirrored) Array will give you 2TB of space, which is great for our case. You can read more about what Drives we recommend in ggRock Hardware Specifications.

You can read more about different ggRock Array Types here, and read more about Game Image size calculation here.

RAM Caching - why RAM size is important

One of the reasons we store all data on the server is to be able to efficiently cache it. If you would just hit one SSDs with requests from 40 PCs at the same time - it's speed would not be sufficient.

Therefore, RAM is important because it's used to stand in between your Machines and your Array. If some data is frequently requested and is "popular" with the Client Machines, say, Fortnite data - ggRock will put that information into the RAM cache, which is in orders of magnitude faster than any SSD out there.

Above you can see that when PC01 requests Fortnite data - ggRock first goes to RAM, checks whether the data is there, and then pulls up data from the Array into the RAM cache. Once that's done, 99 other requests from other PCs are served from RAM and drives in the Array have time to serve other requests or are just not utilized.

Key takeaways from this should be:

  1. You need as much RAM as you can reasonably get

  2. The more Machines there are, more RAM is required. We recommend:
    - 32GB for 20 Machines
    - 64GB for 40 Machines
    - 128GB for 100 Machines
    - 256GB for 200 Machines and 128GB for every 100 machines after it

  3. Volume of RAM is more important that it's frequency (Hz) or response time (CL)

You can read more about what size of RAM we recommend in ggRock Hardware Specifications.

Overall, this approach allows ggRock to be superior to even other PXE boot diskless solutions, as demonstrated here:

Writebacks and Snapshots

The diagram in the beginning of the article does not tell the whole story about ggRock mounting OS and Game Images to Client Machines as physical drives. You can read more about how Writebacks and Snapshots work in this dedicated article: How Writebacks and Snapshots work.