Steam can do pretty well filling a tail circuit, probably better on average. But a torrent of a large file with a ton of peers when your client has the port forward back into the client absolutely puts more pressure on a tail circuit. More flows makes the shaping work harder.

Sometimes we see an outlier in our reporting and it’s not obvious if a customer has a torrent or a DDoS directed at them for the first few minutes.

No, if two 300 megabit tails are shaped correctly, a third user shouldn’t notice that the 1G backhaul has got a bunch of use going on.

If you do, there’s something wrong or you aren’t really getting the 1G for some reason. Not generally a concern in a carrier platform.

I build ISP and private data networks for a living.

A contention ratio for residential circuits of 3 to 1 isn’t bad at all. You’d have to get pretty unlucky with your neighbors being raging pirates to be able to tell that was contended at all. Any data cap should scare the worst of the pirates away, so you probably won’t be in that situation.

If you can feel the circuit getting worse at different times of the day then the effective contention ( taking into account further upstream ) is probably more like 30 to 1 than 3 to 1.

I’ve been using Linux for something like 27 years, I wouldn’t say evangelical or particularly obsessed.

I started using it because some of the guys showing up to my late 90’s LAN parties were dual booting Slackware it and it had cool looking boot up messages compared to DOS or Windows at the time. The whole idea of dual booting operating systems was pretty damn wild to me at the time too.

After a while it became obvious to me that Slackware '96 was way more reliable than DOS or Windows 95 at the time, a web browser like Netscape could take out the whole system pretty easily on Windows, but when Netscape crashed on Linux, you opened up a shell and killed off whatever was left of it and started a new one.

I had machines that stayed up for years in the late 90’s and that was pretty well impossible on Windows.

Often on Linux group membership changes only take effect on login. So you could try logging out of your session and logging back in after your group changes to test that theory out.

The context of this post is Linux on AMD cards, is there any support at all for raytracing or upscaling of any sort on Linux on either AMD or Nvidia? Serious question.

I’ve been running Linux for 100% of my productive work since about 1995. Used to compile every kernel release and run it for the hell of it from about 1998 until something like 2002 and work for a company that sold and supported Linux servers as firewalls and file servers etc.

I had used et4000’s, S3 968’s and trio 64’s, the original i740, Matrox g400’s with dual CRT monitors and tons of different Nvidia GPU’s throughout the years and hadn’t had a whole lot of trouble.

The Nvidia Linux driver made me despair for desktop Linux for the last few years. Not enough to actually run anything different, but it did seem like things were on a downward slide.

I had weird flashing of sections of other windows when dragging a window around. Individual screens that would just start flashing sometimes. Chunky slideshow window dragging when playing video on another screen. Screens re-arranging themselves in baffling orientations after the machine came back from the screen being locked. I had crap with the animation rate running at 60hz on three 170hz monitors because I also had a TV connected to display network graphs ( that update once a minute ). I must have reset up the panels on cinnamon, or later on KDE a hundred times because they would move to another monitor, sometimes underneath a different one or just disappeared altogether when I unlocked the screen. My desktop environment at home would sometimes just freeze up if the screen was DPMS blanked for more than a couple of hours requiring me to log in from another machine and restart X. I had two different 6gb 1060’s and a 1080ti in different machines that would all have different combinations of these issues.

I fixed maybe half of the issues that I had. Loaded custom EDID on specific monitors to avoid KDE swapping them around, did wacky stuff with environment variables to change the sync behaviour, used a totally different machine ( a little NUC ) to drive the graphs on the TV on the wall.

Because I had got bit pretty hard by the Radeon driver being a piece of trash back in something like 2012, I had the dated opinion that the proprietary Nvidia driver was better than the Radeon driver. It wasn’t til I saw multiple other folks adamant that the current amdgpu driver is pretty good that I bought some ex-mining AMD cards to try them out on my desktop machines. I found out that most of the bugs that were driving me nuts were just Nvidia bugs rather than xorg or any other Linux component. KDE also did a bunch of awesome work on multi monitor support which meant I could stop all the hackery with custom EDIDs.

A little after that I built a whole new work desktop PC with an AMD GPU ( and CPU FWIW ) . It has been great. I’m down from about 15 annoying bugs to none that I can think of offhand running KDE. It all feels pretty fluid and tight now without any real work from a fresh install.

A 2 gigabit event isn’t big enough to be considered a real attack, a service like cloudflare can sink a 2 terrabit attack every day of the week.

Building a DDoS protection service ( that isn’t just black holing traffic ) starts with having enough bandwidth to throw away the attack volume plus keep your desired traffic working and have a bit of overhead to work your mitigation strategies.

What this means is to DIY a useful service you start by buying a couple of terrabits of bandwith in ‘small’ chunks of a hundred gigabits or so in most peering locations around the globe and then you build a proxy layer like cloudflare on top of it with a team of smart dudes to automate outsmarting the bad guys.

I don’t like cloudflare either, but the barriers to entry in this industry are epic.