[00:23:23] *** waldorf_ has joined #bittorrent
[00:33:52] *** Andrius has quit IRC
[00:48:59] *** andar2 has quit IRC
[00:49:10] *** maswan has quit IRC
[00:51:55] *** Miller` has quit IRC
[00:52:13] *** Miller` has joined #bittorrent
[01:25:58] *** waldorf_ has quit IRC
[01:27:15] *** waldorf_ has joined #bittorrent
[01:46:39] *** init0_ has joined #bittorrent
[02:00:24] *** init0 has quit IRC
[02:02:25] *** waldorf_ has quit IRC
[02:13:04] *** chelz has joined #bittorrent
[02:14:40] *** medecau has quit IRC
[02:26:47] *** bbelt16ag has joined #bittorrent
[02:28:00] *** TheSHAD0W has quit IRC
[02:28:44] *** TheSHAD0W has joined #bittorrent
[02:45:03] *** klapaucjusz has joined #bittorrent
[02:45:13] <klapaucjusz> The_8472: oy.
[02:45:27] <klapaucjusz> I see you've hardwired dht.wifi.pps.jussieu.fr in your plugin.
[02:45:32] <The_8472> hi, i saw your complaint
[02:45:39] <The_8472> yeah, already fixed that
[02:45:48] <The_8472> i hope it didn't cause any trouble?
[02:45:56] <klapaucjusz> could you please be so kind as to switch to mldht.wifi.pps.jussieu.fr
[02:46:11] <klapaucjusz> ...and release straight away.
[02:46:11] <The_8472> already changed it :)
[02:46:15] <klapaucjusz> And released?
[02:46:22] <The_8472> not yet
[02:46:46] * klapaucjusz is taking out his tcpdump
[02:46:50] <klapaucjusz> It's still dht.
[02:47:04] <The_8472> yes, it is
[02:47:18] <The_8472> as i said, not released yet
[02:47:27] <klapaucjusz> I'm getting one DNS query every two seconds, and that's just one of the DNS servers.
[02:47:28] <The_8472> there are some other issues i need to fix too
[02:47:38] <klapaucjusz> The_8472: please.  That's important.
[02:47:45] <DHE> I've discovered that rtorrent's piece picker, at least in the face of solo downloading, seems to be rather not random
[02:47:53] <klapaucjusz> I really don't want to have to discard the record.
[02:48:31] <The_8472> yeah, sry. mixed up the hostnames while testing and comitted the wrong one
[02:48:43] <klapaucjusz> So please release.
[02:48:57] <The_8472> DHE, not sure if it was rtorrent, but i've seen it in other clients too
[02:49:19] <klapaucjusz> mldht is a lovely record.  It points at two bootstrap nodes, controlled by different people, in different countries, and in different ASes.
[02:49:30] <klapaucjusz> There's no reason why you should need anything else.
[02:50:09] <The_8472> no need to explain, i just put the wrong one in, that's all ^^
[02:50:23] <klapaucjusz> Then please release.
[02:50:46] <The_8472> ... yes, i will, soon
[02:51:11] <The_8472> it takes a few hours until users pick it up anyway, so let me do some testing at least
[02:56:11] *** goussx_ has joined #bittorrent
[03:12:21] *** goussx_ has quit IRC
[03:12:35] *** goussx_ has joined #bittorrent
[03:12:37] *** goussx has quit IRC
[03:12:49] *** goussx_ is now known as goussx
[03:30:48] *** mxs has joined #bittorrent
[03:31:04] *** mxs_ has quit IRC
[03:37:25] *** klapaucjusz has quit IRC
[03:38:41] *** klapaucjusz has joined #bittorrent
[03:39:07] <TheSHAD0W> Offtopic, but...
[03:39:08] <TheSHAD0W> http://www.youtube.com/watch?v=9VDvgL58h_Y
[03:42:24] *** gilles_ has joined #bittorrent
[03:45:24] <The_8472> already seen it. and it's great :)
[03:52:24] *** bittwist has quit IRC
[03:58:54] *** gilles has quit IRC
[03:59:12] *** gilles_ has quit IRC
[04:02:31] *** bittwist has joined #bittorrent
[04:05:47] *** The_8472 has quit IRC
[04:06:05] *** wadim has joined #bittorrent
[04:06:07] *** wadim is now known as The_8472
[04:06:37] <The_8472> klapaucjusz, there are some nodes that send error messages that aren't containing a list but simply a byte string... wouldn't it be appropriate to respond to that with an error message, informing them of their malformed error message? :)
[04:15:18] <klapaucjusz> Yes, and you should probably format the error message the way they do, to  make sure they can parse it.
[04:15:43] <The_8472> ah, good idea
[04:15:45] <klapaucjusz> (In DCCP, ACKs are congestion-controlled.  THat implies that you ACK ACKs.)
[04:17:43] <The_8472> hrrm, they should pad their ACK packets to MTU size
[04:17:54] <The_8472> this way the stream will be constant rate, regardless of utilization
[04:18:55] <klapaucjusz> BTW, the IPv6 DHT has just been committed into Transmission.
[04:20:21] *** klapaucjusz has quit IRC
[04:38:26] *** The_8472 has quit IRC
[04:38:38] *** goussx has quit IRC
[04:38:46] *** wadim has joined #bittorrent
[04:38:48] *** wadim is now known as The_8472
[04:39:13] *** The_8472 has quit IRC
[04:39:33] *** wadim has joined #bittorrent
[04:39:35] *** wadim is now known as The_8472
[04:48:26] *** The_8472 has quit IRC
[04:48:48] *** wadim has joined #bittorrent
[04:48:48] *** wadim is now known as The_8472
[05:12:05] *** goussx has joined #bittorrent
[05:32:20] *** mistform has joined #bittorrent
[05:47:50] *** mistform has left #bittorrent
[06:02:42] *** The_8472 has quit IRC
[06:12:02] *** nGTHK has joined #bittorrent
[06:12:02] *** GTHK has quit IRC
[06:15:16] *** GTHK has joined #bittorrent
[06:15:17] *** nGTHK has quit IRC
[06:24:55] *** nGTHK has joined #bittorrent
[06:24:56] *** GTHK has quit IRC
[06:31:43] *** GTHK has joined #bittorrent
[06:31:45] *** nGTHK has quit IRC
[06:39:23] *** GTHK has quit IRC
[06:49:12] *** GTHK has joined #bittorrent
[06:51:07] *** MassaRoddel has quit IRC
[06:59:19] *** uau has quit IRC
[07:01:44] *** flexible has quit IRC
[07:03:03] *** uau has joined #bittorrent
[07:17:06] *** MassaRoddel has joined #bittorrent
[07:43:16] *** Switeck has quit IRC
[07:51:24] *** _rafi2_ has joined #bittorrent
[07:56:27] *** _rafi_ has quit IRC
[08:23:37] *** gilles has joined #bittorrent
[08:27:54] *** bbelt16ag has quit IRC
[08:28:00] *** bbelt16ag has joined #bittorrent
[08:39:06] *** _rafi_ has joined #bittorrent
[08:39:18] *** bt42 has joined #bittorrent
[08:45:18] *** _rafi2_ has quit IRC
[08:46:00] *** Andrius has joined #bittorrent
[08:47:03] *** gilles has quit IRC
[08:47:53] *** bittwist has quit IRC
[08:48:46] *** bbelt16ag has quit IRC
[08:50:13] *** maswan has joined #bittorrent
[09:08:44] *** GTHK has quit IRC
[09:12:08] *** bbelt16ag has joined #bittorrent
[09:12:42] *** bbelt16ag has quit IRC
[09:45:35] *** waldorf_ has joined #bittorrent
[10:30:48] *** goussx_ has joined #bittorrent
[10:31:13] *** goussx_ has quit IRC
[10:31:33] *** goussx_ has joined #bittorrent
[10:34:05] *** bbelt16ag has joined #bittorrent
[10:42:19] *** cyb2063 has joined #bittorrent
[10:47:31] *** goussx has quit IRC
[10:47:31] *** goussx_ is now known as goussx
[10:50:02] *** goussx has quit IRC
[10:50:07] *** goussx_ has joined #bittorrent
[10:50:19] *** goussx_ is now known as goussx
[10:54:13] *** rdjong has joined #bittorrent
[10:55:51] *** bbelt16ag has quit IRC
[10:57:22] *** bbelt16ag has joined #bittorrent
[10:58:54] *** bittwist has joined #bittorrent
[11:17:12] *** bt42 has quit IRC
[11:23:41] *** rdjong has quit IRC
[11:50:04] *** goussx_ has joined #bittorrent
[12:02:39] *** bbelt16ag has quit IRC
[12:06:24] *** goussx has quit IRC
[12:06:24] *** goussx_ is now known as goussx
[12:19:32] *** A9[idle] has joined #bittorrent
[12:20:12] *** DWKnight has quit IRC
[12:20:20] *** mxs has quit IRC
[12:21:09] *** DWKnight has joined #bittorrent
[12:23:55] *** A9[idle] has quit IRC
[12:24:14] *** mxs has joined #bittorrent
[13:40:30] *** Andrius has quit IRC
[13:50:15] *** Andrius has joined #bittorrent
[14:53:03] *** Qb_Master has joined #bittorrent
[14:54:26] *** Qb_Master has left #bittorrent
[14:56:08] *** _rafi2_ has joined #bittorrent
[15:01:01] *** _rafi_ has quit IRC
[15:22:44] *** L337hium has joined #bittorrent
[15:24:55] *** _rafi_ has joined #bittorrent
[15:41:53] *** _rafi2_ has quit IRC
[16:09:15] *** _rafi2_ has joined #bittorrent
[16:28:02] *** _rafi_ has quit IRC
[17:00:28] *** ajaya has joined #bittorrent
[17:18:47] *** The_8472 has joined #bittorrent
[17:38:43] *** KyleK_ has joined #bittorrent
[17:39:31] *** init0_ is now known as init0
[17:42:32] *** rrr_ has quit IRC
[17:46:30] *** gilles_ has joined #bittorrent
[17:57:04] *** JudgeSHAD0W has joined #bittorrent
[17:58:23] *** gilles_ has quit IRC
[17:58:34] *** gilles_ has joined #bittorrent
[18:34:56] *** goussx has quit IRC
[18:38:11] *** midkniht has quit IRC
[18:43:42] *** Switeck has joined #bittorrent
[18:46:33] *** bittwist has quit IRC
[18:59:11] *** pevangelista has joined #bittorrent
[18:59:53] <pevangelista> Hello guys! I have a question about piece and peer selection on the BT protocol.
[19:00:00] *** goussx has joined #bittorrent
[19:00:49] <DHE> go on
[19:01:00] <pevangelista> Assume that the current piece selection policy is rarest first. And suppose that there is one piece that is the rarest in the swarm, for the sake of the example.
[19:01:19] <pevangelista> And this piece is available in a few peers that are connected to the client
[19:01:40] <pevangelista> should the client choose the peer with the highest upload rate?
[19:02:08] <DHE> can't tell what someone's upload rate is, only what your download rate from them is.
[19:02:12] <The_8472> the peer(s) has/have to unchoke you first
[19:02:29] <The_8472> and you can download one piece from several peers at once
[19:02:54] <pevangelista> oh, thats true
[19:03:33] <pevangelista> DHE: when I wrote upload rate I meant the average download rate percieved by the client
[19:05:59] <pevangelista> I'm organizing my thought now =) Thanks for the help! Any more problems and I will come back with more questions!
[19:06:47] <DWKnight> and we will attempt to have more answers
[19:11:40] *** pevangelista has quit IRC
[19:12:31] *** pevangelista has joined #bittorrent
[19:34:44] <pevangelista> I think I solved my problem! In my simulation, each connection with a peer corresponds to a thread. All threads have access to a list of available pieces and blocks. So, when two threads asks for the rarest piece, each one can get a different block of the same piece.
[19:35:29] <The_8472> you know, peers don't have a complete view of the swarm
[19:35:45] <The_8472> and there is nothing keeping them from downloading the same thing at once
[19:35:50] <pevangelista> yes, they have only a subset of the peers in the swarm
[19:36:12] <The_8472> beyond statistical improbability of course
[19:36:24] <mpl> hmm, I don't cut at the block level here; each thread is in charge of getting a whole piece...
[19:36:32] <pevangelista> I didnt understand what you meant
[19:37:02] <Switeck> also, if 2 peers are requesting the same piece...they can't share with each other
[19:37:06] <Switeck> unless 1 finishes first
[19:37:15] <DWKnight> and request blocks can't be shared
[19:37:18] <DWKnight> only full pieces
[19:37:23] <The_8472> oh wait... you're using 1 thread per connection? oO
[19:37:58] <pevangelista> yes, I am. Each TCP connection opens a thread]
[19:38:12] <The_8472> and you're simulating a whole swarm?
[19:38:23] <mpl> 1 coroutine per connection here, I figured they're light enough to do that...
[19:38:30] <pevangelista> yes
[19:38:46] <pevangelista> actually, the simulation is not capable of multi-threading
[19:38:51] <The_8472> that's possibly tenthousands of threads
[19:38:51] <pevangelista> it is a simulated thread
[19:40:24] <Switeck> If you're trying to simulate a torrent swarm, are the virtual peers/seeds given different characteristics?
[19:40:59] <pevangelista> what characteristics do you mean? Like bandwidth?
[19:41:52] <Switeck> variability of bandwidth, different BT client quirks, throttled/disrupting ISPs, hostiles...
[19:41:53] <pevangelista> Thats the idea. There are classes of Peers, each with a different behavior (such as seeding time) and characteristics (such as bandwidth)
[19:42:12] <The_8472> upload, download bandwidth, number of upload slots, number of connections, being firewalled, latency (although latency is not really important)
[19:42:23] <Switeck> some peers will quit downloading abruptly because they go into seed-only mode
[19:42:42] <Switeck> some might be foolishly trying to use initial seeding/super-seeding even while a peer!
[19:42:56] <The_8472> also, a swarm evolves over time... peers join, seeds leave. not everybody starts at the same time
[19:43:23] <pevangelista> Well, my scenario is a private network, so some things can be overlooked
[19:43:37] <The_8472> that's a pretty uncommon scenario
[19:43:44] <Switeck> the Poisson distribution curve may move closer to 0 or further away.
[19:44:20] <The_8472> which process do you think is poisson-distributed?
[19:44:36] <pevangelista> The_8472: I am researching an architecture that uses the BitTorrent protocol.
[19:44:39] *** Nolar has quit IRC
[19:44:50] <The_8472> LAN = you can use multicast. way more efficient than bittorrent
[19:46:11] <Switeck> the distribution of seeds/peers ratio (with peers also being rated as % complete) can slide around over time
[19:46:20] <Switeck> it won't follow anything like a standard bell curve
[19:46:35] <The_8472> ah yes
[19:46:50] <The_8472> i have my own little torrent-health rating scheme
[19:47:07] <The_8472> http://forum.bittorrent.org/viewtopic.php?pid=156#p156
[19:48:00] <The_8472> here, an even better one
[19:48:01] <The_8472> http://infinite-source.de/az/selectiveDownloading.jpeg
[19:48:12] <The_8472> it shows the impact of selective downloading on the swarm
[19:48:14] <pevangelista> I know that multicast is more efficient, but it cannot provide the services i am researching
[19:48:24] <pevangelista> I'm trying to find the paper that describes my project
[19:51:01] <pevangelista> Do you have access to IEEE publications?
[19:51:05] *** Nolar has joined #bittorrent
[19:51:12] <The_8472> no
[19:51:29] <pevangelista> how can I send you the pdf file?
[19:51:37] <The_8472> well, i guess i could. but i never bothred my prof about it ^^
[19:52:17] <Switeck> Other than direct LAN, what can even use multicast in relation to Bittorrent? (I've heard many/most consumer routers can't pass multicast packets outwards.)
[19:52:20] <The_8472> uhm... put it on a server?
[19:52:32] <pevangelista> I bet you could publish tons of things with the results you get with azureus
[19:52:57] <The_8472> we're not really gathering many statistics
[19:53:10] <pevangelista> hum... yeah... I don't know/have any public servers
[19:54:26] <The_8472> Switeck, home routers are one big obstacle. the other issue is if the ISP itself forwards multicast requests
[19:55:06] <The_8472> but i don't know much about it myself, nobody can give a good answer whenever i ask
[19:55:36] <DeHackEd> The_8472: is that a real swarm or did you just rig up a demo?
[19:55:44] <The_8472> a real swarm
[19:55:51] <DeHackEd> oh dear
[19:56:43] *** bittwist has joined #bittorrent
[19:57:10] <Switeck> even more fun when an individual peer or seed has multiple IP addresses that somehow propagate to the swarm/PEX/Tracker
[19:57:33] <Switeck> in the simplest form, they may have IPv4 and IPv6 (from native or Teredo)
[19:57:45] <The_8472> multihoming is really a problem... it's actually a good thing if it works
[19:57:54] <The_8472> *is not really a problem
[19:58:17] <Switeck> even more fun scenarios are 2 LAN groups on the same torrent and all using 192.168.0.x
[19:58:45] <The_8472> in that case lan peer discovery may help
[19:59:18] <pevangelista> Here, I just remembered I have a 4shared account:  http://www.4shared.com/file/158919701/adbee5b1/A_Multimedia_Delivery_Architec.html
[20:00:15] <The_8472> so... timeshifting with p2p
[20:00:19] <The_8472> that can be done with multicast too
[20:00:26] <The_8472> i never said you'd only have 1 multicast source
[20:00:34] <The_8472> you can do p2p-multicast with ssm :)
[20:00:35] <pevangelista> not so true
[20:01:18] <pevangelista> or better saying, we are trying to develop a better solution
[20:01:51] <The_8472> i can't think of anything more efficient than using SSM to augment a p2p overlay
[20:02:03] <pevangelista> timeshift with multicast demands cache servers serving the delayed content
[20:02:10] <The_8472> no
[20:02:16] <The_8472> the peers themselves multicast too
[20:02:28] <The_8472> every sink is a source too
[20:02:40] <The_8472> they just transmit at different offsets
[20:02:51] <The_8472> so you can pick which one you join
[20:02:54] <pevangelista> I don't follow... are you talking about overlay multicast?
[20:03:02] <The_8472> no, real IP multicast
[20:03:37] <The_8472> http://en.wikipedia.org/wiki/Source_specific_multicast
[20:05:26] <pevangelista> thanks for the link! I was not aware of the SSM multicast
[20:07:49] <The_8472> SSM + P2P architecture = win
[20:08:30] <The_8472> peers can negotiate who uploads what with which offset via unicast or ASM and then the actual content delivery happens via SSM
[20:08:46] <The_8472> and depending on their needs the peers can subscribe to different SSM sources
[20:11:09] <pevangelista> The_8472: What do you understand by time-shift?
[20:12:03] <The_8472> uh, depends on the context i guess. either you watch a live stream and hit the pause button and continue watching later (in that case you just have to buffer the live stream to the HDD)
[20:12:13] <The_8472> or you actually join later and want to watch from the start
[20:12:23] <pevangelista> In my case, it is the ability to pause, rewind and fast forward (until the live content is reached) the video
[20:13:44] <pevangelista> In the architecture I am studying, it is possible to rewind any amount of time, and not only to the begining of the video.
[20:14:06] <The_8472> let me put it this way: everything that bittorrent can do can be done with SSM too. in the extreme case it would boil down to 1 source and 1 sink per "connection". in the optimal case you need a lot less sources than sinks
[20:14:51] <Switeck> oh yeah, I forget...if you really want to mess up a torrent swarm -- throw a few sequential downloaders into the mix.
[20:15:32] <pevangelista> The_8472: Thats something to think about...
[20:16:17] <The_8472> coordinating SSM sources in such an overlay certainly is not trivial, but it can only perform better than bittorrent, never worse
[20:16:33] <The_8472> (assuming that multicast routing causes no additional cost within the network)
[20:17:24] *** cyb2063_ has joined #bittorrent
[20:17:26] <pevangelista> Thats a whole field of research =)
[20:18:51] <pevangelista> Switeck: What happens when sequential downloaders are present in a torrent swarm?
[20:18:51] *** L337hium has quit IRC
[20:19:02] <The_8472> http://www.azureuswiki.com/index.php?title=Sequential_downloading_is_bad
[20:19:26] <Switeck> 1 seed, 10 peers -- 5 are set to sequentially download, so they ALL demand first piece
[20:19:37] <The_8472> http://infinite-source.de/az/selectiveDownloading.jpeg <- also, this happens... just worse.
[20:19:53] <Switeck> after all 10 peers get 1 piece, only 5 have anything other than 1st piece
[20:20:08] <Switeck> none of the sequential downloaders tit-for-tat with each other
[20:21:42] <Switeck> eventually, seed leaves after reaching probably 400+% uploaded but torrent is still <100% available once seed is gone. :(
[20:21:43] <The_8472> sequential downloading is acceptable only when the swarm is backed by some fast seeds. i.e. when it only serves as offload in a more classical client-server architecture
[20:22:42] <The_8472> or when it's in a stage during its lifecycle when the number of seeds significantly exceeds the number of peers
[20:23:22] <pevangelista> Ah, I see. But why give the user the capacity to choose the priority of the files? I think it is not possible to remove this feature now, but it leads to this kind of problem, right?
[20:23:52] <Switeck> people want to download sequentially, especially for multi-file torrents
[20:23:57] <Switeck> demand is insane
[20:24:18] <Switeck> most clients have that mode, usually disabled by default though.
[20:24:40] <Switeck> (or at least a subset of that mode, such as first/last higher priority)
[20:24:56] <Switeck> BitComet has first/last higher priority mode by default
[20:25:17] <pevangelista> Maybe people should stop making way too big multi-file torrent
[20:25:20] <Switeck> for video previewing before the download finishes.
[20:25:50] <pevangelista> BitComet does that?
[20:26:02] <Switeck> best I can tell, yes
[20:26:04] <Switeck> not the answer...people make huge multi-file torrents because the files are associated with each other. The reverse is its own disaster - 1 file per torrent.
[20:26:16] <Switeck> if the torrent has 20 files, that'd be 20 separate torrents
[20:26:49] <The_8472> large torrents usually have a longer lifecycle. even with partially selective or sequential downloading they can last for years
[20:27:38] <Switeck> and even if they become unseeded, it only takes a low-end broadband connection typically less than a day to "fix"
[20:27:46] <Switeck> (by reseeding it)
[20:28:14] <Switeck> but when that happens, they *DESPERATELY NEED* a working super seed mode!
[20:29:03] *** cyb2063 has quit IRC
[20:29:29] <Switeck> otherwise sequential downloaders will tie up the seed and rare pieces will be VERY slow to propagate.
[20:34:05] <pevangelista> Switeck: I though super seed mode was already largely used. Is it not?:
[20:34:35] <Switeck> no, almost never when needed...and only when it shouldn't be XD
[20:35:53] <pevangelista> And there are stable implementations of the super seed?
[20:36:13] <Switeck> stable, yes...good, only BitTornado
[20:37:15] <pevangelista> thats... odd!! At least for me. I read about the super seed mode in a good bunch of places, and it seems a pretty good idea, XD
[20:38:04] <Switeck> it's only a good idea because the super seed cannot always see the whole swarm, due to firewalled peers, and other seeds
[20:38:43] <Switeck> or if the super seed has their connections per torrent limit set low relative current swarm size.
[20:39:59] <Switeck> if a connected peer is uploading heavily to peers the seed cannot see, the seed's uploading can stall
[20:41:51] <pevangelista> I see. There are a lot of things I haven't considered. I think my focus on LANs made me forget the problems of the internet
[20:43:01] *** MassaRoddel has quit IRC
[20:43:34] <Switeck> software firewalls even in a LAN can be 1-way as well.
[20:48:56] <pevangelista> you added some ideas to my pool, XD
[20:49:07] <pevangelista> see you guy later!
[20:49:10] *** pevangelista has quit IRC
[20:51:50] *** MassaRoddel has joined #bittorrent
[21:01:54] *** JudgeSHAD0W has quit IRC
[21:23:52] *** bittwist has quit IRC
[21:27:44] *** bittwist has joined #bittorrent
[22:13:30] *** cyb2063_ has quit IRC
[22:15:32] *** kalkin- has joined #bittorrent
[22:15:34] <kalkin-> hi
[22:15:53] <kalkin-> is there some extension which alows the client to tell the tracker that he supports encryption?
[22:16:06] <kalkin-> so other clients may request only peers which support encryption?
[22:16:19] <kalkin-> this would help a lot against traficshapers
[22:16:30] <DWKnight> no it wouldn't
[22:16:34] <DeHackEd> not really. not unless the tracker itself were over https://
[22:16:46] <DeHackEd> and even then
[22:16:50] <kalkin-> DeHackEd: k, it would help against the trafishaper in our university
[22:17:04] <kalkin-> it shapes only the p2p connections
[22:17:13] <kalkin-> not the http protocoll
[22:17:24] <DeHackEd> then I would recommend just putting your client in encrypted-only mode
[22:18:14] <kalkin-> DeHackEd: yes i did, but it takes it a _while_ until it gets some peers which support this
[22:18:29] <DeHackEd> shouldn't be that long really...
[22:18:40] <The_8472> PEX should take care of that pretty fast
[22:18:44] <DeHackEd> encryption's been aorund for years. most clients support it
[22:18:52] <kalkin-> ahhh, crap!
[22:19:03] <kalkin-> i head activeted allow unencrypted connections
[22:20:42] <kalkin-> had
[22:22:33] <kalkin-> but it's really slow
[22:23:45] <kalkin-> and i have here an 100Mbit/s connection
[22:24:34] <DHE> yeah but that's going to be shared
[22:25:01] <kalkin-> DHE: nop the whole building have a 2Gbit/s connection
[22:25:16] <kalkin-> and the switches stats shows that there is not much traffic
[22:25:26] <kalkin-> and it was faster just 2 weeks ago
[22:25:35] <The_8472> might be due to the torrent
[22:25:39] <The_8472> how many seeds/peers?
[22:25:39] <kalkin-> but then the new p2p shaper was installed
[22:26:02] <kalkin-> its house md new episode with over >2k seeders
[22:26:29] <alus> house++
[22:26:53] <kalkin-> ofcourse the client has far fewer peers, but afaik it's normal
[22:27:02] <kalkin-> it getting only 50 peers/announce
[22:27:09] <Switeck> are you firewalled?
[22:27:10] <The_8472> that's perfectly normal
[22:27:22] <Switeck> tracker cannot afford to hand out 100's of peers/announce
[22:27:27] <Switeck> it'd be like a DDoS attack
[22:27:42] <Switeck> private tracker?
[22:27:46] <kalkin-> Switeck: of course i understand it
[22:27:49] <kalkin-> Switeck: nop
[22:27:55] <Switeck> then your PEX should save you
[22:28:02] <kalkin-> Switeck: the sundart public
[22:28:05] <kalkin-> PEX?
[22:28:10] <Switeck> Peer Exchange!
[22:28:11] <kalkin-> peer exchange?
[22:28:13] <kalkin-> aka dht?
[22:28:15] <DWKnight> if it's not a private flagged torrent, then peer exchange and dht can get you your stuff
[22:28:15] <Switeck> no
[22:28:15] <DWKnight> no
[22:28:22] <Switeck> PEX is *NOT* DHT
[22:28:22] <DWKnight> peer exchange isn't the same as dht
[22:28:40] <kalkin-> ahh, k
[22:28:42] <The_8472> similar purpose, a very very different mechanism behind it
[22:29:01] <kalkin-> k, i thought there is only dht for this purpose
[22:29:04] <Switeck> you have it enabled I hope
[22:29:17] <kalkin-> ofcourse
[22:29:18] <Switeck> no, PEX is much better for "knitting" together a public torrent with a working tracker
[22:30:29] <Switeck> (than DHT)
[22:30:30] <DWKnight> DHT and PEX combined can, in many situations, cause a torrent that is duplicated across multiple unlinked trackers to link
[22:30:56] <Switeck> ...so long as enough of the peers/seeds are unfirewalled
[22:32:10] <DWKnight> private torrents cause fractured swarms
[22:32:21] <DWKnight> and as such, cause a noticable performance hit overall
[22:33:47] <kalkin-> k, now i'm getting fine results
[22:34:06] <kalkin-> not as fast as it was before the new p2p shaper, but it's better then the last days
[22:35:53] *** rrr has joined #bittorrent
[22:36:42] <Switeck> what limits you have on max coons?
[22:36:45] <Switeck> conns
[22:37:08] <kalkin-> 5k
[22:37:08] <kalkin-> 50k on all torrents
[22:37:39] <Switeck> I want to shape you now!
[22:37:46] <kalkin-> hmm, k. up 1.2Mbit
[22:37:52] <kalkin-> down only 200kbitt
[22:38:09] <kalkin-> but it's better than nothing ;)
[22:38:27] <Switeck> even for unfiltered 100 mbit/sec symmetric, 1000 connections is probably excessive.
[22:38:46] <kalkin-> dunno
[22:38:56] <kalkin-> i mean if i start a tor exit node
[22:39:02] <kalkin-> there'are lot more connections
[22:39:06] <kalkin-> at it can handle it
[22:39:27] <Switeck> tor is *NOT* BitTorrent!
[22:39:58] <alus> 1000 connections is not excessive. it totally depends on the average swarm speed, and average number of connections per peer
[22:40:02] <Switeck> tor is typically very low traffic per connection
[22:40:02] *** _rafi2_ has quit IRC
[22:40:15] <kalkin-> i know, but a connection is an connection, it don't make a diference, or do it?
[22:40:33] <DWKnight> you have a lot of protocol overhead in bittorrent swarms to factor in
[22:40:39] <Switeck> it kills average speed per connection on BitTorrent, making everyone slow
[22:40:45] <DWKnight> that grows SIGNIFICANTLY with increased connection counts
[22:41:23] <kalkin-> so whats the perfect number for connection limit?
[22:41:33] <Switeck> telling every peer you just got a piece?
[22:41:53] <alus> Switeck: uh, lower average speed but increased number of connections is a wash
[22:41:55] <Switeck> for you, maybe 200 connections per torrent
[22:42:02] <The_8472> alus, you just need many upload slots. with 100Mbit you can do 300 upload slots on 600 connections easily. the slot:connection ratio can be a lot different with that much bandwidth toy around with
[22:42:19] <alus> The_8472: connections are for downloading too.
[22:42:28] <alus> the more connections, the more optimistics
[22:42:30] <The_8472> upload slots = downloading... usually
[22:42:31] <Switeck> alus, it's bad to reduce average speed if you're using a 100 mbit/sec line to do it!
[22:42:32] <alus> and seeds
[22:42:38] <The_8472> that's just leeching imo ^^
[22:43:03] <The_8472> it's symmetric, he shouldn't have to leech optimistics
[22:44:15] <Switeck> not more than 4:1 anyway :P
[22:44:58] <Switeck> not all BT clients manage upload slots at a global level
[22:45:20] <Switeck> so 300 overall upload slots might require changes as you start/stop lots of torrents
[22:45:41] <kalkin-> k
[22:46:01] * alus has been meaning to make the choker global in uT
[22:46:16] <alus> choking is just so... coarse
[22:46:16] <Switeck> 1000 global connections should do ok
[22:46:45] <Switeck> optimistic unchoke on every torrent at once makes interesting results too
[22:46:46] <The_8472> choking on the global level is difficult. it could starve one torrent because the torrent is performing worse than the others
[22:47:14] <Switeck> better to starve one than have 5 sec intervals to 0 globally
[22:48:04] <Switeck> http://img7.imageshack.us/img7/8703/utorrentuploadcrash.png
[22:48:08] <The_8472> meh @stupid users running more torrents than their connection can handle
[22:48:33] <Switeck> http://img522.imageshack.us/img522/3038/utorrentoceanwaves2.png
[22:48:51] <The_8472> uhm, that normally is a sign of too many connections
[22:49:04] <Switeck> people WANT to run lots of torrents
[22:49:16] <The_8472> that's stupid
[22:49:22] <Switeck> I had fewer than 15 total connections
[22:49:33] <The_8472> i see that, which is odd
[22:49:48] <The_8472> we have queues and scrapes to handle torrents... one (or a handful) at a time
[22:50:09] <Switeck> it's like I said, optimistic unchoke occurs on ALL active torrents at same time
[22:50:19] <The_8472> why?
[22:50:49] <The_8472> that sounds as if the optimistics already share a global timer
[22:50:54] <alus> The_8472: so AZ chokes per-torrent?
[22:50:57] <The_8472> yes
[22:51:20] <alus> interesting
[22:51:27] <The_8472> that causes issues too though
[22:52:00] <alus> sadness in little children?
[22:52:06] <Switeck> (I had upload slot max set to 1 for my test)
[22:52:10] <The_8472> if you dynamically adjust the number of active torrents. but that should only happen if torrents are idle (0 connections), so the number of really active torrents should stay fairly constant
[22:52:34] <The_8472> ah, heh. the minimum upload slots we allow per torrent is 2
[22:52:37] <alus> Switeck: so your dips are uT switching which peer has the optimistic, I imagine?
[22:52:47] <Switeck> alus, yes
[22:52:50] <alus> ok.
[22:52:52] <alus> see The_8472's limit
[22:52:58] <alus> and don't make me write it in uT :P
[22:53:12] <Switeck> problem with a min of 2 upload slots is when someone has 20 active torrents on a 0.5 mbit/sec upload line
[22:53:29] <Switeck> or worse...
[22:53:42] <alus> ?
[22:53:52] <The_8472> well... it shouldn't be used that way, really
[22:53:53] <alus> what do you expect to happen if you set upload slots to 1
[22:54:06] <kalkin-> maeh i need a faster raid, allocating diskspace for a torrent, leeching from the internal dc++ and looking a move slows down the systam a lot
[22:54:23] <The_8472> set your client to preallocate the space...
[22:54:43] <kalkin-> that what it does at the moment
[22:55:21] <Switeck> alus, I expect the optimistic unchoke upload slot to "roam" between torrents
[22:55:34] <Switeck> so perhaps only 1 torrent at a time is using optimistic unchoke
[22:55:43] <Switeck> that puts more in tit-for-tat mode
[22:56:18] <Switeck> (assuming they've had enough time to determine decent peers to upload to!)
[22:57:28] <alus> well uT's choker is per-torrent
[22:57:35] <alus> so if won't roam across torrents
[22:57:49] <alus> and they would result in -very- slow rotation
[22:58:06] <The_8472> do all optimistics happen at the same time?
[22:58:07] <alus> s/so if won't/so it won't/
[22:58:12] <alus> they do.
[22:58:16] <alus> maybe.
[22:58:26] <Switeck> completing larger-sized pieces almost begs for slower rotation :(
[22:58:38] <The_8472> well, if they happen at different offsets form each other that would fix Switeck's issue too
[22:58:56] <The_8472> but... just running as many torrents as your connection can actually handle would fix things too ^^
[22:59:06] <kalkin-> k guys thanks you for helping and all the hints
[22:59:07] <kalkin-> cu
[22:59:27] *** kalkin- has left #bittorrent
[22:59:38] <Switeck> a seed with 4 upload slots (but only 1 fully optimistic) with 100 peers connected would take a very long time to get completed pieces out at 1 KB/sec per upload slot and 4 MB pieces.
[22:59:38] <alus> they are not staggered, but the intervals are proportional to piece size
[22:59:54] <Switeck> alus, huh?
[23:00:11] <alus> the optimistic unchoke window size is proportial to piece size
[23:00:12] <Switeck> in my screenshots, they were different piece size on my torrents
[23:00:30] <The_8472> only 1 torrent was really active though
[23:00:33] <The_8472> the rest was dead
[23:00:35] <Switeck> and the unchokes occurred at the same intervals for all
[23:00:37] <Switeck> 3
[23:00:58] <The_8472> so you were using 3 upload slots globally?
[23:00:58] <alus> ? but only one was active
[23:01:04] <Switeck> the other 2 *would've* been active, but sometimes the unchoke with 1 peer caused the peer to have the U flag but transfer nothing for 10 mins
[23:01:09] <alus> so what does it matter if the torrents are in sync or not
[23:01:24] <Switeck> once I raised upload slots to 2 they stayed constantly active
[23:01:33] <The_8472> it only matters in his case
[23:01:48] <The_8472> when all optimistics occur at once and he has only 1 slot per torrent then all unchokes get dropped at once
[23:01:54] <Switeck> http://img123.imageshack.us/img123/6711/utorrentinactivepeer.png
[23:01:58] <The_8472> causing a dropoff in bandwidth utlization
[23:02:18] <Switeck> The_8472, the unchoke even occurred on torrents with just 1 peer
[23:02:35] <Switeck> it would stop, and try to choose a different peer, choose the same peer, and stall
[23:03:00] <The_8472> heh, ok. we have some code to guard against that... i think
[23:03:08] <The_8472> at several levels even
[23:03:24] <The_8472> like chokes and unchokes annihilating each other in the queue
[23:04:10] <Switeck> in my example, the peer that was stalling...was another uTorrent client XD
[23:04:20] <The_8472> mostly because it caused trouble for lan 1:1 transfers
[23:05:16] <alus> chokes and unchokes annihilate each other in the uT queue as well
[23:09:12] <The_8472> hrrm, must be something else then
[23:17:04] *** KyleK_ has quit IRC
[23:23:34] *** GTHK has joined #bittorrent
[23:30:53] *** MassaRoddel has quit IRC
[23:51:58] *** Elrohir has joined #bittorrent





top