Re: Network very very slow... was iSCSI and jumbo frames

[RVP <rvp%SDF.ORG@localhost>]

On Wed, 3 Feb 2021, BERTRAND Joël wrote:

> 	Of course, but with dd, I only obtain :
>
> legendre# dd if=/dev/zero of=/opt/bacula/test.dd count=10 bs=10m
> 10+0 records in
> 10+0 records out
> 104857600 bytes transferred in 0.537 secs (195265549 bytes/sec)

This looks reasonable.

> legendre# dd if=/dev/zero of=/opt/bacula/test.dd count=10 bs=100m
> 10+0 records in
> 10+0 records out
> 1048576000 bytes transferred in 53.396 secs (19637725 bytes/sec)

This is odd. How much of RAM do you have on the NetBSD client? And,
how much disk space is free?

If you don't have free RAM, or a lot of free disk space to spare, then
dd(1) allocating a 100MB buffer for I/O might slow things down, esp.
as you haven't passed `iflag=direct oflag=creat,direct' to bypass the
FS caches. Still, this is odd. Creating a 1GB file should not take so
long.

> legendre# dd if=/dev/zero of=/opt/bacula/test.dd count=10 bs=1000m
> 10+0 records in
> 10+0 records out
> 10485760000 bytes transferred in 1026.927 secs (10210813 bytes/sec)
> legendre#

This is an atypical workload. 1GB of RAM is tied up by dd(1) for its
I/O _and_ then you're creating a 10GB file which means the system is
definitely allocating doubly/triply-indirected blocks. FS performance
in such cases would not be optimal. On my directly-connected old laptop
SATA disk I get 1/2 the speed of the `bs=10m' case (~80 MB/sec).

I wouldn't be surprised if the OS had started using swap during this
dd run.

> And I don't understand. If iSCSI target or raid6 subsystem on qNAP were
> the bottleneck, CPU load should be greater than 1 and it's not the case.

Use top(1) on the NAS; looking CPU load is not very useful here.

> Maybe I will try to add a SSD disk as cache (but I'm not sure that this
> NAS supports cache over USB3).

How're the disks connected to the client (SATA?) and to the NAS (USB3?)?

Q for the FS devs: does FFS+WAPBL honour the O_DIRECT flag? Because
even with `iflag=direct oflag=creat,direct', top(1) shows a steadily
shrinking `Free' mem and a steadily increasing `File' mem.

-RVP