Initial Seeding

[BlueDragon]

Before I start to ask my questions I would like to make clear that I do have spent a couple of hours reading (almost) all the threads here about the initial seeding topic so please don't just reply by telling me to read this or that in the help, manuals etc... 8)

I have been using the initial seeding option for 2 uploads until now. The first one about 420MB and the 2nd one (still actively uploading) for 7.5GB.

I have been fidelling around with trial and error for many hours to try to tweak and optimise as best as possible my uT 1.8.2. settings...

My present connection settings are:

(Bandwith)

Global max # connections: 130

Max # connected peers / torrent: 70

# uploads slots / torrent: 4

(Queueing)

Max # active torrents: 4

Max # active dl: 3

Ratio 150%

My ADSL has a max. capacity of 2400/230 KBits/s (no ISP throttling). In average this means around 25 KBytes/s ul and 270 KBytes/s dl.

I have been uploading for about 5 days non stop with a few little interruptions and reductions of the max ul bandwith for other purposes. (Ul avg. 21 KB/s) Some hours ago I reached a ratio of 1.0 e.g. I uploaded 7.5GB in initial seeding mode so far.

Trackers Information are as follow (S/P/D):

[DHT] 1/73/0

[PEX] 1/119/0

Tracker A 1/80/0

Tracker B 1/81/0

Tracker C 1/85/1

General Panel Information:

S 0(1) (1 in swarm)

P 47(123) (85 in swarm) {sometimes up to 55 (150)}

Availibility: about 1.54 {now (later in time) the max peer is 57.5% with overall availibilty of 1.587}

Questions:

1) Indeed I expected to reach my seeding goal after having reached the ratio 1.0 since due to the initial seeding option I should ul only peaces which are not available to other peers. I quote from http://en.wikipedia.org/wiki/Super-seeding As peers connect, the seed will inform a peer that it has received a new piece, one that has not yet been sent to any other peers. Now it seems rather that I will reach an availibility of =<2 after a ratio of at least 1.5 if not more. Why?

2) Can it be that the seeding progression (best followed on the basis of the availibility indicator) is not linear (in time) but rather somewhat exponential (slow at the beginning and progressively faster especially at the end)? (I got this impression but I did not measure accurately enough to be sure.)

3) Why is the seeding (generally speaking but of course even more for an initial seed) action deprived of many technical indicators which are available for leeching: no information at all about piece exchange and progression (Pieces and Files tabs), no usable extrapolation of ETA (up to availibility >=2)? {After all technical stuff I read at many places I came to the simple conclusion that there remains no better optimised way than doing everything manually concerning the management of the whole seeding procedure from the start to the end. This includes especially the queueing and bandwith management but it would be beyond the scope of this thread to go more in depth into it now.}

4) Speaking about bandwith management, not knowing the technical aspects of ADSL, I wonder if the fact that the used dl bandwith affects the remaining ul bandwith (and opposite) is inherent to any ADSL connection? [For me it is clearly the case and it makes an effective automatic management (with the use of the available uT settings) practically impossible but again, this is beyond the boundaries of this thread...}

5) Just because I want it to be said again... Why do the trackers assume that there is 1 seed since theoretically in initial seeding mode I am not visible as seed?...

[Edit] 6) Oh I forgot one question... On the Peers tab I made visible the Inactive (time) Information. In my initial seeding I described above there are some peers which remain connected though inactive for up to 16h. Why is this (since "peer.disconnect_inactive_interval" still has got it's default value of 300, means 5 min)?

Thanks a lot for your replies and constructive comments. :-)

[Switeck]

1) Probably peer churn rate. Peers that have critical pieces of the torrent may have stopped the torrent...maybe they only wanted a couple files or just plain gave up. Either way, they may remove a significant percentage of availability when they leave.

2) Somewhat. If the torrent swarm is smaller than 5 peers or larger than probably 30 peers, initial seeding doesn't perform as well. Try setting connection max per torrent to only 10-20. This will cause the purely leeching peers to disconnect from you after awhile to be replaced by peers that are more willing to return the favor to the swarm.

3) The indicators don't work in seeding mode because a few of them are irrelevant or incorrect. Your piece availability is 100% for one, so the downloaded bar is always solid. ETA can't guess whether a hit-and-run peer leaves the torrent and causes huge availability drops. Initial seeding mode isn't even consistent at uploading at 100% set rate. If you want to try adding "bum" ips to ipfilter.dat, good luck...it probably won't help how well you're seeding the torrent.

4) TCP networking is very vulnerable to DL/UL stalls caused by slow ACK packet arrival. This can be caused by trying to upload at unlimited (or just too-fast) speed for your line and the ISP randomly destroying packets over the limit. If slow ACK packets are bad...lost ones cause BIG speed decreases.

5) uTorrent even in initial seeding mode reports itself as a seed to the tracker.

