[email protected] (z411) writes: >Best case: >[ ID] Interval Transfer Bitrate >[ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec >[ 5] 1.00-2.00 sec 1.00 MBytes 8.39 Mbits/sec >[ 5] 2.00-3.00 sec 1.12 MBytes 9.44 Mbits/sec >[ 5] 3.00-4.00 sec 256 KBytes 2.10 Mbits/sec >[ 5] 4.00-5.00 sec 1.88 MBytes 15.7 Mbits/sec >[ 5] 5.00-6.00 sec 1.62 MBytes 13.6 Mbits/sec >[ 5] 6.00-7.00 sec 512 KBytes 4.19 Mbits/sec >[ 5] 7.00-8.00 sec 256 KBytes 2.10 Mbits/sec >[ 5] 8.00-9.00 sec 640 KBytes 5.24 Mbits/sec >[ 5] 9.00-10.00 sec 1.12 MBytes 9.43 Mbits/sec
>So with a increased the value it can occasionally hit higher speeds, >it's not much. And what's worse, it makes it very unstable. The "unstability" is mostly packet loss together with slow recovery. The slow recovery comes from limiting packet bursts as requested in early RFCs. Other BSDs have relaxed that a long time ago, and I'm currently running NetBSD with similar modifications in the TCP stack. What I do not yet understand is what causes the packet loss. To some degree this seems to be a consequence of running the network stack under KERNEL_LOCK, but that can only be part of the truth. Another issue is e.g. the wm(4) driver that easily sends packets out of order (and that I work around with a small patch). With my local modifications, I can now do near Gigabit wirespeed over a simulated WAN distance of 100ms (RTT). But the results over the real internet are much worse.
