Another example: PCIe ASPM exit latency. Fast LAN speed (because the card does not have time to go into sleep) but low internet speed (manages to enter ASPM if the host is at least 3ms away)
I'm honestly surprised Intel doesn't provide do fwupd crate, it's such a blow to their reputation considering how popular 22x NICs are in Mini PCs and even ASRock mobos
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
A lot of these drivers were written in a different era and the defaults are less appropriate now.
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.
Took wayyyy too many hours of tech support to find someone that clued in that I had an 8250 uart and that’s why my $$$ 33.6k performed like garbage until I bought a 16550 card.
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.
When I was struggling to figure out why so many of my devices on my gigabit network were only getting 100 megabits, I learned that a lot more of my devices were on 10/100 ethernet than I expected. Including some recent purchases (TV's especially).
It took me a while because I assumed gigabit had been kind for far longer than it actually was in practice.
Yes - I think in cases where you have a good wireless setup at home it's actually preferable to not hardware the TV. It's easy to get better performance over wifi when the port is only 100mbps.
> Turns out I didn’t plug the sfp+ all the way in.
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"
Is there a similar diagnostic that can be run on a Playstation 5? I generally have good download speeds on my network but it seems to take forever to install games on my PS5.
My guess would be that this has more to do with disk speed if your download speeds are decent. Especially if it’s wired to the internet rather than WiFi. It’s always easy to spot the console user in cross-platform lobbies because of the loading times.
The write speed of the PS5 SSD is indeed quite bad but it's still way faster than gigabit ethernet, it can't be the bottleneck. It also can't be the bottleneck with load times, it still reads at 5000MB/s even though it writes at 1/10 that on a good day.
Playstation's networking capabilities are an absolute mess.
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.
If it's anything like the PS4, you might be able to fix this by running a HTTP proxy using Squid and configuring that on the PlayStation. There's something really funky about Sony's networking on them, and configuring a squid proxy for my PS4 vastly sped up my downloads.
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.
Take a pcap on your router while you're downloading things and it should be enlightening.
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 had problems where the download ran at max speed for about 3 seconds and then practically idle for a minute, over and over. Took forever to download games. The solution was to disable the newfangled ipv6 in my router; now I get full speed at the ps5.
Very much agreed with you that IPv6 is indeed fine. I think it’s even good, even beyond the necessary feature of providing an appropriate number of prefixes.
But I do narrowly agree with GP that CLAT should’ve been a goal from the beginning. Dual stack is such a losing proposition for any org that doesn’t substantially benefit from deploying IPv6. Adding in CLATs with a plan to go 464XLAT from almost day one would have massively changed the calculus.
No. Just no.
If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before. And dual stack is no issue. But as always the ISP does need to not fuck up and you operating system should follow RFCs.
All these transitions methods are far to expensive and an unnecessary overhead.
> If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before.
I think you forgot half a sentence here. What was your point?
> And dual stack is no issue.
How can that possibly be so? Having enough address space to comfortably architect gives you room for far superior topologies, meaning that running dual stack at the bare minimum means that either your IPv6 topology is being compromised to map cleanly to your v4 topology, or that you're running two different topologies altogether. You need two times the sets of firewall rules, two times the number of address configurations...everything in your infra roughly 2x.
> All these transitions methods are far to expensive and an unnecessary overhead.
How so? Running 464XLAT on a device with a proper CLAT has minimal overhead, and the PLAT is no worse than running a NAT for IPv4.
Running nat on ipv4 is no worse than running a stateful firewall on ipv6 only, I don't get the complaints about it. Modern firewalls do far more with deep packet inspection, SSL unwrapping etc. NAT is a hardware function on enterprise access switches let alone firewall layers, any home router would have to do firewalling at their router anyway.
Well performance really isn't something I would point to at all. While I believe it can become problematic with great scale (e.g. those expensive CGNAT boxes), it's more the architectural and connectivity aspects that are problems:
Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.
Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).
I'm not advocating dual stack either. Like I said in my other reply to you, I am suggesting IPv4-as-a-service using standard translation technologies and architectures.
Dual stack is the problem, we've still got devices which are ipv4 only. I've never seen anything that's ipv6 only.
Even on my standard linux laptop, and corporate windows laptop, with the hack of DNS64, I still have issues with my ipv6 subnet. Yet I have no problem with my ipv4 subnets.
So I don't bother with ipv6 - it's a toy. There is no benefit at all to me, but I can't get rid of IPv4 because some devices won't work with ipv6, and others will work but have bugs.
The ivory towers felt "we know best, everyone will move to us, we don't need backwards compatibility". That arrogance put ipv6 back probably 30 years, maybe more. Building in backward compatibility at the protocol level (so 464 etc) would have removed the need for other hacks (dns64) and allowed a trivial transition.
Yep, agreed on pretty much all counts. The end goal is obviously the same for both dual-stack and translation technologies. But the latter makes things so much lower risk and gives you (the network operator) actual progress and a chance to simplify along the way. Providing IPv4-as-a-service is an actual plausible thing, compared to dual stack's now-draw-the-rest-of-the-owl vision.
Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.
At work I can't see being able to drop ipv4 for at least 20 years due to applications and hardware which still relies on ipv4 (I've got some endpoints which don't even support igmpv2!)
I still haven't had a single failure for someone who can't reach an ipv4 endpoint.
I'm not suggesting dropping v4 connectivity altogether. I'm suggesting migration to a v6-only core by providing IPv4 as a service via 464XLAT, IPv6-Mostly, or only offering IPv4 to select network segments using SIIT-DC-2xlat: https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual...
I upgraded my entire home network to 10GBase-T earlier this year, and I get 10Gbps speeds everywhere, but I run Linux everywhere, except for a few Windows VMs, which also get 10Gbps. I think the TLDR for this article comes down to "Windows networking sucks", which everybody should already know anyway.
Windows networking doesn't suck that much. Microsoft does do some good things with networking (they originated receive side scaling, which is really useful for high volume servers), this is just bad defaults and poor feedback.
Other OSes also suffer from bad defaults and poor feedback, so whatcha gonna do.
10-gbase-t sucks, massive power draw, massive heat generation. Use fibre.
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 agree 100%, but my relatively new house already had Cat6 everywhere, and I did not think it was worthwhile to start tearing up walls. Also, lots of the connected goodies use PoE++ which you cannot do over fiber.
(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.)
43 comments
[ 0.26 ms ] story [ 3.4 ms ] threadhttps://lore.kernel.org/intel-wired-lan/803760bf-04ff-4b23-8...
I hate this piece of shit with a passion. But hey, at least they gatekeep the worst kinds of firmware updates in their OEM pages!
https://github.com/BillyCurtis/Intel-I226-V-NVM-Firmware
I'm honestly surprised Intel doesn't provide do fwupd crate, it's such a blow to their reputation considering how popular 22x NICs are in Mini PCs and even ASRock mobos
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.
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.
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...
I didn't need to change any NIC settings, but I'm on an X540 instead of an E610-XT2
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.
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.
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.
It was badly designed in the first place, CLAT should have been mandated as part of the spec rather than dual stack nonsense.
But I do narrowly agree with GP that CLAT should’ve been a goal from the beginning. Dual stack is such a losing proposition for any org that doesn’t substantially benefit from deploying IPv6. Adding in CLATs with a plan to go 464XLAT from almost day one would have massively changed the calculus.
All these transitions methods are far to expensive and an unnecessary overhead.
I think you forgot half a sentence here. What was your point?
> And dual stack is no issue.
How can that possibly be so? Having enough address space to comfortably architect gives you room for far superior topologies, meaning that running dual stack at the bare minimum means that either your IPv6 topology is being compromised to map cleanly to your v4 topology, or that you're running two different topologies altogether. You need two times the sets of firewall rules, two times the number of address configurations...everything in your infra roughly 2x.
> All these transitions methods are far to expensive and an unnecessary overhead.
How so? Running 464XLAT on a device with a proper CLAT has minimal overhead, and the PLAT is no worse than running a NAT for IPv4.
Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.
Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).
I completely agree, which is why dual stack is terrible.
> Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.
Dual stack doesn't solve that
> stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used
The source port is ephemeral for almost all applications, and I can't think of a good reason it wouldn't be, just legacy crap
I'd love to have an ipv6 only network with NAT66 at the boundary, at home and at work, but while it still requires ipv4 I don't see the point.
Even on my standard linux laptop, and corporate windows laptop, with the hack of DNS64, I still have issues with my ipv6 subnet. Yet I have no problem with my ipv4 subnets.
So I don't bother with ipv6 - it's a toy. There is no benefit at all to me, but I can't get rid of IPv4 because some devices won't work with ipv6, and others will work but have bugs.
The ivory towers felt "we know best, everyone will move to us, we don't need backwards compatibility". That arrogance put ipv6 back probably 30 years, maybe more. Building in backward compatibility at the protocol level (so 464 etc) would have removed the need for other hacks (dns64) and allowed a trivial transition.
Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.
I still haven't had a single failure for someone who can't reach an ipv4 endpoint.
As such I see it as just a toy.
You can even safely remove the word "networking" from that sentence.
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.)
Dave Täht is rolling in his grave