6) Inactives are only disconnected if you are close/at/over max connections per torrent or global.

[BlueDragon]

Thanks a lot Switeck for your quick reply.

1) Yes that could be a very good explanation. Maybe they would come back later but anyway it may severly impact the initial seeding.

2) I just changed my settings to 20 and I may reduce even more after a certain period of observation. Presently with only 24 connected (left) the max. inactivity is around 20 min. Probably I will try to reduce it to max. 10 min. in a next step.

3) What you say is perfectly correct. Nevertheless I would find it good to have the information about the piece # which have been (already) ul and / or the availibility of a given peace which is being / has been ul.

Why do you say that initial seeding mode isn't even consistent at ul at 100% set rate?

About IP filtering how could i find out what IP's should be banned in this situation??...

4) I could not figure out what ACK packet means but do you intend to say that this problem is not a general (typical) problem with ADSL? {In the meantime I also suspect my "old" Zyxel Router especially because when I am ul or dl with full bandwith I have to wait 30-60s on webpages in my browser if not more (timeout)...} What I can say is that in my situation the quality of the copper cables (too big distance) is the bottleneck because actually my ISP would allow 5000/500 kbits/s. I should move into a big town...

5) Ok. The funny thing now: on all the trackers 2 seeds are reported except only 1 seed on 1 tracker. But with an availibility of 1.599 it cannot be true at all... I must still be the only seed.

6) So what is the use of the "peer.disconnect_inactive_interval" in that case?

Thanks again for your valuable input!!

[Switeck]

3) The lack of more precise info about pieces also can be the result of uTorrent not knowing everything. Knowing everything requires more bandwidth and ram usage, because uTorrent has to poll all connected peers for changes and store the results in ram. Initial seeding is dependent on how well peers respond and upload to others, it can BADLY stall if the peers refuse to share pieces with each others. I'm not going to tell you how to determine which ips are less "good" than others, because most of it is arbitrary and you don't really know what the peers are doing. Suffice to say, that blocking lots of peers WILL badly hurt your ability to seed.

4) Go GOOGLE the basics of TCP/IP networking that the internet+Ethernet is built around. "I have to wait 30-60s on webpages in my browser" = sounds like a crappy router problem.

5) If your ip changes, the trackers see you as a "new seed" and still remember the old seed ip for awhile.

6) To disconnect ips if/when at or near connection max. They'd just stay connected without that settings even if not DL/UL for hours.

[BlueDragon]

3)

Knowing everything requires more bandwidth and ram usage, because uTorrent has to poll all connected peers for changes and store the results in ram.

Yes I agree and I don't really see the problem... Nowadays we are not talking much about bandwith and RAM limitations for so little and even if that would be a relevant factor for some poeple, it could be easily disabled by default allowing any use if needed and for the ones ready to pay "the price" for it.

I'm not going to tell you how to determine which ips are less "good" than others, because most of it is arbitrary and you don't really know what the peers are doing.

Well that's fine to me but please remember that you started to talk about this possibility so don't be surprised if someone tries to follow your thread... Anyway what I like so much with Internet is that it is the biggest "library" on earth so by chance I already find this information (actually I even received it) elsewhere. You are basically fully right but I think if something is explained thouroughly than a judicious decision can be made. If I come here and devote a lot of time to try to understand the ins and outs of an application like uT, especially as we are talking about seeding, do you think with a good information I would "hurt my ability" to seed?

To me one point has become clear: uT has to be improved a lot, especially in seeding matters and good forum discussions can help in that way, at least I believe it.

4)

Go GOOGLE the basics of TCP/IP networking that the internet+Ethernet is built around.

Let me tell you openly that this is typically the answer I was somewhere expecting from you out of the feeling I got by reading many other threads with this style of replies from you. That is why at the beginning of my thread I wrote what I wrote... So FYI I did not already google but I went directly on wikipedia and I did not find anything with these 3 letters "ACK". But thanks for the advice...

Yes, as I already stated the router might well be the problem in these limited bandwith conditions...

5) That's fine but my IP did not change AFAIK... :/

6) So this would only be the case when someone lowers the max connection since at connection max any new connection is simply refused by uT so no question of timeout then...

Thank you!

[Switeck]

3) The problem is, total awareness of the torrent swarm's state uses a LOT of upload bandwidth...which dang near everyone doesn't have enough. Many people have less than 10 KB/sec upload speed available for each torrent they're running...and that's likely split between multiple upload slots.

ip banning:

First define what a "bum" peer is to you. (Very slow downloading from you, never shares to others, sends out corrupted pieces, inside an ip range of companies trying to destroy/disrupt the internet, etc...)

Then figure out how to spot them.

Then figure out how to eliminate false positives...or you could end up blocking semi-good peers.

Add those ips to your ipfilter.dat

Reload ipfilter.dat in uTorrent or uTorrent won't notice changes. (Right-click in PEERS window of an active torrent.)

