Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux network performance parameters

github.com

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Linux network performance parameters

#111

Post by uep »

jeffbee wrote: post #42
trustingtrust wrote: post #40

Earlier quoted context omitted.

There are 3 revisions of i225 and Intel essentially got rid of it and launched i226. That one also seems to be problematic [1] . Why is it exponentially harder to make a 2.5gbps NIC when the 1gbps NIC (i210 and i211) has worked well for them. Shouldn't it be trivial to make it 2.5x? They seem to make good 10gbps NICs so I would assume 2.5gbps shouldn't need a 5th try from intel ? [1] - https://shorturl.at/esCNP

The bugs I am aware of are on the PCIe side. i225 will lock up the bus if it attempts to do PTM to support PTP. That's a pretty serious bug. You would think Intel has this nailed since they invented PCIe and PCI for that matter. Apparently not. Maybe they outsourced it.

This is really interesting for me to read. I encountered a DMA lockup in the hardware by an Ethernet MAC implementation on an ARM chip. It was a Synopsys Designware MAC implementation. It would specifically lockup when PTP was enabled. From my testing, it seemed like it would specifically lockup if some internal queue was overrun. This was speculation on my part, because it would only lockup if I tried to enable timestamping on all packets. It seemed to work alright if the hardware filter was used to only timestamp PTP packets. This can be a significant limitation though, as it can prevent PTP from working with VLANs or DSA switch tags, since the hardware can't identify PTP packets with those extra prefixes.

The PTP timestamps would arrive as a separate DMA transaction after the packet DMA transaction. It very possibly could have been poor integration into the ARM SOC, but your PTP-specific issue on x86 makes me wonder.

Re: Linux network performance parameters

#112

Post by joveian »

drewg123 wrote: post #110
fulafel wrote: post #100

Earlier quoted context omitted.

> Most TCP stacks will cut their send windows in half (or otherwise greatly reduce them) at the first sign of loss. This was obsoleted by fast retransmit which was standardized in the 90s and ~everyone uses, right? (loss generally is still used as a congestion signal, but first loss is usually not)

No, fast retransmit basically does what it says -- retransmits things quicker. However, it is orthogonal to what the congestion control (CC) algorithm decides to do with the send window in the face of loss. Older CC like Reno halves the send window. Newer ones like CUBIC are more aggressive, and cut the window less (and grow it faster). However, RACK and BBR are still superior in the face of a lossy link.

Depending on the particular situation maybe vegas would work as well?

In particular, since Wireguard is UDP, using vegas over Wireguard seems to me like it should be good (based on a very limited understanding, though :/ ), it is just a question of how well it would work on the other side of the reverse proxy since I don't think it can be set per link?

Re: Linux network performance parameters

#115

Post by Matthias247 »

napkin wrote: post #50

Just changing Linux's default congestion control (net.ipv4.tcp_congestion_control) to 'bbr' can make a _huge_ difference in some scenarios, I guess over distances with sporadic packet loss and jitter, and encapsulation. Over the last year, I was troubleshooting issues with the following connection flow: client host reverse proxy host service host On average, I could not get better than 20% theoretical max throughput.…

> The change needed to be made on both sides of Wireguard.

Congestion control works from the sender of data to the receiver. You don't need to switch both sides if you are just interested in improving performance in one direction.

Besides that, I agree to what others said BBRv1. The cubic implementation in the Linux kernel works really nice for most applications.

Re: Linux network performance parameters

#116

Post by trustingtrust »

ghotli wrote: post #65
trustingtrust wrote: post #40

Earlier quoted context omitted.

There are 3 revisions of i225 and Intel essentially got rid of it and launched i226. That one also seems to be problematic [1] . Why is it exponentially harder to make a 2.5gbps NIC when the 1gbps NIC (i210 and i211) has worked well for them. Shouldn't it be trivial to make it 2.5x? They seem to make good 10gbps NICs so I would assume 2.5gbps shouldn't need a 5th try from intel ? [1] - https://shorturl.at/esCNP

I'm interested in clicking your link just not through a shortener. Perhaps just my own bias but figured I'd surface that reaction here. Much more useful to see the domain I'll end up on.

I didn't realise the URL shortener part. Slipped my mind that I could have just pasted the original anandtech link instead.

Re: Linux network performance parameters

#117

Post by joveian »

joveian wrote: post #112
drewg123 wrote: post #110

Earlier quoted context omitted.

No, fast retransmit basically does what it says -- retransmits things quicker. However, it is orthogonal to what the congestion control (CC) algorithm decides to do with the send window in the face of loss. Older CC like Reno halves the send window. Newer ones like CUBIC are more aggressive, and cut the window less (and grow it faster). However, RACK and BBR are still superior in the face of a lossy link.

Depending on the particular situation maybe vegas would work as well? In particular, since Wireguard is UDP, using vegas over Wireguard seems to me like it should be good (based on a very limited understanding, though :/ ), it is just a question of how well it would work on the other side of the reverse proxy since I don't think it can be set per link?

Er, I was confused; of course being over UDP won't make the kind of difference I was thinking since the congestion control is just about when packets are sent. Although I heard a while back that UDP packets can be dropped more quickly during congestion. If that is the case and the congestion isn't too severe (but leading to dropped packets because it is over UDP) then possibly vegas would help.
Post reply on HN