<div dir="ltr"><div>The realtek is definitely not ideal.   The test needs to watch the ptp stats to make sure the corrections are stable over the life of the test and throw out bad results per test equipment introducing too much error.<br><br>Qualifying a NIC for use in test equipment is a bit of a pain.  My rationale is to avoid consumer grade products, rather leverage the work of engineers that qualify equipment for data centers, i.e. the data center market is driving the vendor.   I find the INTC server class NICs to be the best for this so far.<br><br>Bob</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 5, 2017 at 5:57 AM, Pete Heist <span dir="ltr"><<a href="mailto:peteheist@gmail.com" target="_blank">peteheist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Nov 5, 2017, at 2:42 AM, Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com" target="_blank">bob.mcmahon@broadcom.com</a>> wrote:</div><br class="m_-142968380318613492Apple-interchange-newline"><div><div dir="ltr">I have some brix with realtek and run ptpd installed with fedora 25.    The corrections are in the 25 microsecond range, though there are anomalies.  These are used for wifi DUTs that go into RF enclosures.  <br><div><br></div><div>[root@hera ~]# tail -n 1 /var/log/ptpd2.stats</div><div>2017-11-04 18:33:46.723476, slv, 0cc47afffea87386(unknown)/1,  0.000000000, <span style="background-color:rgb(255,255,0)">-0.000018381</span>,  0.000000000, -0.000018463, 1528.032750001, S, 0.000000000, 0, -0.000018988, 1403, 1576, 17, -0.000018463,  0.000000000</div><div><br></div>For LAN/WAN traffic, I tend to use the intel quad server adapters in a supermicro mb desktop with 8 or more real cores.  (I think the data center class machines are worth it.)<br></div></div></blockquote><br></div></span><div>Thanks for the info. I was wondering how large the PTP error would be with software timestamps, and I see it’s not bad for most purposes.</div><div><br></div><div>Which Realtek Linux driver does your brix use, and is it stable? The r8169 driver’s BQL support was reverted at some point and it doesn’t look like that has changed.</div><div><br></div><div>I trust that the extra cores can help, particularly for tests with high flow counts, but my project budget won’t allow it, and used hardware is too much to think about at the moment.</div><div><br></div><div>Do you (or anyone) know of any problems with running the Flent client and server on the same box? In the case of the Proliant Microserver, the Broadcom 5720 adapter should have separate PCI data paths for each NIC. I guess the bottleneck will still mainly be the CPU. To get some idea of what's possible on my current hardware, I tried running rrul_be_nflows tests with the Flent client and server on the same box, through its local adapter (with MTU set to 1500) with my current Mac Mini (2.26 GHz Core2 Duo P7550). I know that doesn’t predict how it will work over Ethernet, but it’s a start.</div><div><br></div><div><a href="https://docs.google.com/spreadsheets/d/1MVxGsreiGKNXhfkMIheNFrH_GVllFfiH9RU5ws5l_aY/edit#gid=1583696271" target="_blank">https://docs.google.com/<wbr>spreadsheets/d/<wbr>1MVxGsreiGKNXhfkMIheNFrH_<wbr>GVllFfiH9RU5ws5l_aY/edit#gid=<wbr>1583696271</a></div><div><br></div><div>Although total throughput is pretty good for a low-end CPU, I’m not sure I’d trust the results above 64/64 flows. 256/256 flows was an epic fail, but I won’t be doing that kind of test.</div></div></blockquote></div><br></div>