Ban/block too many peers, and you won't even be uploading at max speed!

(This is why ...maybe remove them sometime later...in case they've improved/changed their settings.)

4) ACK (ACKnowledgement) packets are replies to incoming downloaded TCP packets and a required part of TCP/IP networking. I'm really shocked you didn't find stuff about ACKs in GOOGLE searches, not like I thought I was telling you to do something difficult.

5) That's just 1 possibility. Another is there's peers you can't see. Maybe they were previously connected to you...and left with a sizable chunk of the torrent, thus surpressing your current availability view. They then managed to create a seed out of parts they gathered from other peers that were probably still connected to you. You could start another copy of uTorrent with the same .torrent file loaded but incomplete/0% and see if you can connect to another seed that way.

6) Pretty much. However if at (or very near?) connection max, uTorrent will then start disconnecting "bum" peers that are idle. If you're getting incoming connections, this can still happen often.

[BlueDragon]

First of all, thanks again for having taken the time to develop some points further.

3)

The problem is, total awareness of the torrent swarm's state uses a LOT of upload bandwidth...

Ok if you state it I accept that it must be like that. Of course I understand that more features may become a problem for the "average" people (not wanting to invest so much time as we do, for having a torrent client to work efficiently or simply not to technical) but on the other side I was close to dl and instal Vuze to try the detail features which apparently are available there... In this situation I believe that the best is to keep the UI simple (and stupid) and to have the most important settings set per default on "low budget" values (little bandwith, ram etc.) , which will be the best for the non technical people. For the more technical or interested guys there should be the needed options like presently, somewhere "hidden" under advanced with a big warning: do not modifiy!... (which rather makes me even more feeling like to modifiy them )

Thanks for the little course on the banning procedure. I already played with it before...

4) As stated I had a direct look (no Google) at wikipedia about tcp ip. There I could not find any information about it. Googling is easy but it can be very time consuming and cumbersome to filter the outpout, especially with only 3 letters like that. I did not intent to shock you!

5) I had to read twice but I understood your theory. In the case I saw this could not be applicable because I am the initial seeder (with inital seeding) and that happend long before someone could have enough pieces for this what you described to happen. But it's a very interesting theory I did not think about before, which might occur. I think sometimes the trackers are simply getting somehow confused and showing wrong data. There are lots of discrepancies which can be observed over the time, that is my practical experience. Sometimes even both the different trackers from PB schow different values for some time before "agreeing" again. It's like the downloaded info for the torrent I am still uploading (about 12GB now). The h33t tracker shows 1 download (which can definitely not be true) and all the others 0.

6) The mechanism is not clear to me. Does uT disconnect idle peers only if close to or at max connection AND if others are "knocking at the door"? Anyway I don't see the use of the time out limit because in my case I have a max conn. set on 60 (for the torrent and the other overall max is not playing a part here) and around not more than 45-50 peers connected (though they could be much more I think because in the swarm there are around 140-150 available). Some are connected and inactive since over 13 hours and have not been kicked out, though regularly connection are closed and handshakes completed again and again.

I have been looking in depth in the logger feature so I can better grasp what is happening in the background. Unfortunately (sorry) I must point out that IMO the logger feature is also very poorly implemented in uT. It gives you a headacke faster than something else!... No way to stop the scrolling (except to take away all the flags one by one), no way to filter any information, no way to focuse on only 1 torrent, left aside only 1 peer etc... but it's better than nothing at all!..

Finally for those who might be interested I would like to point to a ("cross forum") link about optimal inital seeding which I would recommend: http://suprbay.org/showthread.php?t=14029 NB: You will have to register (free) if you want to access.

And last but not least let me come back on this statement:

2) Somewhat. If the torrent swarm is smaller than 5 peers or larger than probably 30 peers, initial seeding doesn't perform as well. Try setting connection max per torrent to only 10-20. This will cause the purely leeching peers to disconnect from you after awhile to be replaced by peers that are more willing to return the favor to the swarm.

I have been told the opposite on the above mentioned forum thread which I would like to quote here:

Noooo--that's the worst thing you could do. When you're super/initial-seeding you should increase the no. of connections per torrent. Your client won't upload a second piece to a peer until it sees that piece on another peer--which you won't see if you're not connected

Thanks!

[EDIT]

In the meantime here are the final results of this initial seeding experience with a 7.5GB torrent. I had to upload 12.7GB which means a ratio of 170.4% and it took me 7d+8h. During the last days there was generally a difference of about 1% between the overall availability and the max completion % of the top peer. In the last hours the spread went down towards 0 and as soon as the availability hit 200% I stopped seeding. At that time there where about 150-180 peers. Within 1-2 min 40-50 seeds appeared and if I remember well there where around 100 peers left. Then the # of seeds increased quickly towards 70-80. About 12 hours later there where around 50-60 seeds + 40-50 peers left.

