On 12 August 2018 at 20:39, Jason Lixfeld <[email protected]> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
