Quote from: chemlud on January 19, 2026, 09:10:41 AMHi, have a problem that bugs me for years, no solution found yet:Based on your iperf results and the specific hardware combination (Realtek + Coreboot), this is a classic case of TCP Offloading or Interrupt Throttling issues common with Realtek drivers on Linux.
Two clients with Linux, same update status:
1. SLOW: Libretrend i7 with Coreboot, Realtek NIC
2. FAST: Old Dell Precision M6500 notebook with Intel NIC.
Problem: when downloading e.g. updates, the FAST ist 30-times faster than SLOW, see attached.
Same mirrors,RJ45 cables changed twice, both attached to the same switch. So no real explanation.
Yesterday I did some iperf between the two clients.
For UDP, it does not matter, which is server and whicch is client:
20260118145326,SLOW,FAST,45678,1,0.0-30.0,3935190,1048952,0.025,0,2677,0.000,0
20260118145446,FAST,SLOW,45678,1,0.0-30.0,3935190,1048950,-nan,0,-1,-0.000,0
But for TCP direction matters:
20260118144505,SLOW,FAST,45678,1,0.0-30.0,3533963328,941434163
20260118144740,FAST,SLOW,45678,1,0.0-30.1,1690173504,449722645
-------------------------
First thought: RJ45 in SLOW machine is Realtek. But I have Realtek in other machines with same linux, always maxing out the bandwith possible. So I don't think it'S simply Realtek.
Why only TCP makes a difference? Is there offloading and that doesn't work properly in the SLOW machine? Maybe due to Coreboot @soundboard?
Any ideas how this difference in TCP-speed might be explainable?
:-)
Quote from: LHoust on Today at 04:37:25 AMI was also observing hostwatch running at nearly 100% CPU...
I Proof my OPNsense Updates within a VirtualBox VM running on an Ubuntu 24.04.3 Host, where my /home Partition sits on a HDD...
With 25.7.11_2 I was also observing a Serious Level of HDD Thrashing, until I disabled Automatic Discovery!!!
2026-01-20T15:37:42-08:00 Warning dnsmasq overflow: 15 log entries lost
2026-01-20T15:37:42-08:00 Warning dnsmasq overflow: 4 log entries lost
2026-01-20T15:37:42-08:00 Warning dnsmasq overflow: 15 log entries lost
2026-01-20T15:09:39-08:00 Warning dnsmasq overflow: 9 log entries lost
<dhcp>
<no_interface/>
<fqdn>1</fqdn>
<domain/>
<local>1</local>
<lease_max/>
<authoritative>1</authoritative>
<default_fw_rules>1</default_fw_rules>
<reply_delay/>
<enable_ra>1</enable_ra>
<nosync>0</nosync>
<log_dhcp>0</log_dhcp>
<log_quiet>0</log_quiet>
</dhcp>
{% if dnsmasq.dhcp.log_dhcp %}
log-dhcp
{% endif %}
{% if dnsmasq.dhcp.log_quiet %}
quiet-dhcp
quiet-dhcp6
quiet-ra
quiet-tftp
{% endif %}log-dhcp
quiet-dhcp
quiet-dhcp6
quiet-ra
quiet-tftp
Quote from: meyergru on January 20, 2026, 09:59:12 PMIn theory, MSS should be set to MTU-40, but OpnSense does some trickery with the input value, so I would not set it at all.
Quote from: Patrick M. Hausen on January 20, 2026, 10:01:43 PMSet it to the MTU and OPNsense will use MTU - 40 for IPv4 and MTU - 60 for IPv6 which is the reason why you do not put the effective MSS in that field. Because that is different for both protocols.Okay, so from what I'm gathering, only the MTU should be set in OPNsense itself, and both the Proxmox VirtIO interfaces and their bridges (in WAN and LAN) should stay at the default 1500 MTU value in order to have OPNsense make the corresponding calculations for each protocol.