lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1289735532.24539.12.camel@maxim-laptop> Date: Sun, 14 Nov 2010 13:52:12 +0200 From: Maxim Levitsky <maximlevitsky@...il.com> To: Stefan Richter <stefanr@...6.in-berlin.de> Cc: linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH update 2] firewire: net: throttle TX queue before running out of tlabels On Sun, 2010-11-14 at 10:25 +0100, Stefan Richter wrote: > Maxim Levitsky wrote: > > In fact after lot of testing I see that original patch, > > '[PATCH 4/4] firewire: net: throttle TX queue before running out of > > tlabels' works the best here. > > With AR fixes, I don't see even a single fwnet_write_complete error on > > ether side. > > Well, that version missed that the rx path opened up the tx queue again. I.e. > it did not work as intended. > > > However the 'update 2' (maybe update 1 too, didn't test), lowers > > desktop->laptop throughput somewhat. > > (250 vs 227 Mbits/s). I tested this many times. > > > > Actuall raw troughput possible with UDP stream and ether no throttling > > or higher packets in flight count (I tested 50/30), it 280 Mbits/s. > > Good, I will test deeper queues with a few different controllers here. As > long as we keep a margin to 64 so that other traffic besides IPover1394 still > has a chance to acquire transaction labels, it's OK. Just tested the 'update 2' with 8-16 margin. Gives me ~250 Mbits/s TCP easily, and ~280 Mbit/s UDP. Pretty much the maximum its possible to get out of this hardware. > > > BTW, I still don't understand fully why my laptop sends only at 180 > > Mbits/s pretty much always regardless of patches or TCP/UDP. > > If it is not CPU bound, then it is because Ricoh did not optimize the AR DMA > unit as well as Texas Instruments did. You mean AT, because in the fast case (desktop->laptop), the TI transmits and Ricoh receives. In slow case Ricoh receives and TI transmits. Anyway speeds of new stack beat the old one by significant margin. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists