Re: Slow network on evbarmv7h NetBSD 9

[Alexander Schreiber <als%thangorodrim.ch@localhost>]

On Tue, Dec 31, 2019 at 10:26:20AM -0600, Rich Neswold wrote:
> On Tue, Dec 31, 2019, 4:02 AM Sad Clouds <cryintothebluesky%gmail.com@localhost>
> wrote:
> 
> > On Tue, 31 Dec 2019 00:02:21 -0600
> > Rich Neswold <rich.neswold%gmail.com@localhost> wrote:
> > >     time scp -q -oCompression=no -ocipher=none junk remote:junk
> >
> > This is not a good way to test network throughput.
> 
> 
> My target machine is an older, uniprocessor Intel box but it has
> Gig-Ethernet and SATA drives. It can definitely accept data faster than
> 1.5MB/sec.
> 
> I didn't trust my other test: My Pi's flash is read-only and I NFS-mount my
> home directory from a Synology NAS with SATA drives. If I do
> 
>     dd if=/dev/zero of=junk bs=8192 count=8192
> 
> it creates the 16MB file in 2.9 seconds which is ~23MB/sec -- much better
> throughput! I wasn't sure what kind of buffering and caching was being done
> my the filesystem, so I tried the 'scp' version.

NFS file write semantics is write-through, i.e. when the RPC returns, the
data sits on stable storage. NFSv4 adds support for cached writes, but IIRC
that requires additionally fiddling to be explicitly enabled. But with that
dd you're not benchmarking network throuhput, you're benchmarking a very
specific type of NFS I/O - basically a useless test. Your scp version counts
in the entiry overhead of login, session management, encryption etc and
hence is also useless for network I/O benchmarking.

> I would recommend you use specific tools like iperf, which generate
> > data on the fly.
> >
> 
> Thanks for the pointer.

Yes, iperf is pretty good tool for benchmarking raw network throughput.

Kind regards,
            Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison