[c-nsp] Internet speed

[James Bensley]

On 12 August 2018 at 20:39, Jason Lixfeld <jason at lixfeld.ca> wrote:
> This thread has me thinking about cases where a MetroE customer might call and complain about throughput issues, and troubleshooting would normally require a truck roll to hook up an Ethernet test set.
>
> Does anyone know of a Y.1564 client application, or know of any past work done around creating one?
>
> I’m wondering if a client-side application could be a practical alternative to said truck roll.

Hi Jason,

I'm VERY interested in this too. I think this is a major gap in the
open source market.

A few years ago I started writing an Ethernet testing tool in C
(mainly to learn C). It doesn't provide any RFC2544 or Y.1564 testing,
it's just like iPerf but for Ethernet. Is it the best tool for the job
- no, did I learn some C - yes:
https://github.com/jwbensley/Etherate

Bandwidth wise it's good for 1Gbps, you can push 10Gbps if you have a
fast enough CPU and use 1500 byte frames. 1Gbps is rapidly become "too
slow" though and we need some software that MUST push 10Gbps with 1500
and ideally but not required 10Gbps with 64 byte frames. If you just
want to saturate a 10Gbps link you can do that easily with the 2nd
program I wrote in C, to teach myself about different network options
within the Linux Kernel:
https://github.com/jwbensley/EtherateMT

^ It's multithreaded so it can send/sink higher traffic rates but has
basically no options to change MAC addresses or Ethertype or insert a
VLAN etc, it's just a dumb load generator/sinker. My test boxes were
both 8 core 2.1Ghz Xeons, 1 worker thread sends about 9.7Gbps so I
needed 2 worker threads to get 10Gbps with 1500 byte frames. I didn’t
have enough cores for 10Gbps @ 64 byte frames, EtherateMT can send
about 1Mpps, so you need approximately 14.4 worker thread and I had 8
core per test box :)

I then started to look at how one might gather statistics and take
measurements at such high traffic rates - it basically can't/couldn’t
be done using native Kernel networking. DPDK allows one to send 10Gbps
@ 64 byte packets using a single core, so you have plenty of spare
cores to gather statistics on. So I started writing RFC2544 tests
using MoonGen (LUA bindings for DPDK):
https://github.com/jwbensley/MoonGen-Scripts

^ This has it’s own set of problems – the Lua bindings need updating
as DPDK evolves. You’re restricted to DPDK support NICs etc. So I’ve
given up on that too for now.

I am interesting in writing an open source RFC2544 and Y.1564
compliant tester, I just recently changed jobs and my new company has
hardware testers for RFC2544, Y.1564, RFC6349 and OAM. I think that
XDP is the way forward in the Linux Kernel and now I have access to
hardware testers I can valid the software results against the hardware
testers.

I’m open to collaboration on this if anyone else is intersted :)

Cheers,
James.