Messages in this thread | | | Subject | Re: [PATCH update 2] firewire: net: throttle TX queue before running out of tlabels | From | Maxim Levitsky <> | Date | Sun, 14 Nov 2010 13:52:12 +0200 |
| |
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
| |