On 04/16/2014 07:55 AM, Matija Glavinic Pecotic wrote: > Hello, > > On 16.04.2014 11:02, Alexander Sverdlin wrote: >> Hi Dongsheng! >> >> On 16/04/14 10:39, ext Dongsheng Song wrote: >>> >From my testing, netperf throughput from 600 Mbit/s drop to 6 Mbit/s, >>> the penalty is 99 %. >> >> The question was, do you see this as a problem of the new rwnd algorithm? >> If yes, how exactly? The algorithm actually has no preference to any >> amount of data. >> It was fine-tuned before to serve as congestion control algorithm, but >> this should >> be located elsewhere. Perhaps, indeed, a re-use of congestion control >> modules from >> TCP would be possible... > > Its also worth to note that sctp specifies rfc2581 for congestion > control. TCP obsoleted that one in favor of 5681. > > @Vlad, after Alexanders comment, it seems to be that you were referring > to performance penalty. At first, I understood you refer to some penalty > in rwnd calculation against buffer/rwnd value/something else. Thats why > I asked that. > > What also might be is that we are hitting SWS. I remember us observing > some scenarios in which SWS is broken, new rwnd might have triggered it > fully. > > In any case, after some thought in the meantime, I'm pretty much sure > that we need to improve congestion control and that new rwnd calculation > is correct approach. I am not sure where congestion control is broken. It might be nice to add a periodic SCTP_STATUS call to netperf/iperf to see what the state of the congestion window and peer receive window is. Alternatively, an quick stap script to examine these values could also be useful. -vlad > >>> http://www.spinics.net/lists/linux-sctp/msg03308.html >>> >>> >>> On Wed, Apr 16, 2014 at 2:57 PM, Matija Glavinic Pecotic >>> <matija.glavinic-pecotic.ext@xxxxxxx> wrote: >>>> >>>> Hello Vlad, >>>> >>>> On 04/14/2014 09:57 PM, ext Vlad Yasevich wrote: >>>>> The base approach is sound. The idea is to calculate rwnd based >>>>> on receiver buffer available. The algorithm chosen however, is >>>>> gives a much higher preference to small data and penalizes large >>>>> data transfers. We need to figure our something else here.. >>>> >>>> I don't follow you here. Could you please explain what do you see as >>>> penalty? >>>> >>>> Thanks, >>>> >>>> Matija >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >>>> linux-sctp" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >> -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
