[00:17:13] *** Andrius has quit IRC
[00:27:21] *** deltab has quit IRC
[00:28:12] *** alienvenom has quit IRC
[00:29:16] *** alienvenom has joined #bittorrent
[01:09:56] *** deltab has joined #bittorrent
[01:30:13] *** mxs has quit IRC
[01:30:16] *** mxs has joined #bittorrent
[01:43:20] *** cyb2063 has quit IRC
[01:49:59] *** BitTorrentBot has joined #bittorrent
[01:56:35] <TheSHAD0W> http://news.yahoo.com/s/afp/20091215/od_afp/unclimatewarmingirelandretailsexoffbeat - I think they need to regulate the emissions
[02:09:54] * The_8472 facepalms
[02:26:07] <void^_> "15 billion dollars (22 billion euros)" ...
[02:34:09] *** Nolar_ has joined #bittorrent
[02:38:46] *** Nolar has quit IRC
[02:42:56] *** Nolar_ is now known as Nolar
[03:58:51] *** The_8472 has quit IRC
[03:59:12] *** wadim has joined #bittorrent
[03:59:14] *** wadim is now known as The_8472
[04:01:37] *** K`Tetch has quit IRC
[04:07:56] *** K`Tetch has joined #bittorrent
[04:25:21] *** K`Tetch has quit IRC
[04:29:02] *** goussx has quit IRC
[04:30:33] *** K`Tetch has joined #bittorrent
[04:32:15] <TheSHAD0W> http://torrentfreak.com/utorrent-adds-video-streaming-support-091217/
[04:35:36] *** DreadWingKnight has quit IRC
[04:40:29] *** DreadWingKnight has joined #bittorrent
[04:43:52] *** DreadWingKnight has quit IRC
[04:46:31] *** goussx has joined #bittorrent
[04:53:04] *** DreadWingKnight has joined #bittorrent
[04:54:42] *** K`Tetch has quit IRC
[04:57:38] *** K`Tetch has joined #bittorrent
[05:16:43] *** burris has quit IRC
[05:17:43] *** ajaya has quit IRC
[05:18:32] *** burris has joined #bittorrent
[05:22:09] *** ajaya has joined #bittorrent
[05:58:58] *** ajaya has quit IRC
[06:45:39] *** Miller` has quit IRC
[06:48:55] *** Miller` has joined #bittorrent
[07:30:22] *** MassaRoddel has joined #bittorrent
[07:32:52] *** burris has quit IRC
[07:33:01] *** burris has joined #bittorrent
[07:34:50] *** GTHK has quit IRC
[08:21:29] *** Andrius has joined #bittorrent
[10:06:57] *** kwinz2 has quit IRC
[10:07:25] *** kwinz2 has joined #bittorrent
[10:08:42] *** goussx has quit IRC
[10:12:29] *** Waldorf has joined #bittorrent
[10:13:44] *** waldorf_ has joined #bittorrent
[10:14:45] *** waldorf_ has quit IRC
[10:18:38] *** goussx has joined #bittorrent
[10:30:42] *** goussx has quit IRC
[10:33:18] *** waldorf_ has joined #bittorrent
[10:37:30] *** goussx has joined #bittorrent
[10:57:36] *** gAtzBy has joined #bittorrent
[10:58:20] *** gAtzBy has quit IRC
[11:11:59] *** goussx has quit IRC
[11:16:44] *** The_8472 has quit IRC
[11:17:05] *** wadim has joined #bittorrent
[11:17:07] *** wadim is now known as The_8472
[11:31:11] *** Switeck has joined #bittorrent
[12:04:13] <Switeck> uTorrent v2.1 alpha adds "streaming" to its download strategies.  "Our hope is to transform getting media using uTorrent from a ?load-wait-watch-tomorrow? to more of a ?point-click-watch? experience."  http://forum.utorrent.com/viewtopic.php?pid=441754#p441754
[12:05:29] <Switeck> To me, this sounds like uTorrent will vastly reduce its efforts to get rarest pieces first.
[12:12:49] <DreadWingKnight> [3:22:48pm] <The_8472> well, doing rarest-first in addition to sequential/realtime fetching should be obvious
[12:12:49] <DreadWingKnight> [3:23:13pm] <The_8472> i'm more interested in the constraints put on it to make sure it can't be enabled when it couldn't be sustained anyway
[12:12:49] <DreadWingKnight> [3:23:37pm] <The_8472> or when it would have a significant negative impact on the swarm health
[12:12:57] <DreadWingKnight> from yesterday
[12:14:34] <Switeck> Streaming shouldn't even be CONSIDERED if availability isn't huge (like 10+).
[12:14:51] <Switeck> At least currently it seems only 1 torrent can be put in streaming mode at a time.
[12:14:58] <The_8472> an availability of 10+ is huge? oO
[12:15:24] <Switeck> apparent availability when you connect to 50 peers/seeds
[12:15:36] <Switeck> not true torrent swarm availability
[12:15:47] * kjetilho chuckles
[12:15:51] <The_8472> what if it's 10 seeds and 40 peers? ...
[12:16:14] <The_8472> then you'd essentially be streaming from the seeds while the peers got almost nothing
[12:16:17] <Switeck> It could be 1 seed and 49 peers and if availability is 10+, that still averages the same no?
[12:16:27] <The_8472> not my point
[12:16:29] <Switeck> good point
[12:16:38] <Switeck> 10 seeds and 40 peers with nothing
[12:16:41] <DreadWingKnight> honestly, I don't think this streaming functionality should be put in until bram gets his example code out
[12:16:45] <The_8472> seed:peer ratio should be considered too
[12:17:14] <Switeck> BitTyrant's aggressive leeching strategy might be better. :P
[12:18:07] <Switeck> Trackers may take a wait-and-see approach to this, but quite frankly this is sequential downloading.
[12:18:40] <DreadWingKnight> there are a fair number of private trackers that will just blanket-ban
[12:18:57] <Switeck> I think they'd be right in this case...
[12:19:19] <DreadWingKnight> rare case where I would agree
[12:19:20] <The_8472> private trackers are the least concern in this actually, since they're heavily overseeded during most of the time in a torrent's lifecycle
[12:19:22] <Switeck> though don't ban uTorrent v1.8.x and v2.0
[12:19:39] <The_8472> i'm more concerned about public torrents which take longer to get healthy
[12:19:42] <Switeck> it would ironically increase ratio scalping by slow uploaders
[12:20:19] <Switeck> This would definitely increase how long public torrents take to get healthy and decrease their resistance to hit-and-runners.
[12:21:06] <Switeck> Also, uTorrent doesn't consider source availability
[12:21:43] <Switeck> A "seed" that's uploading at 1 KB/sec globally and/or running many torrents with lots of upload slots...is hardly worthy of being called a seed.
[12:21:51] <Switeck> Yet currently, it still adds 1 to availability.
[12:22:46] <Switeck> So even a high availability for a torrent swarm is a poor metric.
[12:23:44] <The_8472> well, you can probably create a composite metric of seed:peer count, seed+peer count, availability... and then see how fast you actually can download once you're connected to it
[12:24:27] <The_8472> i'm certain that streaming should be mostly harmless with 1000 seeds and 50 peers for example ^^
[12:24:42] <The_8472> it's the rest of the torrents that need attention
[12:26:07] <Switeck> that's an understatement
[12:26:12] <DreadWingKnight> putting this in is probably a marketing decision
[12:26:24] <DreadWingKnight> which almost automatically classifies it as brain-dead
[12:27:35] <Switeck> uTorrent's seeding strategies are weak and limited relative what Azureus/Vuze has, so I doubt a pure uTorrent swarm will hold up as well.
[12:28:41] <Switeck> The *WORST* time for a peer to use this is when just starting a torrent.
[12:28:56] <Switeck> (that is all other variables held equal)
[12:28:57] <DreadWingKnight> which is when everyone is going to use it
[12:29:38] <Switeck> Their first completed pieces will add essentially nothing to the swarm and will "encourage" other new peers to do the same, because they will have *NOTHING* else to offer them.
[12:31:14] <Switeck> So even peers that are not using a sequential downloading strategy will be partially "bent" into doing so.
[12:31:28] <The_8472> actually
[12:31:36] <The_8472> rarest first will do the opposite
[12:31:58] <The_8472> so peers not doing sequential downloading will basically download in reverse order, trying to compensate for the skew intrudoced by those doing streaming
[12:32:01] <DreadWingKnight> assuming the ones not starting in sequential mode connect to seed(s)
[12:32:05] <kjetilho> I prefer to watch TV shows backwards anyway
[12:32:05] <The_8472> which means they'll have less of the first pieces
[12:32:11] <The_8472> thus being less useful for the streaming clients
[12:32:48] <Switeck> uTorrent will still request pieces from low availability peers (it's aggressive like that...which is what people want)
[12:33:01] <The_8472> i've already seen that happening on tv-season torrents. some peers downloaded the files in order (not the pieces), the other peers basically did it backwards to compensate.
[12:33:21] <Switeck> If a peer only has the first pieces, that's what they'll get.
[12:33:47] <The_8472> yes, but from other peers that offer more they'll try the last pieces first
[12:33:52] <The_8472> since they'll be the rarest ones
[12:34:06] <The_8472> thus reversing the distribution for non-streaming ones
[12:34:13] <The_8472> like i said... i've already seen that happening
[12:34:15] <kjetilho> Switeck: on the plus side there will be a glut of peers wanting to give you the early pieces
[12:34:16] <Switeck> As far as I know, uTorrent does *NOT* try to "budget" its limited download only getting rarest pieces early on.
[12:34:52] <DreadWingKnight> if I got on the phone with simon right now, I couldn't guarantee a professional conversation about this
[12:35:31] <Switeck> I've already seen heavy scattering due to my client NOT doing sequential downloading
[12:35:55] <Switeck> but even still the "weight" of first pieces still cause far more of them to fill up first.
[12:37:17] <Switeck> For the peers doing "streaming", it seems remotely possible that they snub a rarest-first client because that client is less interested in getting pieces the "streaming" client wants.
[12:38:44] <The_8472> http://forum.utorrent.com/viewtopic.php?pid=441832#p441832 <-
[12:39:07] <The_8472> average speed of 120KB/s, video bitrate 153KB/s
[12:39:08] <alus> streaming in uT is actually not as bad as sequential file downloading
[12:39:11] <The_8472> and he's trying to stream
[12:39:14] <Switeck> kjetilho, it is precisely because there is (will be) a glut of peers wanting to give you the early pieces that there is far fewer wanting to give anything else. It is a reinforcing and defeating strategy.
[12:39:53] <The_8472> alus, well, we didn't say that.
[12:40:09] <alus> just making sure it's well known :)
[12:40:15] <The_8472> but it certainly isn't good for swarm health
[12:40:19] <alus> meh
[12:40:34] <Switeck> What is worrisome is whether this "streaming" doesn't use endgame mode tricks to keep its streaming speed faster than playing speed.
[12:40:43] <alus> it will work as well as it can.
[12:40:54] <The_8472> |12:48:29| <The_8472> http://forum.utorrent.com/viewtopic.php?pid=441832#p441832 <-
[12:40:54] <The_8472> |12:48:52| <The_8472> average speed of 120KB/s, video bitrate 153KB/s
[12:40:58] <alus> if it can't stream, it doesn't. if everyone wants to stream, they will
[12:41:00] <The_8472> what is it going to do in this case
[12:41:04] <Switeck> ...which sounds exactly like what I fear.
[12:41:09] <alus> if the swarm can support it, it will
[12:41:30] <Switeck> how in the heck can uTorrent decide if the swarm can support it till after it tries?
[12:41:32] <alus> Switeck: streaming does not request dupe data
[12:41:38] <The_8472> by what metric is it determined whether the swarm can support it?
[12:41:45] <alus> it tries
[12:41:51] <kjetilho> alus: do you know how large a window it will attempt to fill?
[12:42:25] <The_8472> so, basically... whenever it can download enough pieces in sequential order to maintain streaming it'll allow the user to do so?
[12:42:25] <Switeck> It'll play havoc with larger high-bitrate videos that use 4 MB piece size.
[12:43:17] <Switeck> Because the probability that the streaming peer *CANNOT* keep up is so much greater.
[12:45:15] <alus> kjetilho: 15 seconds
[12:45:28] <The_8472> it looks into the files to determine the bitrate?
[12:45:35] <alus> kjetilho: at the encoded bitrate. plus like a 2 second fudge
[12:45:37] <Switeck> If a stream speed in excess of 1 megabit/sec download is needed, the average consumer ADSL/Cable line will be "draining" faster than they're replenishing via upload.
[12:45:39] <alus> The_8472: yes
[12:45:46] <kjetilho> fancy :)
[12:45:46] <Switeck> that 15 seconds is arbitrary
[12:46:04] <kjetilho> of course it's arbitrary
[12:46:14] <alus> Switeck: all video buffer amounts are arbitrary :P
[12:46:28] <Switeck> at HD DVD quality, 15 seconds will be *BRUTAL*
[12:46:48] <alus> uh, it's always the same, if you can support the bitrate
[12:46:54] <alus> it's 15 seconds or less of download ;)
[12:46:56] <Switeck> no
[12:47:05] <Switeck> "if you can support the bitrate"
[12:47:19] <alus> yes, if you can support the bitrate.
[12:47:20] <Switeck> implies little about your own upload
[12:47:25] <alus> upload?
[12:47:30] <Switeck> yes, *UPLOAD*
[12:47:37] <alus> sorry, what does streaming have to do with upload?
[12:47:49] <Switeck> leechers
[12:47:56] <alus> you mean users?
[12:48:30] <Switeck> yes
[12:48:55] <kjetilho> you'll leech the exact same amount
[12:49:02] <Switeck> This strategy is less likely to affect a huge swarm if it is also coupled with uploading a lot to others
[12:49:26] <Switeck> kjetilho, I don't believe it will
[12:49:39] <kjetilho> *perhaps* more people will quit the download when it finishes since they don't leave it on overnight
[12:49:52] <kjetilho> but that's not a technical issue
[12:50:17] <Switeck> given enough time, sure you'll download about the same amount.
[12:51:09] <The_8472> so, if the bitrate is 90KB/s and i have 100KB/s it'll basically only do rarest first at 10KB/s .... after the 15 second buffer has been filled too..
[12:51:56] <The_8472> if many users do that...
[12:52:11] <alus> then they all wanted to.
[12:52:19] <kjetilho> The_8472: over time it will be more, since the already rarest first will be in the window
[12:52:22] <Switeck> no, I think that'd be true even if only *YOU* do that.
[12:52:31] <The_8472> people also want to have money, that doesn't mean we allow them to take it from others...
[12:52:41] <The_8472> just because people WANT to doesn't mean it's a good idea to let them
[12:52:50] <alus> sure we do! BT steals upload bandwidth
[12:53:00] <alus> from other users, from the ISP, however you want to look at it
[12:53:08] <The_8472> nah, you "pay" for your download by uploading to others
[12:53:18] <alus> which is free to you...
[12:53:19] <The_8472> and you pay for the ISP bandwidth with money
[12:53:22] <alus> so that's the ISP theft model
[12:53:38] <The_8472> no, it's not free
[12:53:38] <Switeck> and you want that upload "pay" to be as useful as possible to others so you can continue downloading (hopefully at higher speeds)
[12:53:59] <The_8472> you have incentivize others to upload to you. you provide that incentive by uploading to them. it's basically a payment.
[12:54:08] <The_8472> in addition to the actual money you pay to the ISPs
[12:54:20] <alus> sure. and tit-for-tat will keep that market balanced
[12:54:26] <alus> even if some people value pieces differently
[12:54:34] <Switeck> This derails tit-for-tat, at least slightly.
[12:54:41] <alus> no, it doesn't
[12:54:52] <The_8472> except that tit-for-tat can't work with tiered swarms due to sequential downloading, since there is a lack of mutual interest
[12:55:20] <Switeck> If you're only getting rarest pieces at a tiny fraction of your max download even when "ample" uploaders are available...
[12:55:21] <The_8472> peer has streamed 90%, other peer has streamed 10%. 90%-peer won't be interested in the 10% one
[12:55:44] <alus> that's good...
[12:55:46] <kjetilho> alus: did you consider tracker extensions so that peers can indicate say, which percentile they're currently interested in?
[12:55:56] <alus> it puts back-pressure on people trying to stream
[12:56:10] <alus> kjetilho: yes. for DNA we had implemented that
[12:56:11] <The_8472> people don't know that
[12:56:27] <The_8472> they just want to stream and don't care about the impact. they don't even know about it
[12:56:31] <alus> The_8472: they don't need to. they just need to look at the time-to-stream ETA
[12:56:35] <The_8472> for many of them it probably works like youtube...
[12:56:45] <alus> exactly! that's great.
[12:56:45] <kjetilho> The_8472: you're saying that as if it's a bad thing?
[12:56:50] <The_8472> yes
[12:56:53] <Switeck> A peer that has everything that you do is useless to you at the moment.
[12:56:58] <The_8472> because they don't know what harm they might be doing
[12:57:12] <kjetilho> Switeck: yes, but new clients will be joining all the time
[12:57:14] <alus> it's not harm. it's value they're extracting, because they want it
[12:57:22] <kjetilho> Switeck: you're useless to all the seeds, too
[12:57:31] <Switeck> correct
[12:57:32] <The_8472> alus, you are lacking the global perspective
[12:57:40] <Switeck> but Bittorrent is pull driven, not push
[12:57:45] <alus> The_8472: I think this balances globally.
[12:57:50] <The_8472> and they might actually be harming themselves too by lowering the swarm health and thus delaying the download
[12:57:53] <Switeck> seeds don't choose what pieces to send others
[12:58:15] <alus> The_8472: how are they harming themselves by taking what they want sooner?
[12:58:16] <Switeck> And are left vulnerable to sequential downloaders even if they have a better overview of the torrent swarm.
[12:58:22] <The_8472> in some cases streaming might actually kill a torrent.
[12:58:43] <alus> well that's not true. streaming doesn't kill torrents.
[12:58:46] <The_8472> they take the first 50% streaming, seed departs, torrent is dead.
[12:58:50] <alus> if it can't stream, it uses rarist-first
[12:58:50] <kjetilho> clients need to be smarter about booting useless peers, I guess?
[12:58:54] <The_8472> thus they harmed themselves
[12:58:57] <kjetilho> so that they can get a new set from the tracker
[12:59:16] <The_8472> instead of downloading rarest first and thus maintaining availability
[12:59:20] <kjetilho> but I think the isolated islands is very unlikely
[12:59:22] <Switeck> rarest first buffer gets drained while streamers are present.
[12:59:24] <kjetilho> +scenario
[13:00:01] <The_8472> thus they killed the torrent (globally harmful) and prevented themselves from finishing the torrent (not in their own interest)
[13:00:02] <alus> The_8472: yes, it does make the availability of the last piece slightly lower. however in our experience, often if that happens it's because no one watches that far :P
[13:00:25] <kjetilho> hehe
[13:00:48] <The_8472> i don't care. egoistic motivations of users have negative impact on others (which might include me). thus i consider it bad behavior
[13:00:48] <Switeck> I wasn't aware uTorrent was a media player
[13:00:49] <kjetilho> who bothers to watch the end credits anyway?
[13:00:59] <The_8472> tit-for-tat is egoistic behavior that improves swarm health
[13:01:05] <The_8472> streaming isn't
[13:01:07] <alus> and it's not nearly as low as you might think. non-streamers and -everyone- capable of downloading over the encoded bitrate will be helping to balance it
[13:01:27] <Switeck> hit-and-runners certainly do not
[13:01:34] <alus> Switeck: it's not a media player, it's a transport
[13:01:45] <The_8472> in some cases it will certainly lower the torrent's life expectancy by skewing the piece distribution
[13:01:54] <Switeck> then you have no way of knowing if anyone watches that far
[13:02:47] <alus> Switeck: yes we do. we know how far the media player has downloaded. they can't have watched farther than that
[13:03:12] <Switeck> media player?
[13:03:13] <alus> Switeck: and back when we used to do Flash streaming, we instrumented the Flash player to know for sure where they were
[13:03:19] <Switeck> you just said it wasn't a media player
[13:03:31] <alus> Switeck: in the uTorrent case, the media player in question is DivX Web Player
[13:03:42] <Switeck> people *OFTEN* do spot checks to make sure they're downloading what they think they're getting
[13:04:12] <alus> great. now they have a random set of pieces out in the middle somewhere they can share with the world :)
[13:04:54] <Switeck> ...
[13:06:41] <Switeck> At the very least, in a multi-torrent environment, is streaming going to be allowed on multiple torrents at once?
[13:07:07] <alus> I can't see why a user would attempt that
[13:07:16] <Switeck> then you are blind
[13:07:18] <Switeck> XD
[13:07:28] <Switeck> They'll do it because they *CAN*!
[13:07:29] <alus> but I'm not sure we specifically disallow it
[13:07:39] <alus> yes, how many people will do it because they can?
[13:07:59] <alus> if a few people do it, it really doesn't matter
[13:08:00] <Switeck> <- points at YouTube "uTorrent speedup" videos
[13:08:07] <The_8472> user thinking: let's stream the 2nd one too, so i have it in order after finishing the 1st one
[13:08:12] <Switeck> you can expect a roughly equal uptake
[13:08:32] <alus> no one will claim that streaming two videos at once speeds things up
[13:08:34] <alus> unless it does!
[13:08:38] <The_8472> or "stupid random order downloads, i don't want them" ... streaming all torrents
[13:08:40] <alus> in which case, awesome
[13:09:02] <Switeck> have you studied the BitTyrant model?
[13:09:17] <alus> their tit-for-tat improvements?
[13:09:22] <Switeck> yes
[13:09:25] <alus> yes, I have
[13:09:28] <alus> it's awesome
[13:09:36] <The_8472> i disagree
[13:09:41] <Switeck> Is BitTyrant detrimental to the swarm?
[13:09:45] <alus> actually, I'm rewriting the uTorrent choker to be much better, taking some of that idea in to account
[13:09:49] <The_8472> they basically exploit goodwill of the clients
[13:09:55] <alus> Switeck: it should not be
[13:10:02] <alus> The_8472: exploit?
[13:10:04] <The_8472> thus leading to a lower equilibrium
[13:10:08] <Switeck> It can be in "strained" torrent swarms.
[13:10:10] <The_8472> alus, yes.
[13:10:13] <alus> The_8472: how?
[13:11:01] <The_8472> they even admit it in their own paper that it leads to a less-efficient, lower equilibrium if everyone did it
[13:11:40] <The_8472> i have to find the relevant chapter first
[13:11:45] <Switeck> 8472, I read that they weren't "sure"
[13:11:57] <alus> well, they refuse to use excess capacity, which is just mean
[13:12:10] <alus> if you toss in the extra like you should, I believe it's better
[13:12:17] <The_8472> no, that's not it
[13:12:21] <Switeck> however given hit-and-running percentages, it can definitely reduce a torrent's stability if some are doing it and running.
[13:12:28] <alus> "However, our current BitTyrant implementation always contributes excess capacity, even when it might not improve performance. Our goal is to improve performance, not minimize upload contribution."
[13:12:52] <Switeck> alus, that's only referring to upload speed max
[13:13:03] <alus> Switeck: it should not have anything to do with hit-and-run
[13:13:14] <alus> and what is hit-and-run anyway?
[13:13:21] <alus> I mean, who does that, and why?
[13:13:22] <Switeck> BitTyrant won't reduce the upload speed max you set *IF* it determines it can't download faster than at a lower upload speed.
[13:13:38] <Switeck> hit-and-running is *EXTREMELY* prevalent.
[13:14:17] <alus> who does it, and why?
[13:14:26] <Switeck> Shouldn't you already know that? XD
[13:14:38] <alus> humor me
[13:14:57] <The_8472> found it
[13:15:00] <The_8472> To work around this last effect, BitTyrant advertises
[13:15:00] <The_8472> itself at connection time using the Peer ID hash. Without
[13:15:00] <The_8472> protocol modification, BitTyrant peers recognize one
[13:15:00] <The_8472> another and switch to a block-based TFT strategy that
[13:15:00] <The_8472> ramps up send rates until capacity is reached.
[13:15:13] <The_8472> ...
[13:15:23] <Switeck> Torrents have a "sweet spot" in size where they are easier to maintain the torrent swarm. Above or below that, hit-and-runners become prevalent.
[13:15:29] <The_8472> that means bittyrant does use block-based-tft among each other, because the behavior they show to other clients is deemed sub-optimal
[13:15:42] <The_8472> and block-based tft is WORSE than rate-based tft...
[13:15:47] <The_8472> so yeah...
[13:15:49] <alus> The_8472: can you link to or define "this last effect"?
[13:15:54] <The_8472> it's basically a leeching client
[13:16:09] <The_8472> http://www.cs.washington.edu/homes/piatek/papers/BitTyrant.pdf chapter 5.2
[13:16:30] <Switeck> A <50 MB torrent will see lots of downloaders leave within moments of finishing because they watch it finish
[13:16:36] <The_8472> they even admit that it's only designed to exploit altruism, not to improve efficiency
[13:16:58] <Switeck> A >2 GB torrent will see lots leave before reaching 1:1 because they don't want to seed for days.
[13:17:01] <kjetilho> Switeck: <50 MB torrents typically have so many seeders already it's useless to stay.
[13:17:10] <Switeck> not usually
[13:17:17] <The_8472> so a swarm of 100% bittyrant peers doesn't use what they would use on other peers, they use block based tit for tat. which is horrible
[13:17:19] <kjetilho> *shrug* that's my experience
[13:17:40] <Switeck> 1000+ tiny torrents on a tracker = lots unseeded
[13:17:45] <The_8472> <alus> it's awesome <- so, want to repeat that?
[13:17:50] <Switeck> for public trackers
[13:18:09] <The_8472> Switeck, depends on your seeding queue rules
[13:18:22] <Switeck> people *STOP* the torrents
[13:18:35] <Switeck> their queue rules hardly need to be considered
[13:19:02] <The_8472> you're just proving my point that people make bad decisions and that what people WANT isn't necessarily good. Which is the same with streaming
[13:19:20] <Switeck> It's a very big deal for a large segment of BitTorrent users to even leave their computers on at night or while they're at work/school.
[13:19:23] <The_8472> they want to stream, but don't understand the consequences. thus it should not be allowed or only allowed when the client makes sure that it has no impact
[13:20:13] <The_8472> streaming and then stopping the torrent when it's done is even worse than doing either of those behaviors alone
[13:21:11] <alus> The_8472: ah. that effect is: "BitTyrant tends to spread available capacity
[13:21:11] <alus> among many low capacity peers, potentially causing
[13:21:11] <alus> inefficiency due to TCP effects
[13:21:22] <alus> (man, pdfs suck at copy+paste)
[13:21:50] *** cyb2063 has joined #bittorrent
[13:22:06] <alus> The_8472: so detecting diminishing returns is awesome. they had a stupid property where it spread too thin. they should just fix that instead of switching it off
[13:22:17] <The_8472> you're missing the
[13:22:19] <The_8472> BitTyrant was designed
[13:22:19] <The_8472> to exploit the significant altruism that exists in
[13:22:22] <The_8472> BitTorrent swarms today.
[13:22:24] <The_8472> part
[13:22:31] <alus> well, that was obviously a bad goal
[13:22:41] <The_8472> once there is no altruism left to exploit bittyrant performs worse
[13:22:58] <kjetilho> The_8472: you don't believe in tit-for-tat all of a sudden?
[13:23:07] <The_8472> i believe in rate-based TFT
[13:23:13] <alus> right. but their method is actually useful for improving things generally -and- "exploiting" old clients
[13:23:13] <The_8472> not in block based TFT
[13:23:19] <alus> rate-based is hard
[13:23:31] <The_8472> huh? it's what we're doing right now
[13:23:38] <The_8472> fastest peer gets the unchokes
[13:23:44] <The_8472> it rewards faster uploading
[13:23:55] <alus> oh, but it's choke/unchoke not proportional
[13:23:59] <The_8472> instead of trying to sneak up to a peer and upload only as little as necessary
[13:24:03] <alus> sorry, two different rates at play here
[13:24:49] <The_8472> uploading as little as neccessary does not provide incentive to upload faster. it only provides incentive to spread upload to more peers and try to find the ones that are the easiest to exploit
[13:25:16] <The_8472> that's neither "playing nice" nor improving swarm performance
[13:25:19] <alus> no, it finds the ones who have bandwidth to give you.
[13:25:27] <The_8472> optimistics do that
[13:25:35] <alus> it's faster than optimistics
[13:25:49] <The_8472> because it lowers what it's uploading to others to have more slots...
[13:26:00] <alus> yes, without hurting what you get
[13:26:10] <The_8472> GLOBAL PERSPECTIVE
[13:26:11] <The_8472> ffs
[13:26:16] <The_8472> you're always thinking about yourself
[13:26:32] <alus> if everyone does this, the amount you need to give goes up
[13:26:52] <The_8472> or they'll just play each other down
[13:27:01] <alus> how?
[13:27:52] <The_8472> lowering what they upload to the other peer, trying to see if they can lower, meanwhile increasing their upload slots with the spare bandwidth and thus uploading slower per slot in general. thus making other peers lower their upload bandwidth too...
[13:28:52] *** Andrius has quit IRC
[13:29:18] <alus> yes, and I have a clever way of not spreading yourself too thin while trying that
[13:29:42] <The_8472> then publish it and have others review it before you try to exploit other clients
[13:30:06] <alus> my goal is not exploiting
[13:30:16] <The_8472> it still might have the effect of doing it
[13:30:22] <The_8472> regardless of intentions
[13:30:26] <alus> well, I'll test that.
[13:30:30] <The_8472> ...
[13:30:44] <The_8472> it doesn't affect you alone
[13:30:53] <Switeck> tragedy of the commons
[13:30:53] <The_8472> how about letting others who have a stake in this too review it?
[13:31:06] <The_8472> Switeck, excellent point
[13:31:07] <Switeck> it may be "very beneficial" for you, but not be for the swarm
[13:31:14] <alus> what?
[13:31:23] <alus> for me? I work on a client
[13:31:29] <The_8472> your users
[13:31:36] <alus> I am not one peer, I'm many millions
[13:31:36] <Switeck> I meant from a user perspective
[13:31:54] <Switeck> law of diminishing returns XD
[13:32:03] <Switeck> some things won't scale
[13:32:08] <The_8472> millions who still might see an improvement at the detriment of others
[13:32:11] <Switeck> I think 8472 and I agree this may not.
[13:32:23] <alus> The_8472: which others? other peers which are also uT?
[13:32:31] 
[13:32:48] <alus> The_8472: if I wanted to be hostile, I could just detect uT peers and treat them better.
[13:32:54] <alus> The_8472: obviously I have no interest in that
[13:33:05] <Switeck> no, sounds more like the reverse
[13:33:12] <Switeck> detect uT peers and treat them worse XD
[13:33:17] <alus> what?
[13:33:38] <Switeck> collusion to download less rare pieces amoung uT peers
[13:34:02] <Switeck> means that non-uT peers are slightly more likely to have the rare pieces you're missing
[13:34:21] <Switeck> even *IF* the swarm size is huge and availability is high
[13:35:09] <alus> ok somehow you jumped from talking about tit-for-tat to talking about streaming again
[13:35:29] <Switeck> yes
[13:35:38] <Switeck> because from what I understand, both are getting done
[13:35:44] <alus> that's true
[13:35:57] <alus> as are many other changes. all the time.
[13:35:59] <alus> hooray progress
[13:35:59] <Switeck> together they may be worse than separate
[13:36:09] <Switeck> ironic though it may seem...
[13:36:32] <alus> I don't see how one could make the other worse
[13:36:44] <Switeck> don't worry, 8472 does XD
[13:37:03] <alus> The_8472 doesn't know entirely how our streaming or the new tit-for-tat work
[13:37:13] <alus> so I don't know how he could know about an interaction between them
[13:38:15] <alus> anyway, clearly talking about improvements here is creating FUD, so I'm going to stop now.
[13:39:05] <Switeck> maximizing download as a goal is the likely strategy.
[13:39:14] <Switeck> individually, that can be great
[13:40:09] <Switeck> for the swarm, hit-and-runners + sequential downloaders + probably even mostly firewalled peers/seeds ...make this not so great.
[13:41:44] <Switeck> reducing any of those or the damage they cause is a worthwhile goal
[13:43:15] <Switeck> Streaming by my estimates increases all of those.
[13:45:03] <Switeck> If the torrent "finishes" when the playback is done, they're more likely to stop the torrent
[13:47:15] <Switeck> "Our hope is to transform getting media using uTorrent from a "load-wait-watch-tomorrow" to more of a "point-click-watch" experience." implies a watch now -- probably during prime/peak evening hours, when many ISPs are under heaviest load.
[13:49:42] <Switeck> While that would be nice, consumer ISPs aren't set up for millions to do that atm. This may change their policy from possibly throttling BitTorrent to blocking it during peak hours.
[13:51:44] <Switeck> Smart users are reactive to this, either moving their BitTorrent use to overnight/morning hours...and/or using marginal encryption tricks, proxies, VPNs, or seed boxes.
[13:52:30] <Switeck> But the average users have some pretty crazy expectations, going by YouTube videos XD
[13:55:27] <Switeck> So if they can stream everything, many will.
[13:56:20] <The_8472> <alus> The_8472 doesn't know entirely how our streaming or the new tit-for-tat work <- that's why i asked you to provide an explanation that can be reviewed
[13:57:43] <The_8472> in fact, things have gotten more worrisome now that you say that you want to change tft and streaming at once...
[13:59:19] 
[13:59:33] 
[14:02:08] <The_8472> on a different topic:
[14:03:23] 
[14:03:59] <The_8472> thus trying to maximize the one with the lowest RTT and highest bandwidth first... focusing on fewer connections until the delay goal is reached
[14:04:07] <Switeck> RTT?
[14:04:17] <The_8472> round trip time
[14:04:32] <Switeck> you mean pingtimes?
[14:04:36] <The_8472> yes
[14:04:47] <The_8472> but unidirectional delay would work too
[14:05:47] *** goussx has joined #bittorrent
[14:08:51] *** GTHK has joined #bittorrent
[14:21:55] <alus> The_8472: increasing the gain is dangerous
[14:22:06] <The_8472> not increasing it
[14:22:21] <The_8472> just give preference to which flow's gain to increase first
[14:22:33] <alus> The_8472: decreasing the gain is not helpful, since we react to latency and until we know the latency is affected we wouldn't know to not decrease it
[14:22:46] <The_8472> so you can max out your line (i.e. reach the delay goal) with fewer connections
[14:23:21] <alus> that's sort of a layer violation
[14:23:55] *** cyb2063 has quit IRC
[14:23:55] *** DreadWingKnight has quit IRC
[14:24:01] <The_8472> well, you could "group" connections and then prioritize within a "group"
[14:24:06] <The_8472> where a group happens to be an application
[14:24:23] 
[14:24:24] *** cyb2063 has joined #bittorrent
[14:24:24] *** DreadWingKnight has joined #bittorrent
[14:29:05] *** DreadWingKnight has quit IRC
[14:29:05] *** Guest73835 has joined #bittorrent
[14:29:12] *** Guest73835 has joined #bittorrent
[14:29:25] *** Guest73835 is now known as DWKnight
[14:35:19] *** cyb2063 has quit IRC
[14:36:49] *** cyb2063 has joined #bittorrent
[14:37:47] *** cyb2063 has quit IRC
[14:37:56] *** cyb2063 has joined #bittorrent
[14:42:04] *** Gottaname has quit IRC
[14:49:24] *** Andrius has joined #bittorrent
[15:34:20] *** Gottaname has joined #bittorrent
[15:46:37] *** Gottaname has quit IRC
[15:49:06] *** Gottaname has joined #bittorrent
[16:11:33] *** init0_ has joined #bittorrent
[16:21:39] *** init0 has quit IRC
[16:21:44] *** init0_ is now known as init0
[16:22:44] *** BitTorrentBot has quit IRC
[16:23:06] *** BitTorrentBot has joined #bittorrent
[16:30:09] *** ajaya has joined #bittorrent
[16:38:29] *** hlindhe has quit IRC
[16:38:30] *** hlindhe_ is now known as hlindhe
[16:40:24] *** CyrusYzGTt has joined #bittorrent
[16:42:04] *** kwinz2 has quit IRC
[16:43:23] *** CyrusYzGTt has left #bittorrent
[16:46:05] *** cyb2063 has quit IRC
[17:02:07] <TheSHAD0W> http://yro.slashdot.org/article.pl?sid=09/12/18/1531216
[17:04:43] <Switeck> bottom of that article has something about...  Farmers in the Iowa State survey rated machinery breakdowns more stressful than divorce. -- Wall Street Journal
[17:12:15] <burris> that's cuz divorce kills you very slowly, and when it's over you're nothing but a bitter, burned out husk
[17:14:07] *** Miller` has quit IRC
[17:14:52] *** KyleK_ has joined #bittorrent
[17:21:50] *** kwinz2 has joined #bittorrent
[17:23:37] *** lioux has joined #bittorrent
[17:30:39] *** liouxNOT has quit IRC
[17:36:00] *** ajaya has quit IRC
[17:40:54] *** KyleK_ has quit IRC
[17:49:06] *** ajaya has joined #bittorrent
[17:57:46] *** Res2216firestar has joined #bittorrent
[18:03:52] *** ajaya has quit IRC
[18:04:38] *** ajaya has joined #bittorrent
[18:25:17] *** Res2216firestar has quit IRC
[18:50:40] *** Waldorf has quit IRC
[20:47:18] *** hlindhe_ has joined #bittorrent
[21:07:26] *** Andrius has quit IRC
[21:20:30] *** Andrius has joined #bittorrent
[21:22:05] *** goussx has quit IRC
[21:22:24] *** goussx has joined #bittorrent
[21:29:15] *** kwinz2 has quit IRC
[21:32:05] *** kwinz2 has joined #bittorrent
[22:14:10] *** _rafi_ has joined #bittorrent
[22:26:20] *** goussx has quit IRC
[23:02:02] *** Andrius has quit IRC
[23:03:13] *** _rafi_ has quit IRC
[23:18:47] *** MassaRoddel has quit IRC
[23:24:18] *** charles_ has joined #bittorrent
[23:24:33] *** kjetilho has quit IRC
[23:24:33] *** TheSHAD0W has quit IRC
[23:24:34] *** cgreco has quit IRC
[23:24:34] *** charles has quit IRC
[23:24:34] *** void^_ has quit IRC
[23:24:34] *** void^ has joined #bittorrent
[23:25:17] *** kjetilho has joined #bittorrent
[23:27:23] *** cgreco has joined #bittorrent
[23:30:34] *** TheSHAD0W has joined #bittorrent
[23:46:00] *** Waldorf has joined #bittorrent





top