Since for an initial seeding the upload ratio is expected to be around 105-120% I wondered why such big difference in my case. There are of course many possible reasons which may ultimately add up. One of these, as someone pointed out in another forum (see above), could be my fiddling around but I don't have the impression at all that this could explain such a bad result. So I have been investigating more and I had a detailed look at your recommended speed settings here http://forum.utorrent.com/viewtopic.php?id=58404. Also I delved into the TCP/IP protocol details to better understand what the ACK segments are doing. It came to my mind that the capacity limit of my ADSL line actually could be the main reason of my very ineffective initial seeding experience. I noticed in your conservative settings chart that you advise to limit the ul speed to a max of about 70-73% of the effective max bandwith. Only for 128-160 KBit/s you even go down to 56-65% (Is this intentional? Reason?). My investigations showed me that my ISP is willing and able to allow 1000 MBit/s though I can only get around 230 KBit/s ul. In a further step I found out that the distance between my PC and the next telecom node is the problem and bottleneck. Another thing I noticed on my speed chart was the big irregularities (volatility) at max e.g. unlimited ul speeds. I put it together with what you told me above concerning the lost packets because of the ISP possibly destroying them randomly in an effort to limit the bandwith. I tought that there must be a reason why you are advising to limit the max. ul speed to only about 70% of the (measured) max. bandwith. So I tried limit more and more the ul speed in 1 KBytes/s steps and after a certain limit the chart volatility becomes much less (best visible in 1 or 5 sec charts): the speed line flattens and remains always above the straight red limit line whereas in unlimited state it's jumping up and down, like when hitting the ceiling it's being knocked down again before it tries again to go up to the limit. So this could be a reason for regular and big tcp packet losses which would oblige my uT to send some data again and again in duplicated form or even more. If the counter of uT indicates the effectively sent data (not only the acknowledged one!) than of course this could explain the 50 % bytes more I finally had to upload!

Please let me know what do you think about my last assumption and why you advised this limit at approx. 70% (or below for the 160-128 KBit/s lines) of the max. available upload bandwith.

Thanks again

[Switeck]

4) That's why I used TCP/IP networking and ACK for the GOOGLE search.

5) Bum trackers seem a possibility. I know I've seen peer/seed counts before that were suspect. Seeds at least are sometimes counted as peers as well. I guess it's remotely possible someone who only downloaded 1 file and set the rest to not download might be mistakenly thought of as a seed by some tracker types? Timing of each tracker updates could make at least small differences between trackers.

6) uTorrent disconnects idle peers if close to or at max connections regardless of additional peers trying to get in. You're not close enough to max for uTorrent to start kicking them, but it is strange you're not connecting to more if there really *IS* 140-150 peers available in the swarm.

Have the logger save to a file and read the file while uTorrent continues to run.

Or do CTRL+A, CTRL+C and paste that into notepad/wordpad/whatever to view just a ~100 line snapshot of what uTorrent is doing.

I turned off practically all the verbose logging so my logger window is actually quite slow even with ~10 torrents started and ~20 total active peers across all these torrents. However my bt.connect_speed AND net.max_halfopen are both set lower than default...since I see no sense in spam-retrying dead ips over and over again as fast as uTorrent allows.

You can have logger focus on 1 peer or all highlighted peers of 1 torrent -- just right-click in the PEERS window and choose "Log Traffic to Logger Tab". This can be messy too!

"When you're super/initial-seeding you should increase the no. of connections per torrent. Your client won't upload a second piece to a peer until it sees that piece on another peer--which you won't see if you're not connected"

2) That would be true if you have spare bandwidth to burn. But if you don't, you end up with lots of peers you WON'T upload to but still must do all the other BitTorrent protocol communcations with...and vice-versa. You'd even see some of their traffic in logger if you had verbose logging enabled, but beyond even that keep-alive packets have to be sent to keep the connection open to them which although very small individually add up. If the torrent's busy enough, the odds of a bad ip continuously reconnecting to you goes down drastically until predominately only bad ips are left. uTorrent keeps a memory of how much it uploaded/downloaded with a peer even when it disconnects with them...at least for awhile (typically well over an hour.)

[BlueDragon]

6) uTorrent disconnects idle peers if close to or at max connections regardless of additional peers trying to get in. You're not close enough to max for uTorrent to start kicking them, but it is strange you're not connecting to more if there really *IS* 140-150 peers available in the swarm.

I have been testing some more by connecting to torrents with over 100 peers and seeds. The results where different than what I expected following what has been said previously in this thread.

In the case I am acting as peer (not [EDIT] initial seeding) my client checks every minute if any connected peer is inactive for > 5 min (default setting of 'peer.disconnect_inactive_interval'). If yes it is immediately kicked out. There is no direct relationship at all with the max connections (torrent or overall)!

