<div dir="ltr">Hello Norman,<div><br></div><div style>I've done test for nic_bridge, and I've updated page with results <a href="http://ksyslabs.org/doku.php?id=genode_network_perfomance#nic_bridge_test">http://ksyslabs.org/doku.php?id=genode_network_perfomance#nic_bridge_test</a></div>
</div><div class="gmail_extra"><br clear="all"><div>--<br>Ivan Loskutov<br><br></div>
<br><br><div class="gmail_quote">2013/3/20 Norman Feske <span dir="ltr"><<a href="mailto:norman.feske@...1..." target="_blank">norman.feske@...1...</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Vasily,<br>
<br>
thanks for this nuanced discussion. It helps me lot to understand your<br>
situation. For example, I didn't have the binary-blob problem on my<br>
radar at all.<br>
<div class="im"><br>
> I agree that would be worth L4Linux seen only as a sandbox for Linux<br>
> binaries execution. Again, ideologically correct exclude drivers from<br>
> L4Linux. But there are some problems. In addition to the noticed above<br>
> there is another one. Is is a performance. Now we make some<br>
> experiments with L4linux as gateway with two dedicated NIC drivers and<br>
> L4Linux. And we see that the performance degradation is around 85% in<br>
> contrast with Linux. That is too much, and if it turns that the moving<br>
> NIC driver back to L4Linux ( ie if we give acces L4Linux network<br>
> driver to HW) can decrease performance degradation (security<br>
> architecture allows to do it), we will use this approach.<br>
<br>
</div>I suspect that the poor networking performance stems from the dde_ipxe<br>
networking driver, not L4Linux. I would definitely recommend to<br>
benchmark the dde_ipxe networking driver individually without L4Linux.<br>
E.g., by adding some code to the driver that transmits a predefined<br>
network packet and measure the throughput achieved.<br>
<br>
Another test would be to connect two L4Linux instances via nic_bridge<br>
and perform the benchmark between both instances. If the communication<br>
over the virtual network performs well, we can rule out L4Linux and the<br>
'Nic_session' interface from being the problem.<br>
<div class="im"><br>
> And oddly enough, the applications for the ARM easier develop from<br>
> scratch and not use L4Linux for binaries execution. While software for<br>
> network equipment, based on x86, increasingly require re-using.<br>
> We have not looked NOVA and Vancouver yet. If we can not solve<br>
> performance problems with L4Linux we will "taste" them.<br>
<br>
</div>Please let us know how you like the taste once you try it. ;-)<br>
<div class="im HOEnZb"><br>
Norman<br>
<br>
--<br>
Dr.-Ing. Norman Feske<br>
Genode Labs<br>
<br>
<a href="http://www.genode-labs.com" target="_blank">http://www.genode-labs.com</a> · <a href="http://genode.org" target="_blank">http://genode.org</a><br>
<br>
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden<br>
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth<br>
<br>
</div><div class="HOEnZb"><div class="h5">------------------------------------------------------------------------------<br>
Everyone hates slow websites. So do we.<br>
Make your web apps faster with AppDynamics<br>
Download AppDynamics Lite for free today:<br>
<a href="http://p.sf.net/sfu/appdyn_d2d_mar" target="_blank">http://p.sf.net/sfu/appdyn_d2d_mar</a><br>
_______________________________________________<br>
Genode-main mailing list<br>
<a href="mailto:Genode-main@lists.sourceforge.net">Genode-main@...12...ceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/genode-main" target="_blank">https://lists.sourceforge.net/lists/listinfo/genode-main</a><br>
</div></div></blockquote></div><br></div>