Ridiculously low download speed (~8 kByte/sec)

PMc

PMc

The situation:
I have a LAN:

[Workstation] ---- [gateway] ----- [router] -> Internet-uplink

All three are FreeBSD 12.2, and seem to work well: all upload and download works to the expected bandwidth of the uplink.

Then I have another machine in the cloud. Also FreeBSD 12.2. And when I try to download from that machine onto [Workstation], ssh/scp runs with 8 to 17 kByte /sec.
When I try to download onto [gateway] or [router], it runs with some 60 to 100 kByte /sec.
Then, when I switch OFF the firewall on the cloud machine ( ipfw add 1 allow all from any to any), the speed rises from 8 kByte to some 350 kByte / sec. (which is still not full bandwidth).
But, if I reboot the cloud machine into their rescue image (some FreeBSD 11.2), then the downloads run with the full available speed, as one would normally expect.

So it cannot be a hardware problem, neither a network issue. It must be something in the configuration of the FreeBSD 12.2. (Somehow it appears like those TCP window sizing matters - but I thought that is all autotuning nowadays and no longer an issue under normal circumstances - or at least not to such extreme effects.)
 
Ah, thanks. More fun coming in.

I just learned two more things:
The [gateway] has a traffic shaper (dummynet) configured. This is not on the [router], because the router is a vnet-jail, and dummynet is not vnet-aware, it can be only on the host (but all the jails can then read and manipulate it). So, after switching the traffic shaper on and off a few times and experiencing more strange network interruptions, I finally got a total eclipse of interruption, and when the system came up again I had a crashdump where the whole message area is filled with thousands of these:
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */
qfq_dequeue BUG/* non-workconserving leaf */

The cloud machine, meanwhile, needed only one single ifconfig. And now I had a not-really-amused service personnel, because they had to walk to the compute-center and switch on the power again, because ifconfig does not only power down the machine, but also the IPMI. (Actually that's news to me,, but, well, it's DELL quality - so I don't want to know the details.)

More fun this will be, because security/suricata (in inline mode) needs a very subtly crafted assortment of ifconfig switches, and basically one has to try them all out - which in this case seems to mean: either they work, or they power down the IPMI.

aragats said:
That's kind of a known issue, I filed several bug reports, in particular, with Cloudatcost.
See this thread. The initial image was indeed 11.2 ― as you mentioned.
Click to expand...
Hm, Yours' a VPS. That then seems rather not so related. Mine is an old DELL blade, but real metal.
 
You must log in or register to reply here.
Back
Top