As stated previously when I was acting as initial seeder some peers could remain connected for many hours so it's clear that this "inactivity disconnection" does not to apply to initial seeding [EDIT] but it applies to normal seeding too. (my wrong former statement was >>nor does it to normal seeding.<<)

...it is strange you're not connecting to more if there really *IS* 140-150 peers available in the swarm

Well I wanted this to be clarified once for all because I also was wondering why... So for testing purposes I increased my limits up to 150 max connections (overall and torrent) and I connected as peer to a swarm of hundreds of peers/seeds. I let uT play the game until I had about 150 connections. I also fiddled around with the 'net.max_halfopen' option and as I expected (XP SP1) increasing the # seemed to speed up the establishment of this huge amount of connections but I could reach it anyway with the 8 (default). I concluded (happily) that my router is not limiting this amount of connections. So I think that when I am not reaching my max even in a big swarm there must be other reasons for that, beyond my control (e.g. bad peers, bad connections etc.)

About the logger I have been testing around as usual since I did not find any consistant information in the uT help. Is there any place where its use has been thouroughly documented?

Actually the proper use of the logger is very confusing at the beginning. I noticed that there are basically 2 ways to activate it: a) by setting the flags (right click in the logger panel) which will anyway always count for ALL the torrents or as you stated by highlighting one or several peers in the peers tab, right click and select 'log traffic to logger tab' which will log ALL the traffic for the selected peer(s). So it seems not possible to be selective by choosing a given peer AND logging only a specific activity (like with the flags). Besides it seems that if you start by setting some flags (a) AND also use method ( than both cumulated information will be logged... Finally to stop the logging if you used method (a) you must right click in the logger tab and select 'clear log' whereas if you selected method ( you must right click in the logger tab and select 'clear all logging flags'. I took me quite a while to find all this out so I hope this little "basics tutorial" might help others...

2) That would be true if you have spare bandwidth to burn. But if you don't, you end up with lots of peers you WON'T upload to but still must do all the other BitTorrent protocol communcations with...and vice-versa.

Yes you are right, even to keep up an idle connection takes up some bandwith but it's relatively minimal according to my testings. When I connected 150 peers/seeds at the same time I was continuously uploading with a max set at 22 KBytes/s (for a bandwith of 230 KBit/s) and only starting at around 120-130 connections, did my upload speed line start to show some slight drop downs. Besides don't forget that as inital peer I don't have to upload data to all my connected peers but the main point in this strategy is to "keep a door open" in order to increase the chance to get the have information of another peer, as go signal that I might upload another piece to a peer I already served before.

Please answer to the questions I asked in the [EDIT] part of my former post. It might not have been very obvious to see them, sorry...

Thank you!

[Switeck]

6) Sounds like based on your testing uTorrent's peer.disconnect_inactive_interval is broken while seeding.

I use uTorrent's Logger some. I don't claim it's easy to use...and I don't have a manual or documentation to it.

Sorry.

2) A bandwidth meter program can show how much "background" bandwidth gets used while uTorrent is running. Is that what you're using?

There are data updates done between seeds and peers even if no parts of the torrent are exchanged. HAVE messages...an initial seeder cannot use a generic HAVE ALL message like a regular seed can. The seed has to report and update its speeds too, if I understand BitTorrent correctly.

I read your edit...

Your average upload speed thus ended being just over 21 KB/sec. Because there were peers within 1% of the availability (besides you as the seed), this means you were definitely the limiting speed factor for the torrent. Once seeds started forming, many seeds form rapidly by heavily utilizing the highest speed connections. So at least on that side, things are working fine.

"Since for an initial seeding the upload ratio is expected to be around 105-120% I wondered why such big difference in my case."

I've given you my guesses. Hostile (intentional or otherwise) peers are also a remote possibility.

TCP connections act weakly half duplex. They're not true half duplex connections, but under heavy loads they resemble that.

There is a simple reason -- my speed chart assumes 2 things:

1.You want to be able to DOWNLOAD at a fast rate while uploading.

2.You (or others on your LAN network) want to web surf without crippling lag while uTorrent runs.

In both cases, percentage of upload max isn't as important as leaving a significant amount of upload bandwidth unused by uTorrent's upload speed. It is not designed to be set as fast as the line can go, but rather roughly as fast as the line can go without causing other things problems. Many people don't even get their full rated speed from their ISP, so the settings are even a little on the low side. Alternate upload speed while not downloading (only seeding) can be set slightly higher as a result of this.

At much higher speeds, my chart assumes the connection is shared and/or not really reaching the stated limits. At 100 megabit/sec, many LAN cards are only 80-95% usable...thus even BEFORE other considerations 5-20% of the bandwidth is lost!

