The vids detailed but worth the time spent as it relates to game networking, t1 and t2 both have similarities to the networking paradigms discussed and use Huffman compression in their networking too. Bonus: if you have any probs falling to sleep just fire up one of that guys vids.
I have an old MSI 970 if you want another one. Have the rest of the computer attached to it as well (3570k CPU maybe?), it was running kinda funny for a while. Having stability/boot issues, etc., and wouldnt run Windows 11 on the old MB without some workarounds so I eventually upgraded.
Something not planned for going from SAS HDD to SAS SSD drives in the server was trim/unmap cmd passhthru that I knew nothing about beforehand. This is problematic since no RAID card save the very newest bothers to pass those cmds, and only the enterprise level cards are going to feature it as the cmds are arcane to the enterprise RAID SAS SSD world. If you run a standard HBA in IT mode the OS will automagically send trim/unmap cmds to each drive when needed, RAID cards ignore such cmds so the drive must rely on its own garbage collection routines written into the firmware. These cmds tell the drive the blocks that can be overwritten with new data when need be, otherwise the drive thinks any cell with bits is needed data and not to be overwritten even though the OS has deleted the file(s) in its table. As you can see, this can quickly fill up a drive. These routines also reduce write amplification and ensure the drives last as long as possible by spreading the wear out among all the cells.
To be sure, the SAS SSD drives in the server are enterprise class from an older generation, but with petabytes of drive life inbuilt, so even used ones are typically a safe bet for a drive that can last a decade. Knowing no RAID card passed trim/unmap cmds, the makers overprovisioned the drives with extra cells, a 400gb rated drive will actually have 500 to 600gb capacity, a 200gb drive will have 300gb total, the extra space is hidden from userland and OSland and is only available to the housekeeping firmware in each drive. They also gave the enterprise drive firmwares advanced garbage collection routines not present in consumer level SSD drives. Another obstacle often faced in such hobbyist use of enterprise hardware is the block size, most of the serious datacenter stuff is a 520 block size where consumer OS (and RAID cards as well as HBA) want to see 512, so one must reformat the prospective drives from 520 to 512 with some level of cli drudgery if not negotiated before, say, at purchase time. If you get some used SAS SSD disks and the RAID card or HBA refuse to see them it's likely due to them being 520 block drives, so you have some cli work to do.
What is today proposed for best practices, and more and more enterprises are moving away from hardware RAID cards to OS or Software RAID solutions, is to replace the RAID card with a simple HBA in IT mode, this gives the OS direct access to the drive at the lowest latency possible as no slow RAID engine is intercepting all system calls for disk service. This results in fantastic random reads, something unrealised with RAID hardware and spinning disks, the tradeoff is in writes, with no RAID card in write back cache mode taking the writes from the OS and saying ok got it thanks now go away and the OS goes on about its merry way not knowing the RAID card has lied to the OS and is reorganising the data into something more rational before it sends it to the drive to actually be written, this opposed to write thru cache, where each write is committed to the disk ASAP, the disk writes the data, and then reports the transaction as completed to the CPU only after the write has actually taken place. No reordering or time savings at all.
That said, you can enable each drive's own onboard cache either via a cli utility or in the OS itself, but many enterprise drives will have onboard cache disabled by default because enterprise loves reliability more than speed.
So this is what we are going to do,; replace the H700 RAID card in the server with a flashed H200 HBA and run the game files in a Software RAID0 array. The current disks, one hosting the OS the other the games, will remain as they are. The games drive will become the data drive and will hold all the backups and perhaps a pagefile so the OS can busy itself with OS needs, but the system should never really hit the pf as I've never seen it use more than 5gb out of the 16 in the server and that was only when Mozilla was running, in normal use it's around 2.8gb total. My game pc runs two SATA drives in a RAID0 array and don't notice anything bad performance wise from the system, so the much faster and more advanced game server should follow suit, being the Software RAID0 array in the server will cause a fraction of 1 percent CPU time spent on disk access, especially since no parity has to be calculated in RADI0. We shall see.
Comments
Server down for for a few hours for ssd/os implants.
Just saw this discussion at reddit;
The vids detailed but worth the time spent as it relates to game networking, t1 and t2 both have similarities to the networking paradigms discussed and use Huffman compression in their networking too. Bonus: if you have any probs falling to sleep just fire up one of that guys vids.
https://www.youtube.com/watch?v=b8J7fidxC8s
https://www.reddit.com/r/programming/comments/1nxuj2b/indepth_quake_3_netcode_breakdown_by_tariq10x/
Hi Blakhart,
I have an old MSI 970 if you want another one. Have the rest of the computer attached to it as well (3570k CPU maybe?), it was running kinda funny for a while. Having stability/boot issues, etc., and wouldnt run Windows 11 on the old MB without some workarounds so I eventually upgraded.
Would you be interested?
Hey there, nice to make the offer, pm me what you'd like for the combo and I'll get with my friend who is looking for a 970 setup/
For all working with a current install of win11 or installing it fresh, this link is on reducing bloat/spyware on the OS;
Stop the Slop: 8 Tools That Clean Up Windows 11 | TechSpot
Gonna try tiny11 on the server in a few weeks or so.
Something not planned for going from SAS HDD to SAS SSD drives in the server was trim/unmap cmd passhthru that I knew nothing about beforehand. This is problematic since no RAID card save the very newest bothers to pass those cmds, and only the enterprise level cards are going to feature it as the cmds are arcane to the enterprise RAID SAS SSD world. If you run a standard HBA in IT mode the OS will automagically send trim/unmap cmds to each drive when needed, RAID cards ignore such cmds so the drive must rely on its own garbage collection routines written into the firmware. These cmds tell the drive the blocks that can be overwritten with new data when need be, otherwise the drive thinks any cell with bits is needed data and not to be overwritten even though the OS has deleted the file(s) in its table. As you can see, this can quickly fill up a drive. These routines also reduce write amplification and ensure the drives last as long as possible by spreading the wear out among all the cells.
To be sure, the SAS SSD drives in the server are enterprise class from an older generation, but with petabytes of drive life inbuilt, so even used ones are typically a safe bet for a drive that can last a decade. Knowing no RAID card passed trim/unmap cmds, the makers overprovisioned the drives with extra cells, a 400gb rated drive will actually have 500 to 600gb capacity, a 200gb drive will have 300gb total, the extra space is hidden from userland and OSland and is only available to the housekeeping firmware in each drive. They also gave the enterprise drive firmwares advanced garbage collection routines not present in consumer level SSD drives. Another obstacle often faced in such hobbyist use of enterprise hardware is the block size, most of the serious datacenter stuff is a 520 block size where consumer OS (and RAID cards as well as HBA) want to see 512, so one must reformat the prospective drives from 520 to 512 with some level of cli drudgery if not negotiated before, say, at purchase time. If you get some used SAS SSD disks and the RAID card or HBA refuse to see them it's likely due to them being 520 block drives, so you have some cli work to do.
What is today proposed for best practices, and more and more enterprises are moving away from hardware RAID cards to OS or Software RAID solutions, is to replace the RAID card with a simple HBA in IT mode, this gives the OS direct access to the drive at the lowest latency possible as no slow RAID engine is intercepting all system calls for disk service. This results in fantastic random reads, something unrealised with RAID hardware and spinning disks, the tradeoff is in writes, with no RAID card in write back cache mode taking the writes from the OS and saying ok got it thanks now go away and the OS goes on about its merry way not knowing the RAID card has lied to the OS and is reorganising the data into something more rational before it sends it to the drive to actually be written, this opposed to write thru cache, where each write is committed to the disk ASAP, the disk writes the data, and then reports the transaction as completed to the CPU only after the write has actually taken place. No reordering or time savings at all.
That said, you can enable each drive's own onboard cache either via a cli utility or in the OS itself, but many enterprise drives will have onboard cache disabled by default because enterprise loves reliability more than speed.
So this is what we are going to do,; replace the H700 RAID card in the server with a flashed H200 HBA and run the game files in a Software RAID0 array. The current disks, one hosting the OS the other the games, will remain as they are. The games drive will become the data drive and will hold all the backups and perhaps a pagefile so the OS can busy itself with OS needs, but the system should never really hit the pf as I've never seen it use more than 5gb out of the 16 in the server and that was only when Mozilla was running, in normal use it's around 2.8gb total. My game pc runs two SATA drives in a RAID0 array and don't notice anything bad performance wise from the system, so the much faster and more advanced game server should follow suit, being the Software RAID0 array in the server will cause a fraction of 1 percent CPU time spent on disk access, especially since no parity has to be calculated in RADI0. We shall see.