mirror of
https://github.com/GrapheneOS/infrastructure.git
synced 2025-09-23 22:24:36 -04:00
c6156ebed7
These servers originally only had the 1Gbps base bandwidth and shaping it with CAKE worked well to make the most of it during traffic spikes for the web servers. It has little value for the nameservers since the only potentially high throughput service is non-interactive SSH. These servers now have 10Gbps burst available but are heavily limited by their single virtual core and unable to use all of it in practice. CAKE can only provide significant value when it's the bottleneck which isn't the case when the workload is CPU limited. We don't want to keep around the artificially low 1Gbps limit and it can't do much more. Unlike OVH, the practical bottleneck is the CPU and FQ has the lowest CPU usage in practice due to being very performance-oriented with a FIFO fast path and offloading TCP pacing from the TCP stack to itself. On the DNS servers, the fast path is always used in practice. Our OVH servers have a much lower enforced bandwidth limit and the way they implement it ruins fairness across flows. We definitely want to stick with CAKE for our VPS instances on OVH but it doesn't make sense on BuyVM anymore. |
||
|---|---|---|
| .. | ||
| -.slice.d | ||
| attestation.service.d | ||
| certbot-renew.service.d | ||
| chronyd.service.d | ||
| fstrim.service.d | ||
| fstrim.timer.d | ||
| nginx.service.d | ||
| plocate-updatedb.service.d | ||
| sshd.service.d | ||
| sysstat-collect.timer.d | ||
| system.slice.d | ||
| systemd-boot-update.service.d | ||
| unbound.service.d | ||
| 0.releases.grapheneos.org.fq.service | ||
| 1.releases.grapheneos.org.fq.service | ||
| 2.releases.grapheneos.org.fq.service | ||
| create-session-ticket-keys.service | ||
| rotate-session-ticket-keys.service | ||
| rotate-session-ticket-keys.timer | ||
| single.fq.service | ||
| tcp-fastopen-rotate-keys.service | ||
| tcp-fastopen-rotate-keys.timer | ||
| xfs_fsr.service | ||