A 1000 megabit/sec line from your ISP is only possible with fiber optics and would be insanely expensive. ADSL 2+ is only capable of around 24 megabit/sec down and 1-3 megabit/sec up, and even if you're 500 meters from the local node you're likely already reduced in speed. By 3 KM, speeds fall to probably less than 5 megabit/sec total. The ADSL lines are grouped together into a DSLAM which may only have 100 megabit/sec down+up to connect back to the rest of the ISP. Then multiple DSLAMs may be connected to a single OC-3 (155 megabit/sec down+up) line that reaches out to the rest of the internet.

Once uTorrent's upload speed gets stable that means you're probably not overloading your line -- except possibly very slightly and/or briefly.

"the speed line flattens and remains always above the straight red limit line"

I don't have that problem, both the speed line and the max limit line are extremely close.

Are you running v1.8.3?

"whereas in unlimited state it's jumping up and down, ...this could be a reason for regular and big tcp packet losses which would oblige my uT to send some data again and again in duplicated form or even more."

I wouldn't expect lost/duplicated data to explain more than 10% of your total "excess" upload.

I believe the counters in uTorrent reflect the acknowledged data sent/received.

[BlueDragon]

6) Sounds like based on your testing uTorrent's peer.disconnect_inactive_interval is broken while seeding.

Yes and no. I just have edited my former post because I did a mistake by stating that the connection inactive for >5min would not be closed if seeding normally. This statement applies only to initial seeding at to me it makes perfectly sense. This is one reason more why I believe that it's better to try to maximize as best as possible the allowed connections when initial seeding. That makes sense because even if the keeping alive of many inactive connections will cost some (relatively little) bandwith it's more important to rise the chances to get the feedback of the swarm that unique pieces have been shared. Otherwise especially if the initial seeder has a good upload bandwith he may not be able to seed continuously anyway.

At this point I must say that it would be good to have some people in this forum knowing about the internals of uT and the BitTorrent protocol in general, so others would not have to test and guess like it's far to often happening... but it's the only way left to get further...

I use uTorrent's Logger some. I don't claim it's easy to use...and I don't have a manual or documentation to it. tongue

Sorry. sad

That is exactly what I have been refering to in my statement above. I do not understand why an application like uT has been written and is being used by thousands of people around the world, yet there is not even a (advanced) user's guide for documenting the various functions and options!! What is the use of a logger if you don't have a clue how to use it and what the output is all about... This being said I thank you Switeck for transmitting what you know (and sometimes think you know but that is happening to all of us if we are frank)

2) A bandwidth meter program can show how much "background" bandwidth gets used while uTorrent is running. Is that what you're using?

No I have not been using a program like that but I will give it a try because I would like to go more in depth about this important network / bandwith topic. What I was refering about in my former post about the upload speed line just was the speed tab of uT. It should be sufficient to reflect the upload speed. So if this speed is very constant and by increasing my connected pears up to a point of saturation because of "background" traffic needed for keeping all this connections alive, I see a drop in the upload speed than it's a clear sign that all these connections are indeed more hurting my upload speed than helping to optimise it further.

In both cases, percentage of upload max isn't as important as leaving a significant amount of upload bandwidth unused by uTorrent's upload speed. It is not designed to be set as fast as the line can go, but rather roughly as fast as the line can go without causing other things problems.

I understand. So it's absolutely not for the reason I had in mind... You see talking about comfort e.g. being able to still surf the web while actively using uT I consider basically 3 main bottlenecks. (a) modem / router ( speed of the line (up to your ISP) © ISP

(a) can be improved by a better device and escpecially a better traffic management / packet priorisation on TCP/IP level. If this is not possible (costly) the cheapest solution is of course to choke uT and that is what you advise with your conservative speed settings.

