On Tue, 28 Jan 2014 22:48:25 +0100 Sebastian Sumpf <sebastian.su...@genode-labs.com> wrote: > On 01/28/2014 10:22 PM, Julian Stecklina wrote: > > On 01/28/2014 01:07 PM, Sebastian Sumpf wrote: > >> Thanks for your tests! But I don't like the 65 MBit/s thing! What > >> is going on? Is this RX or TX? > > > > For the extremely bad case, it might be interesting to capture a > > packet trace and use tcptrace/xplot on it. > > Thanks Julian, I will have a look at it, even though Alex seems to be > our plot guy .-)
Hi Sebastian, I was wondering whether you actually looked intro that as we are experiencing some strange effects with netperf as well. Let me briefly summarise our findings: We are running netperf_lwip on base-linux in order to evaluate how our changes in the software affect the networking performance. For TCP_STREAM, I get results of approx. 350Mbit/s while TCP_MAERTS results in approx. 110Mbit/s. Interestingly, this asymmetry is reverse to the results that have been discussed here. However, what actually puzzles me most is the fact that netperf_lwip_bridge draws a quite different picture. More precisely, TCP_STREAM falls down to round about 170Mbit/s which I guess is perfectly explainable by the additional context switch and copying of the nic_bridge. Yet TCP_MAERTS performs better, i.e. 130Mbit/s with the additional nic_bridge. All results are reproducible. I could also observe a similar behaviour on hw_rpi. AFAIK the netserver code for TCP_STREAM only uses recv() whereas the code for TCP_MAERTS only uses send(). Hence, it's totally comprehensible to me that we experience asymmetric throughput results depending on which path (RX or TX) performs better. However, I just don't get why the nic_bridge, which not only adds a context switch but also additional copying, increases the performance for TCP_MAERTS. I guess this might be caused by bulk processing of multiple packets enabled by the asynchronous packet-stream interface. I think I could test this by assigning a high scheduling priority to the nic_bridge so that it always processes a single packet. Up to this point I have basically two questions: 1. Has anyone made any further investigations of Genode's networking performance? 2. Any other (possible) explanations for my observations? Cheers Johannes ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
