Jump to content

test - PPS draft

rafi

By rafi
in Chat

Recommended Posts

rafi Advanced Member

rafi

Posted
Posted
Firon:

Computers had no problem with opening a crapton of connections before XP SP2. And they sure don't after Vista removed the stupid halfopen limits.

I agree. But the issue is (I guess) "crappy network equipment" and possibly redundant connecting traffic , and not "crappy PCs"... :P

I'll do my best below to answer Greg Hazel's comments.

I have also to emphasize - that I have no issue with PPS on my own PC/router. My ISP though, seems to think otherwise regarding his equipment.

Greg Hazel: How high is PPS compared to previous uT releases?

The topic is about connection related PPS. So, If I tell you that it's ~500+% higher than 1.85 during speed buildup/connections generation (when connections #< max # of peers to connect) would you believe me ?

So, I suggest that you do your own homework and measure it . It's not that difficult. Even for you guys... :P

Anyways, keeping PPS as low as possible is best, regardless.

My theory:

+100% - adding outgoing uTP as default

+50-100% - the uTP retries

+300% - incrementing max_halfopen from 8 to 400 (actually - more-packets/for-longer-duration)

Is this amount still too high for some crappy routers?

Dunno for myself. Other people/mods/ISPs in this forum seem to think that it is. You try it out, and tell me what is an acceptable #, and I can then tell you if it's high or not.

I'm sure that you are much better equipped/capable than me in measuring data on the various OSes (I have only one).

[a.concurrent uTP/TCP connects:]

OK. Let's get everyone to use uTP and then we can switch off TCP attempts.

I agree. But until this utopia is realized (in 3-5 years?), let's try and deal with current reality instead.

Maybe improve on this x2/+100% factor (and it's much increased with retries) by sending TCP after uTP requests only on time-outs or visa-versa ?

[b.uTP connect retries]

Uh, the behavior here is no different from TCP.

... B) Should we not retry TCP connections either?

OK, than I was wrong, this multiplies the related PPS X6 times than the connect_rate (I was measuring uTP only, since it's new/added in v2.x).

If you measure the statistics on success rate of the retries (2nd/3rd ones), then we can logically deduct if this contributes to more connections, or more PPS ;) . For now, I take the number of 90% un-connect-able peers as a criteria, and I deducted that we better save our breath (PPS...) here. And yes, maybe not retry both protocols ...

Not hammering peers will be a good result too. Alternatively - one retry will also improve PPS.

Haha.

A) I believe most peers support uTP.

Great. so we'll need less TCP connects if done sequentially after uTP... ( I was going to say - "not for long", first ... ;) )

Again, newer versions (and for that matter, older versions) of Windows do not have a max halfopen limit anymore.

So, this is no different from TCP. Also, since a significant amount of bandwidth is not consumed with connection

attempts, I have a hard time believing PPS is significantly higher as a result of concurrent connections per second.

1. Again, the topic is about connecting-related-PPS, not bandwidth (and I also think it does NOT consume much bandwidth)

2. You don't need to believe anything. Just test it. You tell me if x2 of the connect speed (+100%) is significant or not (unless you divide connect_speed by 2 - for concurrent TCP+uTP)

3. halfopen has different effects on # of packets/PPS - it does not effects directly the PPS, but the packets' burst duration.

4. hugely increased max_halfopen will make the connection attempts keep for a much longer period of time (theoretically - 400/10 = 40 seconds minimum).

[cycling peers' list]

There is no peer list "cycle". Peers are tried in random order if we have not retried them too recently.

I'm sure I don't know the exact details here (I assumed it is implemented this way). Random is good (equal rights for peers?...). I would try to exhaust the whole list first before re-trying an unresponsive peer, so to increase the change for success.

If uT is retrying a peer, there is no one to move on to.

You better double check the code than. Since I've noticed retries starting right on startup, also with a 10K+ peers list. It is my impression that it is triggered just by connect timeout. If it should be like you say (and we assume bugs exist in utopia too) - just make it so, and the result is similar to what I referred to as "cycle" the peers' list. Problem solved :)

Outgoing connections, @10K+ swarm, all inputs - firewalled , only TCP and only uTP runs

http://img30.imageshack.us/img30/4922/tcpretryx336s.png

http://img28.imageshack.us/img28/9035/utpretryx4246s.png

You still haven't shown that this "bombarding" is harmful. Why arbitrarily slow down the connection rate on a hunch?

Me ? I have to show it ? I thought you are responsible for development, testing and support issues... Just look around the forum. Don't you remember ? The ISPs bitching threads ? multiple other users having what you define as "crappy" equipment ? .. Give me a break please. My router is fine, thank you ... ;)

There's no point in optimizing if the problem is already fixed.

If you mean - fixing the payload related PPS (that, after 6 months, does look promising... :) ) - again, this is not the issue on this thread. I'm not aware of any change done in 2.03/x to improve the connection-related PPS (at least it's not in the changelogs)

The increased amount/PPS of small payload packets, small connection related packets and maybe uTP connect-scheme - has done much harm for the past 6 months (PTs, ISPs). Payload traffic/packets is hopefully improved now (and I hope overhead will also be reduced), What I'm saying is - try to improve 2.03 in respect to correction-logic/rate as well.

And there is always a point in optimizing Internet traffic if it's not actually needed.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing
×
×
  • Create New...