It took me a while because I assumed gigabit had been kind for far longer than it actually was in practice.
Even the most high bitrate streaming services have peak bitrates under 80Mbps, with averages being much lower than that.
For USB ether, you’re still going to be limited by USB 2 speeds.
Dave Täht is rolling in his grave
https://lore.kernel.org/intel-wired-lan/803760bf-04ff-4b23-8...
I didn't need to change any NIC settings, but I'm on an X540 instead of an E610-XT2
Other OSes also suffer from bad defaults and poor feedback, so whatcha gonna do.
You'll still run into issues with USB connections and ensuring you have a high speed through them as not all usb connectors and dongles will run reliably at 10g bidirectional.
(I'm aware of some instances where the light in the fiber has been used to power local electronics, but AFAIK there's no standard for this, and it's probably not an economical solution for me.)
You can even safely remove the word "networking" from that sentence.
I don't know why I know this but back in 2011 something not being plugged in all the way was the root reason why neutrinos were detected traveling faster than the speed of light.
"In March 2012 an LNGS seminar was held, confirming the fiber cable was not fully screwed in during data gathering"
https://en.wikipedia.org/wiki/2011_OPERA_faster-than-light_n...
anyone old enough from dialup modems and RS232 to remember the trick of replacing the 16450 UART with 16550 if you were lucky enough to have it on a socket instead of soldered?
that took it from a 1-byte buffer to 16-bytes, instant speed boost
same idea going from X-modem to Y-modem for transfers, 128bytes vs 1024bytes before checksum
surprised ethernet by now doesn't constantly try to negotiate larger buffer windows
Having too few receive buffers leaves a trail in diagnostics (if you know to look for it!), having too many gives more subtle problems. But with 10G ethernet, you can get a lot of packets really quickly and the buffer default was probably set for a card doing 100M or 1G and the driver was updated to handle 10G without new defaults. Interrupt modulation is also common now, which is great for throughput, but means packets buffers will get more full.
I feel like segmentation offload is a nice idea, but weirdness always lurks in the shadows and I don't hesitate to turn it off if any weirdness appears. I haven't noticed a perf difference when I turn it off, but I also haven't run great tests.
I also only learned like 5 years ago that crossover cables are unnecessary nowadays. The 10mbit one I made with a bad soldering iron worked surprisingly well.
If you don't have a router you can capture pcaps with, setup a box with two nics, bridged, between your ps5 and your router and take pcaps on that.
I'd expect slow downloads to be either a pMTU problem (but I over index on that), the tcp window is too small, or the download server is far away/high latency. Too small window and far away download server combine to make it worse. Sibling's suggestion of adding a squid proxy likely helps because squid is highly likely to have large tcp windows. Other sibling's suggestion of disable ipv6 is likely to help if Sony didn't bother to do happy eyeballs and their ipv6 infrastructure chooses far away mirrors or is otherwise partially broken.
Could also be using a download server with high path loss, that would show up in the pcap as lots of out of order packets.
I tried to find an article covering this but I've had no luck, so I'm just going off memory here, but I'm pretty certain that's all that was required.
It was badly designed in the first place, CLAT should have been mandated as part of the spec rather than dual stack nonsense.
In anticipation for GTA6 I actually bought a PS5 Pro 2 weeks ago. I had to create a separate IPv4-only network because it would not complete the user-sign-up on the device on my IPv4/IPv6 network.
Absolutely insane.
This is the biggest problem with those cheap network interfaces in tvs. They dont have any form of usable buffer, so a spike instantly creates problems.
using an usb network dongle (or if your setup is good enough wifi, but this is very unstable)
Also, most tv's are not able to push the full 100Mbps over their network interface.
It shouldn't? I have 10M to 10G in the same ethernet collision domain everything works at appropriate speeds (my 10G hosts don't always hit 10G cause some of them have anemic cpus, but that's a different story). Most of my switches are cheap gigE switches, not the 10G stuff obviously, so cheap isn't the problem.
Only thing is if some equipment thought ethernet pause frames were a good idea... Send too much traffic to a low speed switch port and get a pause frame will tend to stop all outbound traffic which is not helpful. Not a lot of things send or respect pause frames though...
And even in cheap switches (think Realtek / Broadcom chips in $30 switches) they have dynamic shared pools. An elephant flow can exhaust some of that pool, but even the cheap stuff won't allow a single port to exhaust all resources as claimed.
10Gb to 100Gb UDP? Sure... Maybe in this scenario you end up with some odd behavior, but this isn't going to be normal usage. We've got PAUSE frames, congestion control and hardware that's been doing this for decades. Even on the cheap switching. It is imperative to have a router, however that actually deals with buffer bloat appropriately and as your Internet pipe scales you want to be cognizant your router can handle queuing appropriately at those line rates.
But ultimately...
> A 10G host sending large data to a 100M peer will cause all packets between all other peers to drop once switch memory is filled up.
...is not true. Switches don't work like that.
Imagine 5 devices that all push at 100mbit in 100 milliseconds (1gig linerate) to the target 1gig connected device, then nothing for 900ms.
On paper they are feeding 100mbit a second each to a target receiving 500mbit a second. Easily fits in a 1gig link.
But because of the timing you've got to transmit 500mbit in 100ms, or a peak speed of 5gbit.
So instead you have to buffer and delay the packets. Your near-zero latency increases to 400ms, and your switch needs about 400mbit (50MB) of buffer, or over 30,000 packets of buffer space.
You'd need a very high end switch to avoid any drops in that situation.
Again, a cheapo non reputable switch probably runs with whatever settings got it working the first time with no follow up testing. Networking algorithms are an area where the simple dumb thing mostly works except in edge cases and adversarial situations, and the right/proper way to do things is fiendishly complex.
> I’m not an expert on switching algorithms
then you surely shouldn't tell about 'various algos'
And no, no amount of software magik would help if your L1 can't handle the traffic.