Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

asquirrel

Member
  • Content Count

    261
  • Joined

  • Last visited

Awards


This user doesn't have any awards

About asquirrel

  • Title
    Member

Profile Information

  • Gender
    Male
  • Location
    Ewe Essay
  • Occupation
    Clickity-clack I make servers clap back.

Recent Profile Visitors

581 profile views
  1. Winner winner. It was around the 5 minute mark. The problem was how to test a 128t processor. And that's where I got lost in my head of 'how do you test a CPU...' because it needs to do so many different tasks. You could test the interrupt handling capability, but that *should* be tied to the CPU frequently pretty solidly (a test could quantify it though!). But really, when you say 'stress', what do you want? Do you want to see if it glitches out under high interrupts when high memory bandwidth is also requested? Are you just trying to push it to 280W TDP output and see what happens? What's the goal of the test? With storage testing it was far more straightforward. But a CPU...:ahhh:
  2. No, that wasn't it. That's the video where he struggles with NVMe bugs. But there was a more recent video where "how the heck do we test this?" was brought up. Maybe it was in a WAN show and I'm thinking it was a normal video because I never watch the wan shows live. Hrm.
  3. asquirrel

    C++ or C#

    C++ for the engine, C# for anything that isn't the engine *if you want to*. As for the network, you're going to find that any APIs or libraries you use for networking are all going to do the same thing under the cover: #ifdef <some OS flag> #include <osspecificheader1.h> #else #include <languagegenericheader1.h> #endif Sometimes this works great and the API simply saves you headaches. Most of the time (IE: Boost) this is a problem that leads to you tearing out all the work you did with the API down the road because in the API's march to 'be universal' it can't do something you need it to do. Just start down the path where you solve the problems you hit yourself. As for transferring data across the network, here is my formal recommendation: Create a standard struct (literally a C++ struct) for network data. Define these fields in it: Message type Message length Message payload (optional) checksum/verification The important part of making that work is that message type and length need to be a fixed size. So, say, message type might be 1 byte (so you could have up to 255 different message types) and length might be 2 bytes (no single message will be larger than 65535 bytes). Why? Because in this way you can package *any* data (maps, movements, firing commands, etc) into standard payloads and send them across the network very, VERY efficiently. As in, I have used this to saturate 40Gb trunk lines efficiently (no, I'm not joking). The reason being that you can read the network packet directly into the struct and then do all your processing directly on the message type (opcode), then have a handler for each message type that can further decode the payload if needed. The CPU can do all this in less than 10 instructions if you code it right. In case it still isn't clear, message type and length need to have a fixed size and location so that you always know where they are in the bytestream you receive. And you want to be able to send a bytesteam, rather than individual packets, because networks operate *far* more efficiently with bytestreams than hand-crafted packets. You are not smarter than the OS's TCP/UDP implementation. Say it with me: "I am not smarter than the operating system!" You aren't. I've known far too many programmers who thought they were and got proved wrong. If you have something large, like a 1GB map file, you don't even need to convert it to anything. You have one message type that says "map download start", and within the payload for that message type, your handler defines that the first byte of the payload contains the total number of map download chunks being sent, and the second byte is the index of this specific chunk (since they might arrive out of order because you WILL be using UDP for your game. Right? RIGHT!?). This will allow you to re-assemble your map file in memory *very* efficiently by simply memcpy() ing the 3rd bit in the message payload into the map array at payload_size * index. This solution also multi-threads well, because while school teaches you that having multiple threads working on the same memory object is unsafe the reality is that in a large array, as long as nobody needs to write or read the same data, it's perfectly fine to have 10 threads writing to the same array at once. So, your send handler will just take the 1GB map, figure out how many max-length messages it will take to send it, and then start creating the message payloads to transfer the file. The receiver will need to decode the same thing, and re-assemble the file in memory. You exit the re-assembler when: A timeout value is hit (connection died, index got lost and needs to be retransmitted, etc) OR You receive all of the indexes you were expecting AND You receive all the bytes you were expecting Be sure to check 2 AND 3 together, don't rely on just one. Doing all this in C++ will make you a better programmer. You'll understand *why* you are doing things, rather than simply shoving bits into a magic API and stuff 'just happening'. Never fear learning, even if it's slow.
  4. I forget what video it was, but in a recent-ish (past month?) video from LTT they mentioned it was super hard for them to test something (storage throughput? 64 core processors? something else? I forget what, exactly). I want to say the problem was the CPU being saturated with interrupts. I know that specific problem is what they hit with their NVMe storage server, but what I am asking about was a different video and a different (or at least different angle on the same) problem. I remember watching the video and thinking "Hm, how would I solve that..." because when I worked for a former employer, I actually wrote my own software to test storage performance at scale (16,000+VMs). The problem is, I can't find the video where the problem to be solved is talked about so I can do more thinking about how to solve it. Or if I even can solve it. Anyone with eidetic memory who can tell me what video to re-watch?
  5. Non-restrictive front. https://www.fractal-design.com/products/cases/meshify/meshify-c/black/ That says you can fit either 3-120mm fans, or 2-140mm fans. Literally any case fan will work there. If you want cheapness https://www.newegg.com/p/pl?N=100007998 600035590 600035592&Order=PRICE If you want quality: https://www.newegg.com/noctua-nf-p12-1300-cpu-cooler-and-case-fan/p/N82E16835608004 (Some will point to other noctua fans as being better case fans, I pick these because they'll last for a decade or more (mine have) and do better with static pressure, so if you ever want to slap them on a radiator or heat sink, you don't need different fans). If you want something in between: Watch videos, pick what you like. Things to check when buying a fan: 1. Did anyone review that fan? If not, well, it makes for more unknowns. 2. How loud is it compared to the Noctua I linked (fan reviews should always cover this)? At full blast, the noctuas are about as loud as a box fan on low. There are fans that are much, much louder, and make your PC sound like a jet taking off. Buyer beware! {note: all brown noctua fans are roughly the same loudness, the black noctua fans are significantly louder, if they say 'industrial') You can run a 4-pin (PWM) fan on a 3-pin (no PWM) connector just fine, the motherboard will still be able to control the speed, just with less precision/(durability?) than PWM allows. CFM/static pressure don't matter for your current application. Pretty much anything that spins will move enough air.
  6. LTT has many videos on fans. Basically though...any fan that's the right size (will fit in your case and/or matches the current size fan) will do. For a case fan, literally anything will work. Unless you have something special (super restrictive intake, dense radiator right behind intake, etc)
  7. If you decide to go the hardware route, scrapyard wars / some linus videos have the right idea. Fleabay is awash with older Xeon hardware for dirt cheap (I'm talking 10 core procs for < $30 each). I had an old co-worker who would go onto scam-bay and buy all his hardware from there for his rendering boxes. As some point, a $500 pc that has 40 cores will out-render most things that cost $2000+.
  8. You can try blowing the dust out, but more than likely the bearings are starting to die and this is their death knell.
  9. Perfect! I was more commenting to tell you there's a limit on how good the solution can be, and you seem to already be at/near it.
  10. I don't actually have a powershell script I use. I just know it can be done because I've used FFMPEG enough to know it's do-able. That said...I do have a movie or two that I wish weren't ripped to HD as blu-rays and were, instead, H264s...if I reply, it's because my laziness was overcome by my frustration with this. Don't hold your breath, those files have been there for over a year.
  11. I've used: Macbooks, Dell, and Lenovo laptops. For me, Lenovo always had the best hardware. My mac had weird issues and in 1 year I visited in-company support 10 times with the thing (touchpad stops touching, keys stop registering, sleep doesn't sleep, etc). Dell laptops are missing keys I use constantly (pgup/down, home, end) or if they have them at all, I have to hold a function key to use them. No! Also, with Dell, you have to use this breakout-box thingie to connect a monitor to it, and when you dock/undock the computer from that breakout box it can't remember what screens were where. It's super annoying to have your windows get all fuckulated because Dell's shitty software can't remember window positions. But Lenovo? That just worked. Close the lid, it goes to sleep. Open the lid, it wakes up. Pg up/down keys, home and end, exactly where you want them. A touchpad with physical right and left click buttons, so there's no doubt as to what you're trying to do. Dell tries to copy Apple, but without any QA, so their product sucks. Lenovo just made a good laptop. Note: all my review content is circa 2016, so more recent lenovos may suck. But compare them to the ones from 4 years ago and if they look similar, then you're probably golden.
  12. Eh, it's winter. Just run 1-2 overnight while you sleep. Keep your room warm.
  13. Yes, this is a normal workflow for encoding physical media: rip to HD -> convert to final format. Powershell is your friend, assuming you can handle command line stuff.
  14. Just to make sure I understand, you're planing to compress the videos with handbrake by re-encoding them, right? If you were hoping to use Windows file compression or ZIP/RAR/7z formats, none of those will do anything meaningful to video files. I can't find a option for deleting the files after transcode in handbrake/ffmpeg (handbrake is just a wrapper for ffmpeg, if you didn't know). This makes some sense, ffmpeg allowing you to delete a source file right after encode would be akin to someone handing you a gun and letting you shoot it with your eyes closed. It's a *really* bad idea. People who know their transcode settings are good can write a script to delete the file automatically after the transcode is done (powershell/bash). I think a script is your best bet, if you are 100% confident your transcodes are going to work.
  15. I finally installed Honey a few days ago since I was buying a mixer from Kitechaid. The deals it found didn't work. Then I learned it also doesn't work with amazon (in a meaningful way). Now this...I just uninstalled it. Elon's first child really is turning out to be a bit of...well I was going to say spawn of satan, but that'd make Elon satan and I don't hate him at all, much less that much. Hrm... :/
×