[00:10:44] *** Andrius has quit IRC
[00:22:51] *** senex has joined #bittorrent
[00:28:07] *** senex has quit IRC
[00:42:54] *** virus has joined #bittorrent
[00:43:08] *** virus is now known as virus__
[01:10:51] *** virus__ has quit IRC
[01:16:30] *** virus has joined #bittorrent
[01:21:32] *** burris has quit IRC
[01:47:32] *** virus__ has joined #bittorrent
[01:47:36] *** virus has quit IRC
[01:59:15] *** Waldorf has joined #bittorrent
[02:02:33] *** klapaucjusz has joined #bittorrent
[02:08:19] *** klapaucjusz is now known as klapaucjusz-san
[02:09:28] *** klapaucjusz-san is now known as pan-klapaucjusz
[02:09:28] *** pan-klapaucjusz is now known as pan_klapaucjusz
[02:18:33] <alus> IRConan: I'd prefer to call it Earth
[02:21:46] <alus> A9[idle]: why aren't there more people in the < 5GB range?
[02:22:06] *** pan_klapaucjusz is now known as klapaucjusz
[02:22:08] <alus> A9[idle]: are most of your downloads > 5GB?
[02:25:44] *** virus__ has quit IRC
[02:30:39] *** virus has joined #bittorrent
[02:31:22] *** GTHK has quit IRC
[02:43:52] <DeHackEd> I like the bit how the web sherrif is sheriff is clearly based out of the UK-area but goes around flaunting the DMCA
[02:51:30] *** klapaucjusz has quit IRC
[02:51:59] *** GTHK has joined #bittorrent
[02:53:21] <The_8472> it's a lot less funny if you consider that most sites outside the US get DMCA notices... and comply with them.
[03:10:08] *** kwinz2_ has joined #bittorrent
[03:12:39] <alus> some people are just nice
[03:12:51] <alus> you say "hey man, gimme $5", and then they do
[03:12:52] <alus> nice guys.
[03:13:24] *** kwinz2 has quit IRC
[03:23:32] *** KyleK_ has joined #bittorrent
[03:24:31] <K`Tetch_> DeHackEd - ah yeah, sherrif john, and his london ofice
[03:24:47] <Switeck> Where's Robin Hood when we really need him? XD
[03:25:14] <DeHackEd> Sir, I protest! I am not a merry man!
[03:25:49] <K`Tetch_> ok wort
[03:30:06] *** burris has joined #bittorrent
[03:31:00] *** KyleK_ has quit IRC
[03:39:42] *** c0mmunist has joined #bittorrent
[03:41:08] *** c0mmunist has quit IRC
[03:57:09] *** Waldorf has quit IRC
[03:57:15] *** Waldorf has joined #bittorrent
[04:00:22] *** The_8472 has quit IRC
[04:05:48] *** The_8472 has joined #bittorrent
[04:19:07] <TheSHAD0W> Um.
[04:19:11] <TheSHAD0W> "Worf"?
[05:07:08] *** edigaryev has joined #bittorrent
[05:17:46] <A9[idle]> alus: <5 are immune to any ratio requirements
[05:19:49] <Switeck> that's also because smaller torrents are impossible to seed reliably :P
[05:21:22] <alus> A9[idle]: oic
[05:21:42] <A9[idle]> It's a way of easing that starting period.
[05:46:35] *** init0 has quit IRC
[05:48:17] <K`Tetch_> TheSHAD0W - wort, and woof and so on, was lwaxannas name for him
[05:48:36] <TheSHAD0W> Ah.
[05:48:47] *** init0 has joined #bittorrent
[05:49:00] <K`Tetch_> and also, i'd certainnly go rescue a circa 1991 Jennifer Hetrick
[06:20:15] <TheSHAD0W> http://xkcd.com/705/
[06:25:37] <Switeck> Data centers are full of crazy people XD
[06:31:21] *** stalled has quit IRC
[06:33:50] *** stalled has joined #bittorrent
[06:41:29] *** MassaRoddel has quit IRC
[07:10:06] *** Balsaq has joined #bittorrent
[07:11:55] *** mxs has joined #bittorrent
[07:11:56] *** mxs has joined #bittorrent
[07:13:59] *** MassaRoddel has joined #bittorrent
[07:15:40] *** WhatMan has quit IRC
[07:21:11] *** btcod2 has joined #bittorrent
[07:21:17] <btcod2> dear all
[07:21:35] <Switeck> huh?
[07:21:43] <btcod2> please, where may i find a simple description of the queueing mechanism used by most clients when seeding?
[07:22:43] <Switeck> which queuing mechanism?
[07:22:47] <btcod2> http://www.bittorrent.com/btusers/guides/bittorrent-user-manual/appendix-bittorrent-mainline-interface/preferences/queueing
[07:24:04] <Switeck> there are also advanced settings in uTorrent/BitTorrent (same thing really) that tells it to start torrents with no/fewer seeds in preference over torrents with many seeds.
[07:24:33] <btcod2> right
[07:24:43] <btcod2> so, do you know where may i find documentation for these ?
[07:24:58] <Switeck> I don't believe there is a codified documentation for such.
[07:25:07] <Switeck> don't really know why you'd need one.
[07:27:05] <btcod2> well ... if someone is running a seed supporting many torrents and wants to know how set the # of active swarms, and wants to decide how to preempt / promote swarms in the queue ... it would be important to know what is currently used by different clietns
[07:27:50] <Switeck> such dynamic conditions are not really very good to try to keep intermittently active torrents going :(
[07:28:09] <btcod2> yeah
[07:28:14] <btcod2> that would be exactly the scenario of interest
[07:28:23] <btcod2> intermitently active torrents
[07:28:42] <Switeck> 10 very active torrents could tie up a disproportionate amount of the seeder's time-bandwidth
[07:29:18] <btcod2> based on the most popular heuristics in use nowadays ?
[07:29:37] <Switeck> heuristics! ha ha ha!
[07:29:40] <btcod2> :)
[07:29:43] <btcod2> nope ?
[07:29:47] <Switeck> in short, it's done badly
[07:29:51] <Switeck> if it's done at all
[07:30:01] <btcod2> i see
[07:30:29] <Switeck> the clients are also not given perfect data about the torrents
[07:30:45] <btcod2> right... they have only imperfect information
[07:30:52] <Switeck> so working with imperfect, out-of-date information makes it even worse
[07:30:59] <btcod2> based on some samples they get from the connected peers, right ?
[07:31:33] <btcod2> i see
[07:31:48] <Switeck> they won't get any samples UNLESS the torrents are already active and not queued.
[07:32:03] <btcod2> right
[07:32:37] <btcod2> it would be nice to let the torrents that are queued to join swarms only to collect control info
[07:32:44] <btcod2> i don't know how this is done now
[07:32:57] <Switeck> it's called...something...
[07:33:30] <Switeck> tracker scrapes
[07:33:50] <Switeck> in particular, multiscrapes
[07:34:23] <btcod2> i see ... so, for the torrents that are queued, the only info available comes from the multiscrapes
[07:34:39] <Switeck> correct
[07:34:48] <btcod2> ok
[07:35:24] <Switeck> except the tracker is often a liar.
[07:35:32] <btcod2> well, if u recall of any place where these queueing mechanisms are documented, it would be really helpful
[07:35:56] <Switeck> BitTornado XD
[07:36:03] <btcod2> oh! thanks
[07:36:50] <Switeck> no
[07:37:16] <Switeck> I meant that BitTornado doesn't have any queuing mechanisms, therefore what it has is fully documented.
[07:37:37] <btcod2> ah!
[07:38:26] <btcod2> http://btqueue.sourceforge.net/
[07:38:27] <Switeck> Transmission (and Vuze?) has at least semi-documented sourcecode
[07:38:41] <btcod2> if found this project but don't know if it is still in progress
[07:39:00] <Switeck> the problem is...BitTorrent is a horrid protocol for sharing lots of files at once, except as a single torrent.
[07:39:38] <btcod2> yeah! by single torrent you mean a bundle, right ?
[07:40:01] <Switeck> ONE multi-file torrent
[07:40:06] <btcod2> yep
[07:40:12] <btcod2> bundling
[07:40:44] <Switeck> take for instance a collection of 1000 pictures that are ~100 KB each in size. It would be "pointless" to have 1000 torrents.
[07:40:54] <btcod2> right ;)
[07:41:29] <btcod2> http://en.wikipedia.org/wiki/Product_bundling
[07:41:48] <btcod2> "In peer-to-peer swarming systems for content dissemination, such as BitTorrent, bundling consists of disseminating multiple files together in a single swarm. Empirical evidence and analytical models indicate that bundling improves content availability in those systems. Both pure and mixed bundling are supported by BitTorrent."
[07:44:54] <btcod2> so, what would be important measures to alliviate this problem of sharing lots of files at once?
[07:44:57] <Switeck> The bandwidth to track everything quickly swamps the ability to transfer once number of torrents grows.
[07:45:25] <Switeck> There simply is no useful manner to share lots and lots of large files on a slow line.
[07:45:46] <btcod2> right
[07:46:31] <btcod2> do you think the bandwidth to track in a bundle and in isolated swarms would be similar?
[07:46:50] <Switeck> no
[07:47:31] <btcod2> i suspect the bandwidth to track  a bundle would be smaller
[07:47:36] <Switeck> not under the bittorrent protcol anyway
[07:47:46] <btcod2> is that obvious ?
[07:47:51] <btcod2> why ?
[07:47:51] <Switeck> connect to a tracker for 1000 torrents is slightly more than just 1 torrent
[07:48:42] <btcod2> is this obvious ?
[07:48:50] <Switeck> I just said so
[07:49:06] <btcod2> yep, but why is that so ?
[07:49:50] <Switeck> tracker updates
[07:49:53] <Switeck> fewer of them
[07:51:10] <btcod2> well ...
[07:51:16] <btcod2> it depends on the workload we consider
[07:51:23] <btcod2> but yeah, i understand your point
[07:51:50] <btcod2> if all clients join all the 1000 torrents, this would lead to more track info than 1 single torrent
[07:52:00] <Switeck> you'll lower your demand forcing people to download and run 1000 torrents, because most people simply WON'T.
[07:52:16] <btcod2> interesting point
[07:52:21] <Switeck> but what demand is left will still force the tracker to answer for a lot of torrents
[07:52:45] <btcod2> i see
[07:52:49] <Switeck> Each torrent is its own isolated network
[07:52:57] <Switeck> DHT notwithstanding XD
[07:53:50] <Switeck> and each has some minimal connectivity costs that cannot be avoided to keep things running. So more torrents means overheads just to keep things going skyrockets.
[07:54:21] <Switeck> But likewise, more seed/peer connections at once does the same. So a super-busy torrent can be slightly bad as well.
[07:55:06] <btcod2> right ... i can see that pushing this idea of "bundling" to its limits would bring many problems
[07:55:53] <btcod2> (the bitmaps for instance would become really big)
[07:55:57] <Switeck> I know of torrents with 30,000+ peers/seeds
[07:56:05] <btcod2> !
[07:56:15] <Switeck> it is impossible to connect to all of them
[07:56:34] <Switeck> so for all practicality, most can be considered to not really exist. :P
[07:56:48] <btcod2> :D
[07:57:01] <btcod2> so, how is the dynamics of such torrent ?
[07:57:03] <Switeck> peers that are now seeds, but still misreported as peers
[07:57:07] <btcod2> how did the 30,000 join ?
[07:57:13] <Switeck> hopelessly firewalled peers/seeds
[07:57:20] <Switeck> or on hostile ISPs
[07:57:34] <Switeck> the tracker of course! for even more fun, these are private torrents!
[07:57:58] <btcod2> i see
[07:58:12] <Switeck> on such a torrent, the tracker can expect to see probably 1000-10000 tracker updates per minute.
[07:58:27] <btcod2> so, it's impossible to connect because it's a private swarm ... not because of technical limitations,  right ?
[07:58:44] <Switeck> no, being a private torrent makes it WORSE
[07:59:01] <btcod2> why ?
[07:59:06] <Switeck> if you consider laws of reality/physics, etc...technical limitations
[07:59:56] <Switeck> private tracker = no DHT, no PEX, no Local peer discovery...
[08:00:02] <btcod2> oh !
[08:00:18] <Switeck> the ONLY place to get a list of additonal peers/seeds is the once-every-30mins tracker update
[08:00:23] <btcod2> i see !  that's the only way they can remain private !
[08:00:49] *** burris has quit IRC
[08:00:55] <Switeck> and that typically only gives 50-200 ips, many of which may be dead, firewalled, or already a seed.
[08:01:21] <btcod2> i see that there are  clear scalability problems there
[08:01:27] *** burris has joined #bittorrent
[08:01:41] <Switeck> or even more fun, the tracker even gives you your own ip in the list :P
[08:01:48] <btcod2> :D
[08:02:08] <btcod2> so, it would be important to have a private-tracker-compatible PEX
[08:02:35] <btcod2> probably involving cryptographic mechanisms
[08:02:46] <Switeck> but if it were a public torrent, same things still happen
[08:02:58] <Switeck> tracker can still give you bad ips...even more likely to!
[08:03:06] <btcod2> right
[08:03:30] <Switeck> people are more likely to hit-and-run...yet tracker still gives out their ip an hour later. :P
[08:03:47] <btcod2> viz http://www.sagecertification.org/events/hotsec08/tech/full_papers/piatek/piatek.pdf
[08:03:52] <Switeck> they're more likely to be firewalled (practically a bannable offense on a private tracker!)
[08:04:11] <Switeck> I can't read that
[08:04:34] <Switeck> adobe reader (and foxit reader) crashes this box, so I removed it.
[08:04:48] *** senex has joined #bittorrent
[08:04:49] <btcod2> the authors were able to make a printer receive many DMCA take down notices
[08:05:01] <btcod2> by making the printer join bittorrent swarms
[08:05:07] <Switeck> tracker handed out "fake" ips
[08:05:14] <btcod2> https://www.usenix.org/events/hotsec08/tech/full_papers/piatek/piatek_html/
[08:05:17] <Switeck> not news, I've known about that for a couple years
[08:05:36] <btcod2> yes
[08:06:08] <btcod2> so, we touched two important problems
[08:06:26] <btcod2> 1 )  how to make bundles scalable ?
[08:06:33] <Switeck> back to your initial point, most ADSL and cable connections have <1 mbit/sec upload bandwidth, not all of which is usable for Bittorrent.
[08:06:48] <Switeck> You can't squeeze blood from a stone
[08:07:02] <btcod2> 2 ) how to deal with  resource sharing between multiple swarms if they are preferred in place of bundles ?
[08:07:09] <Switeck> if the uploaders have tiny amounts of upload, it's hard enough for them to keep 1 busy torrent seeded.
[08:07:39] <Switeck> having them queue 10+ torrents effectively reduces "availability" of those torrents to the point of uselessness.
[08:07:49] <btcod2> i see
[08:08:11] <btcod2> but this really depends on the cooperation received by other peers
[08:08:32] <Switeck> no, it does not
[08:08:48] <btcod2> well .. and on other factors such as the popularity of the swarm
[08:08:57] <Switeck> it's barely useful under the BEST of conditions
[08:09:34] <Switeck> you familiar with torrent piece sizes?
[08:09:40] <btcod2> well
[08:09:42] <btcod2> 256 Kb ?
[08:09:49] <Switeck> maybe for the little ones
[08:09:55] <btcod2> oh !
[08:10:00] <btcod2> do people use larger values ?
[08:10:12] <Switeck> I see many with 4 MB piece size.
[08:10:17] <btcod2> olala!
[08:10:38] <btcod2> piece is also referred to as chunk, right ?
[08:10:45] <Switeck> some places maybe
[08:10:52] <Switeck> It's a seriously non-trivial delay to get even a single completed piece from a slow peer/seed.
[08:10:59] <btcod2> it's the minimum amount of data that is check-summed
[08:11:08] <Switeck> especially if that same peer/seed is connected to 100+ other peers.
[08:11:15] <btcod2> right
[08:11:23] <btcod2> i observed that this is a big deal
[08:11:33] <btcod2> and that's why the seed cannot open multiple connections at the same time
[08:11:50] <Switeck> A seed should have multiple connetions
[08:11:57] <btcod2> sorry
[08:12:02] <btcod2> i mean, too many connections
[08:12:06] <Switeck> a seed should be able to upload to multiple people at once.
[08:12:15] <Switeck> And at a "reasonable" rate!
[08:12:50] <btcod2> yep, otherwise, peers will not have content to exchange with each other ... they would spend most of their time "idle waiting"
[08:12:50] <Switeck> 3-10 KB/sec per upload slot while downloading, higher if possible while seeding.
[08:13:15] <Switeck> do note: not per torrent, per UPLOAD slot :p
[08:13:28] <btcod2> !
[08:13:51] <btcod2> is it reasonalbe to have around 7 upload slots per torrent ?
[08:14:21] <Switeck> sure, if you have >1 mbit/sec upload OR only 1 torrent with maybe 512 kbit/sec upload.
[08:14:41] <btcod2> right
[08:15:18] <Switeck> If you had 70 KB/sec upload speed max then 1 torrent with 7 upload slots means 10 KB/sec each.
[08:15:47] <btcod2> ok, so this indicates that if a peer has 70 KB/s bandwidth, it might be able to serve only  1 ~ 3 swarms at a time
[08:16:02] <Switeck> it could reduce upload slots to only 3 per torrent.
[08:16:20] <btcod2> in which case it could serve ~ 3 swarms
[08:16:21] <Switeck> Then do slightly more torrents
[08:16:41] <btcod2> now, going back to the original point ...
[08:16:48] <Switeck> 4-5 torrents
[08:17:11] <btcod2> that doesn't make it even more important to have good scheduling policies for the active queue ?
[08:17:23] <Switeck> ...
[08:17:42] <Switeck> not really
[08:18:05] <Switeck> because you're already failing against overwhelming demand based on the premises.
[08:18:27] <Switeck> 10 KB/sec takes how long to upload a single 4 MB piece?
[08:18:45] <btcod2> 40 s
[08:18:52] <btcod2> 400 s
[08:18:55] <Switeck> more
[08:19:02] <btcod2> 4000 s ?!
[08:19:12] <Switeck> 3600 seconds is 1 hour
[08:19:32] <btcod2> yeah, it' s a lot !
[08:19:35] <Switeck> even if the 10 KB/sec were dedicated to a single peer, it'd take ~410 seconds
[08:19:53] <Switeck> except...upload slots "skip around" to try to reach more peers.
[08:20:14] <Switeck> so it may be some time before the 1st peer is downloading again to complete a piece.
[08:20:38] <btcod2> i see
[08:20:47] <Switeck> how many peers would a seed be connected to?
[08:20:59] <btcod2> i assume between 4 - 10
[08:21:18] <btcod2> (this is related to the number of upload slots u were referring to before, right ? )
[08:21:36] <Switeck> If they did that, you'd likely never connect to a seed on busy public torrents.
[08:21:49] <Switeck> no, this is something completely arbitrary
[08:22:03] <btcod2> i see
[08:22:16] <btcod2> so, much more than 10 ?
[08:22:32] <Switeck> uTorrent/bittorrent defaults to 50 connections per torrent
[08:22:57] <Switeck> other clients default to 100 or more...
[08:23:02] <btcod2> i see... connected but not actively transmitting right ? the # of active transmissions is the number of upload slots, no?
[08:23:12] <Switeck> connected but not uploading to all of them
[08:23:33] <Switeck> yes, those that are upload slots are presumably actively uploading.
[08:23:50] <btcod2> i see
[08:23:50] <Switeck> for a brief while once the upload slot becomes first active it's not yet uploading.
[08:24:07] <btcod2> right
[08:24:14] <Switeck> jumping around often means upload slots are less useful because of the initial ramp-up time among other things.
[08:24:27] <btcod2> (tcp ramp-up?)
[08:24:33] <Switeck> that also :P
[08:24:38] <btcod2> i see
[08:24:57] <Switeck> peer and seed also has to negotiate what to transfer and how much
[08:25:00] <btcod2> well... so, u r making the point that supporting multiple swarms is really tough
[08:25:32] <btcod2> at least --- supporting multiple swarms with small bandwidth
[08:25:57] <Switeck> extremely so, but a queued state is effectively not running at all -- others wouldn't see you as a seed according to the tracker and could expect probably a 30+ min delay before a perfect queuing system could even get to them.
[08:26:38] <btcod2> i see
[08:26:48] <btcod2> it would be interesting to have at least that signalized
[08:26:58] <btcod2> so that peers know what is going on
[08:26:59] <Switeck> signaled how?
[08:27:22] <Switeck> it takes an infinite amount of bandwidth to be instantly aware of everything. :P
[08:28:07] <btcod2> right :D but it would be nice to receive a signal saying "your order will come if you wait long enough" (30~40 mins)
[08:28:09] <Switeck> trackers are often already under a horrific bandwidth AND connection load, so they cannot be expected to contact potential seeds
[08:28:34] <btcod2> i see
[08:28:45] <Switeck> potential seeds constantly poling the tracker for changes only increase the tracker's load
[08:29:13] <btcod2> wow! so many problems under this heavy load regime!
[08:29:47] <Switeck> E-mule -- you have been queued as position 32,000 ...you can expect your download to start roughly some time 2 weeks from now.
[08:29:52] <btcod2> interesting to see that even though bittorrent scales so well still faces heavy load
[08:30:28] <Switeck> (I do not like long queues.)
[08:30:47] <btcod2> :) me neither!  i didn't know that in E-mule queues reached size 32,000 !
[08:30:54] <Switeck> The miracle of BitTorrent is not that it often/usually works well...it's that it works at all!
[08:31:02] <btcod2> :) :)
[08:31:55] <btcod2> well ... i still think that if there is space to improve the queueing mechanism it would be worth investigating it
[08:32:52] <btcod2> regarding the 4Mb blocks
[08:33:13] <btcod2> can u point me to a swarm that has such big blocks (pieces) ?
[08:33:30] <Switeck> anything over ~4 GB in size
[08:33:37] <Switeck> take your pick
[08:34:00] <btcod2> thanks! and this is yet another question: how do people pick the block sizes ?
[08:34:12] <Switeck> most don't
[08:34:19] <Switeck> torrent making program does that for them
[08:34:46] <btcod2> the tradeoff i guess is between the efficiency of the system in terms of cooperation (smaller blocks lead to more cooperation) versus overhead (larger blocks have less overhead)
[08:34:55] <Switeck> but the more pieces a torrent has, the larger the resulting .torrent file ends up...the more peers/seeds have to communicate (yes, I have piece #68,071!)...etc
[08:35:23] <btcod2> yeah, the more pieces, the higher the overhead
[08:35:46] <Switeck> then of course the issue of piece overlaps for multiple files...
[08:36:02] <btcod2> how so ?
[08:36:14] <btcod2> you mean, in a bundle ?
[08:36:30] <Switeck> a 4 MB piece might be the end of 1 file and the beginning of the next. or it may even be many little files!
[08:36:32] <Switeck> and if a lot of people are doing sequential downloading or only downloading parts of the whole torrent.
[08:36:37] <btcod2> and when you say "torrent making program" you mean that the torrent making program automatically decides the size of the piece?
[08:36:43] <Switeck> yes
[08:37:17] <btcod2> i see ... so, this is another ingredient to add to the tradeoff
[08:37:31] <Switeck> Seq. DLers will make heavy demands on seeds...as each wants the 1st piece (however common it already is)
[08:37:53] <btcod2> i see
[08:38:13] <btcod2> and in bundles where we have movie + sample , the sample will probably be downloaded first too
[08:38:28] <Switeck> yes
[08:38:29] <btcod2> which also brings heavy demand on seed
[08:39:02] <Switeck> seeds can't effectively tell peers what pieces to download, peers instead demand pieces from the seed.
[08:39:56] <btcod2> right .   so, going back to the piece size selection,  do the programs decide the piece size based on properties of the torrent (bundle / non bundle ;  size of files ; desired overhead ) ?
[08:40:25] <Switeck> size of total torrent is basically the ONLY criteria for automatic settings
[08:40:46] <btcod2> i see
[08:40:47] <Switeck> with the resulting .torrent file having maybe 1000-10000 pieces
[08:41:07] <Switeck> But there are now torrents over 100 GB in size!
[08:41:20] <btcod2> !
[08:41:25] <btcod2> that's really extreme!
[08:41:45] <Switeck> I'm sure there's a torrent somewhere that won't fit on a single hard drive.
[08:42:05] <btcod2> yeah, quite impressive
[08:42:23] <btcod2> i wonder if these torrents are being collectively supported by a large # of peers
[08:42:34] <Switeck> best guess says "no!"
[08:42:35] <btcod2> that together keep all chunks available
[08:43:03] <Switeck> giant torrents like that are probably shared by semi-small numbers of very fast lines
[08:43:31] <btcod2> impressive
[08:43:56] <btcod2> if they are collections of files (huge bundles) they could be of interest to slow clients too
[08:46:53] *** WhatMan has joined #bittorrent
[08:49:26] *** Andrius has joined #bittorrent
[09:39:29] *** Waldorf has quit IRC
[09:47:12] *** kwinz2_ has quit IRC
[10:26:01] *** mxs has quit IRC
[10:26:04] *** mxs has joined #bittorrent
[10:26:05] *** mxs has quit IRC
[10:26:05] *** mxs has joined #bittorrent
[10:55:39] *** Waldorf has joined #bittorrent
[11:31:43] *** GTHK has quit IRC
[11:42:43] *** senex has quit IRC
[12:36:26] *** KyleK_ has joined #bittorrent
[12:40:52] *** KyleK_ has quit IRC
[13:20:33] *** Balsaq has quit IRC
[13:32:26] *** mxs has quit IRC
[13:36:56] *** mxs has joined #bittorrent
[13:36:56] *** mxs has joined #bittorrent
[14:00:33] *** punto has quit IRC
[14:41:38] <TheSHAD0W> http://attackcartoons.com/article.php?story=20100222030919623
[14:45:44] *** kwinz2 has joined #bittorrent
[14:48:39] <mpl> Switeck: do you have an example of such a huge .torrent ?
[14:48:44] <mpl> well, not .torrent
[14:49:03] <Switeck> I do not have one onhand
[14:56:56] <hlindhe> perhaps http://earthobservatory.nasa.gov/Features/BlueMarble/BlueMarble_monthlies.php ?
[15:00:59] <Switeck> I don't know :P
[15:11:24] <Switeck> those only seem to have about 5500 pieces each.
[15:11:54] <Switeck> They'd need over 10 times as many pieces before problems likely would occur
[15:39:31] *** kwinz2 has quit IRC
[15:53:36] *** kwinz2 has joined #bittorrent
[16:02:33] <TheSHAD0W> http://www.macworld.com/article/146552/bandwidth_caps.html
[16:17:42] <Switeck> bandwidth caps are mostly bullshit and mirrors
[16:18:18] <Switeck> ISP doesn't upgrade...saves money. charges extra for going over caps, since its network cannot handle the strain...more profit
[16:18:30] <Switeck> shareholders demand increased profits
[16:18:41] <Switeck> even if it means squeezing the customers sideways
[16:19:11] <kjetilho> I don't know, I think it makes sense.  I'm paying for speed, not bulk capacity
[16:19:13] <Switeck> So ISPs have little incentive to upgrade.
[16:19:42] <Switeck> I'm paying for availability as well as speed
[16:19:46] <kjetilho> I'd rather have 100/100 with caps than 10/10 without
[16:19:57] <Switeck> Depends on what the caps are
[16:20:04] <kjetilho> of course
[16:20:21] <Switeck> ComCast's cap of 250 GB, while seeming generous, would not be very useful for 100/100
[16:21:03] <kjetilho> would be for me
[16:21:25] <Switeck> If ISPs start telling customers what they're selling, maybe the market could compete properly
[16:21:35] <kjetilho> agreed
[16:21:40] <Switeck> except most areas are a virtual monopoly for some broadband ISPs.
[16:22:05] <Switeck> Would you consider overselling the service 50+ times over to be fair?
[16:22:24] <kjetilho> of course
[16:23:12] <Switeck> so offer 100/100 but only be able to deliver maybe 1-2 mbit/sec constantly?
[16:23:27] <Switeck> (assuming a flash crowd of course)
[16:23:38] <kjetilho> the fact of the matter is that most people don't use 1-2 Mbps constantly
[16:23:48] <Switeck> but currently we're not being told this info
[16:24:08] <kjetilho> since it doesn't matter, as long as they upgrade the capacity to handle peaks sensibly
[16:24:14] <Switeck> we don't know what the overselling amount is.
[16:24:16] *** _rafi_ has joined #bittorrent
[16:24:22] <Switeck> except that it's often "bad" in many areas.
[16:24:50] <kjetilho> ask for pingdom graphs or something instead.  overselling ratio is useless
[16:24:55] <Switeck> In short, all many consumers can tell is the ISP apparently hasn't upgraded to handle peaks sensibly.
[16:25:01] <kjetilho> graphs of latency and packet loss, that is
[16:25:15] <Switeck> you have to get a court order to get that
[16:25:18] <kjetilho> I've never had a problem with my ISP not handling peaks *shrug*
[16:25:37] <Switeck> and even then the ISP would probably appeal first!
[16:25:40] <kjetilho> anyone can set up smokeping and show the world what the service is like
[16:26:06] <kjetilho> or use it to document to the ISP that service is unsatisfactory
[16:26:09] <Switeck> Sure, how quick do you want to get character assassinated?
[16:26:18] <kjetilho> what on earth are you on about?
[16:27:06] <Switeck> the ISPs will say unfounded and bad things about you to make you look bad
[16:27:52] <kjetilho> hehe, that would never happen here, anyway
[16:28:04] <Switeck> It's happened in the USA and Canada.
[16:28:15] <kjetilho> they'd fall over themselves explaining why the upgrade has been delayed due to frost or whatever
[16:28:45] <Switeck> hard to prove them totally wrong without a LOT more oversight.
[16:28:57] <kjetilho> smokeping is all you need, really
[16:29:31] <kjetilho> but you have to accept that service is degraded for some small fraction of the time.  otherwise service will get *very* expensive
[16:29:43] <kjetilho> try paying business prices sometime
[16:29:51] <kjetilho> with guaranteed bandwidth
[16:29:53] <Switeck> well, that's a racket XD
[16:29:59] <kjetilho> no, it's not
[16:30:04] <Switeck> yes it is
[16:30:19] <Switeck> not necessarily done by the company you're paying tho!
[16:30:40] <Switeck> thank the regional telephone companies for the high prices
[16:30:40] <kjetilho> it's not free to operate trans-atlantic cabling, you know
[16:30:55] <Switeck> Oh, I know it's not
[16:31:03] <Switeck> I'm talking more about the T-1 prices
[16:31:47] <kjetilho> T-1, how quaint :)
[16:33:26] <kjetilho> well, in cities you buy black fiber and run whatever you like on top of it, then usually pay for 95th percentile of actual usage
[16:33:30] <Switeck> or premise to premise dedicated "dry" DSL lines
[16:33:47] <kjetilho> s/buy/rent/
[16:36:33] <Switeck> Apparently you mean rent.
[16:38:52] <Switeck> While the average computer user would barely know what to do with a 10/10 line, 1 TB/month traffic would prove "trivial" once they figure it out :P
[16:40:44] <kjetilho> 256 GB month is 771 kbps 24/7 btw.
[16:40:59] <kjetilho> which means you can stream Youtube HD all day long :-)
[16:41:17] <Switeck> what's YouTube's supposed HD weigh in at?
[16:41:30] <kjetilho> I don't know, actually.  just guessing there
[16:41:43] <Switeck> from what I've seen, it's still pretty shitty
[16:43:50] <kjetilho> HQ is 750 kbps, but HD is more I guess
[16:44:01] <Switeck> 1 mbit/sec video is actually pretty low
[16:44:16] <kjetilho> yeah.
[16:45:00] <kjetilho> still, with 2.5 Mbps, you can watch it 8 hours out of every day.  that's more than most people do
[16:45:16] <Switeck> from what I've heard about cable cos, they're only getting about 2 HQ digital tv channels in 1 old analog tv channel space.
[16:45:33] <Switeck> That puts them closer to 10-18 mbit/sec
[16:47:12] <kjetilho> DVD is 10 Mbps, Bluray peaks at 40 Mbps (but averages at about 20)
[16:47:46] <Switeck> DVD's 10 mbit/sec probably assumes no TCP/IP overheads
[16:48:08] <kjetilho> that's straight off the disc
[16:48:43] <Switeck> so HD tv is probably very close to DVD quality
[16:48:46] <Andrius> streaming uncompressed DVD data isn't really a good idea
[16:49:02] <kjetilho> DVD data isn't uncompressed :)
[16:49:16] <kjetilho> well, audio can be, but it's quite unusual
[16:49:16] <Andrius> kjetilho, well yes, it's compressed...
[16:49:32] <Andrius> but with real world compression, you can get much higher quality with same bitrate
[16:49:44] <kjetilho> MPEG2 is no match for AVC, so it's wasteful, yes
[16:51:06] <Switeck> so the 10 mbit/sec in Mpeg2 gets converted to about 2.5-5 mbit/sec in AVC
[16:52:41] <Switeck> except about the only "place" online you're likely to see that quality is from BitTorrent
[16:53:36] <Switeck> Maybe iTunes carries HD movies and tv shows, but I doubt they use a friendly video codec.
[16:55:39] <kjetilho> there aren't really many alternatives
[16:55:53] <Switeck> one big problem I have with ISPs and bandwidth caps is the main network limitations reason for an ISP having them is due to peak evening hours being congested.
[16:57:33] <Switeck> a blanket cap, as opposed to a peak/offpeak dual cap, does not deal with the issue properly.
[16:58:46] <Andrius> <Switeck> except about the only "place" online you're likely to see that quality is from BitTorrent < what about digital tv that uses H264? (not that I have a clue about its quality)
[16:59:15] <Switeck> H264 is pretty good actually, roughly 4-10 times better than Mpg2
[16:59:36] <Switeck> Maybe someone is only on during 5-10 PM due to the hours they work, but while on they "download everything". They may not reach a simple overall monthly bandwidth limit, but they're going to be stomping all over congestion issues.
[17:02:10] <Switeck> Since simple bandwidth caps don't deal with that special case, where it really hurts the most, those caps + overage fees are obviously just a moneygrab scheme.
[17:03:11] *** edigaryev has quit IRC
[17:03:39] *** edigaryev has joined #bittorrent
[17:06:21] <kjetilho> it sure would be nice if it was possible to flag traffic as bulk traffic so that ISPs could throw it away during congestion, combined with different caps for bulk and non-bulk traffic
[17:06:44] <kjetilho> problem is that most HTTP is flagged as bulk today
[17:07:10] <Switeck> And since most of BitTorrent isn't HTTP, it isn't...
[17:09:02] <Switeck> I've heard that even if you did flag it as bulk, your router or modem would likely "fix" that. :P
[17:11:00] <Switeck> Most ISPs have very bad network topologies as well. Cable is especially bad due to legacy channel sizes and high customer density per channel.
[17:14:11] <Switeck> As they competed with others, they raised max speeds beyond credibility.
[17:34:14] <TheSHAD0W> One version of BitTornado had the low priority flags set for TCP traffic.
[17:34:56] <TheSHAD0W> Then I started getting some complaints about weird behavior from some routers mishandling the resulting packets very badly, fragmenting them to hell...
[17:35:00] <TheSHAD0W> And I had to undo it.
[17:35:04] *** ajaya has joined #bittorrent
[17:43:57] <Switeck> wonderful!
[17:52:41] *** KyleK_ has joined #bittorrent
[17:59:53] *** MassaRoddel has quit IRC
[18:01:24] *** MassaRoddel has joined #bittorrent
[18:02:40] *** dubious has joined #bittorrent
[18:07:35] *** andar2 has joined #bittorrent
[18:22:14] *** goussx has quit IRC
[18:46:11] *** KyleK_ has quit IRC
[19:00:49] *** goussx has joined #bittorrent
[19:19:57] *** Switeck has quit IRC
[19:20:50] *** GTHK has joined #bittorrent
[19:36:03] *** Switeck has joined #bittorrent
[19:42:59] *** btcod2 has quit IRC
[19:46:02] *** GabydeWilde_ has quit IRC
[19:55:29] *** Miller` has quit IRC
[20:10:43] *** Miller` has joined #bittorrent
[20:15:45] *** Miller` has quit IRC
[20:16:17] *** Miller` has joined #bittorrent
[20:17:04] *** Miller` has quit IRC
[20:21:27] *** btcod2 has joined #bittorrent
[20:24:28] <The_8472>  <Switeck> except most areas are a virtual monopoly for some broadband ISPs. <- if you live in the US ;)
[20:24:54] <The_8472> we have lots of relatively good regulation wrt to loop unbundling and fixed wholesale rates here
[20:24:57] <Switeck> don't think there aren't other places in the world that are the same
[20:25:15] <The_8472> and companies still make a profit
[20:25:57] <Switeck> UK -- home of inexplicably bad ADSL
[20:26:23] <The_8472> i think the UK had some shoddy copper infrastructure. but that's a thing of the past
[20:26:42] <Switeck> that doesn't just "go away"
[20:27:10] <Switeck> an absolute staggering number of people are getting less than 384 kbit/sec upload on ADSL there
[20:34:36] <Firon> uk adsl is better than US ADSL for the most part :P
[20:34:50] <Firon> they at least have ADSL2+ in most places and real competition thanks to LLU
[20:36:38] <Switeck> there is a major campaign to throttle to heck BT traffic
[20:37:04] <Switeck> Anything by Carphone warehouse...is horrendously bad
[20:37:23] <Switeck> and BT Central is also a MAJOR disrupter of BT traffic
[20:38:29] <Switeck> I'm talking a level of *FUCKED* worse than Rogers Cable!
[20:52:27] *** KyleK_ has joined #bittorrent
[21:01:07] *** KyleK_ has quit IRC
[21:10:04] <Firon> didn't see that the last time I went to the uk
[21:11:17] <Switeck> what ISP did you use?
[21:11:27] <Switeck> and who was it through?
[21:11:57] <Switeck> Because I'd like to be able to tell posters a better choice
[21:15:29] *** edigaryev has quit IRC
[21:17:27] *** KyleK_ has joined #bittorrent
[21:26:11] *** KyleK_ has quit IRC
[21:38:46] *** A9[idle] is now known as A9
[21:42:56] <btcod2> hi, please, do you know if i can find somewhere statistics about the number of pieces across bittorrent swarms?
[21:47:59] *** burris has quit IRC
[21:48:59] *** burris has joined #bittorrent
[22:09:27] <The_8472> just randomly sample a few swarms, get the .torrents and count the pieces
[22:10:37] <The_8472> they generally range between a few hundreds (~500MB torrents) and a few ten thousands (dozens of GB torrents)
[22:18:43] *** Miller` has joined #bittorrent
[22:34:58] *** Switeck has quit IRC
[22:47:47] *** BeZerk has quit IRC
[22:50:48] *** BeZerk has joined #bittorrent
[22:51:20] *** KyleK_ has joined #bittorrent
[23:12:35] *** Miller` has quit IRC
[23:13:47] *** m77771111 has joined #bittorrent
[23:13:48] <m77771111> Hi. Can i move all downloading/seeding things from ktorrent to some other software? :) How to export all current deeds of it to other torrent client? :)
[23:24:23] <DeHackEd> just start your new client with the same .torrent files and set to "overwrite" your current downloads
[23:24:39] <DeHackEd> seeding should work just fine. downloads in progress might roll back a percentage or two
[23:34:43] *** KyleK_ has quit IRC





top