( can be improved by changing the line (changing provider or moving to another place)

© same as ( but ISP instead of line

Actually I thought that the idea of limiting the upload bandwith usage of uT was based on some considerations linked with ( the line. I imagined that if one goes to far close to the capacity limit of the line there would be a threshold above which many packet losses would occur, this eventually leading to being the cause of a bad connection quality.

In my personal case it was absolutely not a primary concern since I manually simply limit the upload and / or download speed whenever the need arises (if say my web browsing is getting to slow). The rest of the time I leave it simply unlimited. Speaking about it I have been trying out a lot of methods and automated features of uT and I always come the conclusion that if I want the full control I HAVE TO do it manually!! Automated it only works half way at the best in most cases... I give you a simple example: today I have been trying to use the automatic bandwith allocation feature for priorising my uploads. I could send you screenshots showing you that the result was most of the time exactly the opposite of what I wanted (set it) to be... Sometimes I even wonder if for certain changes in the settings one would need to restart uT again for them to be applied!? Also I have been trying to change the # of ul slots per torrent and in another post you wrote about the debug column in the main screen. If I remember well you stated that the first # is the half open connections. The 2nd # the additional ul slots for the torrent and the 3rd # the max # of ul slots according to the settings. Now for instance I have rised the # of ul slots in the bandwith preferences from 2 to 3. The debug keep on showing 1 on the right (not for all torrents by the way...) and actually 2 slots (only) are being used for 2 seeding torrents out of 3. (All these 3 torrents are connected with between 10-20 peers so this is not the limitation I suppose). Do you have an explanation?...

I don't have that problem, both the speed line and the max limit line are extremely close.

Are you running v1.8.3?

It's not a "problem". I think it's pretty normal. Of course it depends how big you make your window (actually tab) and if you look at 1,5 or 30 sec steps...

I am running v1.8.2. because I don't want to take the risk to update now since I think there are still too many (new?) bugs taking the overhand on new features I do not need at all. For this I prefer the conservative side (not like for my speed settings...)

I wouldn't expect lost/duplicated data to explain more than 10% of your total "excess" upload.

I believe the counters in uTorrent reflect the acknowledged data sent/received.

Well I am not sure here so that is why I am trying to investigate deeper at packet level... You see talking about the counters it would be good to be sure of it (see my statement above).

Thanks!!

[Firon]

There aren't new bugs in 1.8.3 (apart from a few weird issues with UAC and the installer).

[BlueDragon]

@ Firon

Well I have been reading the 3 pages of the v.1.8.3. release and it's not just about the installer and UAC (Vista)... Also uTP seems still in early beta phase but granted, I do not have to activate it...

I will give it a try, cross my fingers and watch out for the Ask toolbar bundle...

[Switeck]

"At this point I must say that it would be good to have some people in this forum knowing about the internals of uT and the BitTorrent protocol in general, so others would not have to test and guess like it's far to often happening..."

I feel I have a pretty good handle on the BitTorrent protocol, but some of your questions have been exacting or edge conditions that even the designers/experts have not studied!

"What is the use of a logger if you don't have a clue how to use it and what the output is all about"

In the makers defense, much of what is in logger is readily understood by anyone with a strong networking background and/or has read the BitTorrent protocol specifications.

"What I was refering about in my former post about the upload speed line just was the speed tab of uT. It should be sufficient to reflect the upload speed."

uTorrent's download and upload speed graphs are normally showing ONLY the download+upload speed of torrent files, not the BitTorrent overheads and certainly not the underlying TCP/IP networking overheads. uTorrent's advanced setting net.calc_overhead (defaults to false) ATTEMPTS to estimate/calculate overall networking overheads, but its methods make it an approximation at best.

"I imagined that if one goes to far close to the capacity limit of the line there would be a threshold above which many packet losses would occur, this eventually leading to being the cause of a bad connection quality."

Yes, that actually happens...sadly very often.

My Speed Guide and the one built into uTorrent are conservative in their estimates of max upload speed because OFTEN an ISP claims you have 256 kilobit/second upload speeds...but you'll likely only have 230 kilobit/second USABLE upload speeds.

ADSL also has losses associated with PPPoA/PPPoE that cable modems and most other broadband connections don't have.

"I manually simply limit the upload and / or download speed whenever the need arises (if say my web browsing is getting to slow). The rest of the time I leave it simply unlimited."

An upload speed limit in uTorrent set close to max allows MORE to be successfully uploaded on most connections...than running with upload speed limit set to unlimited. ISPs are often overzealous in killing off "excess" packets if you exceed your speed limits.

"Sometimes I even wonder if for certain changes in the settings one would need to restart uT again for them to be applied!?"

There's almost no changes you can make in uTorrent that REQUIRE a restart of uTorrent. Stuff like changing to a proxy/VPN might need a restart...but that's really about all I can think of.

"the 3rd # the max # of ul slots according to the settings. Now for instance I have rised the # of ul slots in the bandwith preferences from 2 to 3. The debug keep on showing 1 on the right (not for all torrents by the way...) and actually 2 slots (only) are being used for 2 seeding torrents out of 3."

If the 3rd debug number is 1, you probably have too many torrents running for your limited upload speed.

http://forum.utorrent.com/viewtopic.php?id=3474

"A different upload approach"

I specifically ASKED for this kind of behavior back in late 2005. The semi-long thread explains why.

"I am running v1.8.2. because I don't want to take the risk to update now since I think there are still too many (new?) bugs taking the overhand on new features I do not need at all. For this I prefer the conservative side (not like for my speed settings...)"

There were also many BIG bugs in v1.8.2 that were patched by v1.8.3. The bugs I've spotted in v1.8.3 are old bugs I also had in v1.8.2. uTP connection handling was greatly improved, which is often a useful tool against hostile ISPs.

So long as you save a copy of uTorrent v1.8.2...the risk is essentially zero.

[BlueDragon]

I feel I have a pretty good handle on the BitTorrent protocol, but some of your questions have been exacting or edge conditions that even the designers/experts have not studied!

Of course I know that it's impossible to know everything so please don't take my comment too personnaly. Please consider my "exacting questions" as challenge in between many other ones filling this forum.

In the makers defense, much of what is in logger is readily understood by anyone with a strong networking background and/or has read the BitTorrent protocol specifications.

Sure... It's like telling me that what can bee seen under the hood of a car can be readily understood by anyone with a strong mechanical background but you did never tell how to open the door and what to do to start the engine... :/

uTorrent's advanced setting net.calc_overhead (defaults to false) ATTEMPTS to estimate/calculate overall networking overheads, but its methods make it an approximation at best.

Well in the meantime I installed v1.8.3 and tested with net.calc_overhead set on true and false but that makes absolutely no difference on my pc...

I also activated uTP and I don't feel any difference neither...

But I noticed a big difference: if I don't limit my upload speed than the effective ul speed is totally breaking down whereas with v1.8.2 it did never behave like that! But I know, it can be readily understood by anyone with a strong networking knowledge...

ISPs are often overzealous in killing off "excess" packets if you exceed your speed limits.

Well this is definitely not applying to me because as I explained in a former post of this thread my ISP would be willing and able to deliver 5000/500 instead of the 2300/230 KBits/s I have because of the too long line.

If the 3rd debug number is 1, you probably have too many torrents running for your limited upload speed.

Could you please tell me again what these 3 debug # exactly are?

In any case whatever the # >2 I put in the Bandwith--># of ul slots per torrent, I don't get more than 2 upload slots per torrent. I will read your thread...

So long as you save a copy of uTorrent v1.8.2...the risk is essentially zero.

Well in essence I'd say yes. Indeed I lost all my settings and stats on my notebook because of the uprade... As usual I did not have the standard setup (I moved the dat files from the c: drive) and I managed to have them overwritten by the new dat files.

But I am happy, now I have got new (undocumented) P flags... (I know, my ISP is very good to me, at least until now)

[Ultima]

P: peer is communicating and transporting data over uTP

[Switeck]

If it's not documented enough to your taste, at this point you could probably make a FAQ of your own...

You've pretty much exhausted my knowledge.

[BlueDragon]

P: peer is communicating and transporting data over uTP

Thanks Ultima. Actually I figured it out on my own. With the [uTP] behind the IP having that P it was not too difficult...

If it's not documented enough to your taste, at this point you could probably make a FAQ of your own... :tongue:

You've pretty much exhausted my knowledge. :sad:

I will consider this as compliment...

And for the FAQ I will use 2 big dices, one for the meaning of the 3 'Debug' values and the other one for the meaning of the possible values of bt.transp_disposition...

Thank you for your time!

[DreadWingKnight]

the other one for the meaning of the possible values of bt.transp_disposition...

Even though bt.transp_disposition was discussed in the 1.8.3 beta and 1.9 alpha threads?

[BlueDragon]

Even though bt.transp_disposition was discussed in the 1.8.3 beta and 1.9 alpha threads?

Oh yes, 41 + 4 pages to search through... I tried again, having battled around with the search engine for a couple of mins...

If you want to do the same just click here (best search result I could get): http://forum.utorrent.com/search.php?search_id=733016017&p=4

And here is the most representative "information" I could find... http://forum.utorrent.com/viewtopic.php?pid=402974#p402974 At least I can see that I am not the only one having the same problem...

Sorry to be blunt but that's exactly the waste of time I don't like for something which could so easily just be posted once for all in a complete and understandable fashion. :mad:

[Ultima]

for something which could so easily just be posted once for all in a complete and understandable fashion. :mad:

You mean, like... in the first post of the thread DWK told you to look at?

[BlueDragon]

You mean, like... in the first post of the thread DWK told you to look at?

Yes I mean this...

How to enable and disable it:

Preferences > Advanced, change bt.transp_disposition. This is now a bitfield, so you can add up the following numbers to get your desired setting.

1 - outgoing TCP

2 - outgoing uTP

4 - incoming TCP

8 - incoming uTP

Specific combinations:

255 - both TCP and uTP, incoming + outgoing (future-proof setting, always will mean this)

15 - both TCP and uTP, incoming + outgoing (default)

and I wrote in a complete and understandable fashion... so apparently my IQ is to low (well after all I'm just a blue dragon) because I cannot do anything with this information!! And because you like to insist let me tell you that if you had read all the postings in the announcement threads (1.8.3 and 1.9) it would be clear to you that I am not the only one here to stupid to understand this language...

Need some examples?...

Say I want only TCP in and out (no uTP at all), will I have to set the value to 1 + 4 ??

If I want to have incoming TCP or uTP but outgoing only TCP, will I have to set the value to 4 + 8 + 1??

What is the difference between 255 and 15? What does future-proof setting, always mean this mean?

What does 13 (default value in 1.8.3) mean?

and so on...

But I am sure you know it so why should we waste our time talking about it... :cool: