rafi Posted June 19, 2010 Report Share Posted June 19, 2010 Many have obserbved larger amount of Packets Per Second in the 2.X line. The main reasons were:A- adding of uTP protocol (to the existing TCP ) B- increased bt.connect_rate C- much higher half_open default (Win7/Vista) D- use of smaller packets (and more of them) for payload traffic A/D is payload traffic relatedB/C is connection-relatedAll of that causes more packets & higher PPS, thus:1- inefficiant traffic/data transfer ( -> high overhead)2- failures of older network equipment (SOHO-routers/ISPs)3- more Internet traffic in generalThe latest 2.03 beta-release seems to improve on issues A/D and 1, that were repeatedly raised in this forum, by increasing the payload packets sizes. After this, PPS is still much higher than in pre-2.x releases. I suggest to further decrease PPS by aiming at the connection related PPS issues (B/C) . uT increased PPS is also due to:a- Using concurrent uTP + TCP connections attempts (doubled, x2) b- Retring uTP connection - 3 times to un-responsive peers in the list (and most of them are so for many reasons). This also triples the effective connect_rate (x3) !c- Effectively eliminating the '8' max_halfopen limit (= concurrent TCP connection attempts). This made # of the concurrent attempts - sometimes theoreticaly unlimitted (in steady state it's limited by the max peers #)My suggestions for lowering PPS are:1)For improving "b" (useless uTP retries) - I suggest to NOT retry to connect with uTP at all . The main "pro" reasons:- most peers do not respond anyways (no uTP support, some internal limit reached)- The concurent TCP connection request a kind of retry/backup by itself- the next peer in the list is being connected to, and this is a kind of re-ry too- the non-responsive peer will be re-tried when the peers-list is cycled the next timecons:- missing some reachable peers due to comm. errors. 2)For improving "c" (huge max_halfopen) - I suggest to impose a lower "max_halfopen" 'window' on all Windows OSes again. Setting a "max_halfopen" of "32" will be good enough for non XP systems. Since we have eliminated holdups/retries for uTP I also suggest to add a similar 'half_open-like Window' restrain for uTP as well. A "32" will be good here too. Alltogether we'll now have a default of 64 concurrent connections for uTP + TCP (40 for XP).Pros:- avoid bombarding network equipment with hundreds of packetscons:- slowing connection-generation rate a bit3)For improving B (high connect_rate) - reduce connect_rate from 10 to 5 connections/sec. My experience with it - (on XP) is good.pros:- directly decrease PPS (180 connections a minute is good enough)cons:- slowing down connection rate My estimate for the expected decrease (of 100% PPS of connection generation) -> #1) no retries: -65% of the uTP retry rate => ~-16 uTP PPS (-??? TCP)-> #3) lower connect_rate => ~-10 PPS (TCP + uTP)-> #2) lower TCP max_halfopen, new one for uTP => limit max connecitons to <64 on nonXP/<40 on XP I hope that all of the above will be added to final 2.03 release so to REALLY make a change for a better efeciancy and PPS.PPS (4, 14, 32) vs connect_speed (x1, x5 , x10)( incoming traffic - firewalled. uTP only) Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.