JMJimmy Posted June 24, 2013 Report Share Posted June 24, 2013 I'm just looking for information to see what the norm is... this is what I'm seeing:http://i.imgur.com/4NkARia.jpgWhenever I download a file the upload stream crashes and then is immediately restored upon completion. Now some of this can possibly (?) be attributed to re-provisioning of connections previously used for upload to download but this is what I thought was normal:http://dl.dropbox.com/u/41098084/uTorrentSkin/Old_Graph_before.pngie: a small dip in upload speed but overall the download does not dramatically affect seeding.I ask because I'm trying to determine if this is Bhell trying to implement yet another anti-P2P scheme, a defect in Alcatel Lucient Stingers, or something else entirely. I do not suspect any problem with utorrent or configuration as the cause of the issue - it's the standard 9.2Mbit configuration on a 26/11Mbit profile and the modem/router has been eliminated as it appears on both a Sagemcom 2864 + interleaved and a Cellpipe 7130 + fastpath Link to comment Share on other sites More sharing options...
Andreasvb Posted June 24, 2013 Report Share Posted June 24, 2013 Could be a duplex setting on the NIC.If it can't handle full-duplex then it will count both download and upload to the total.http://en.wikipedia.org/wiki/Duplex_(telecommunications)Also, upgrade to latest version, recommend 3.3.2 beta for least bugs. Link to comment Share on other sites More sharing options...
JMJimmy Posted June 24, 2013 Author Report Share Posted June 24, 2013 Would duplex related issues appear for any type of traffic? ie: if I initiate an HTTP download would I also see this pattern? Link to comment Share on other sites More sharing options...
Andreasvb Posted June 24, 2013 Report Share Posted June 24, 2013 Yes.Open Network Settings (ncpa.cpl) and select your NIC then go to Properties > Configure > Advanced.See if you can find anything about duplex or speed and try change it and see if it works better. Link to comment Share on other sites More sharing options...
JMJimmy Posted June 24, 2013 Author Report Share Posted June 24, 2013 That's the interesting thing - I only see this pattern in P2P - If I download from Steam/Browser/etc P2P upload is completely unaffected.Checked the setting anyway and it's set to auto-negotiate... I'll try forcing 100 full to see if it changes anything, just in case. Link to comment Share on other sites More sharing options...
ciaobaby Posted June 24, 2013 Report Share Posted June 24, 2013 BitTorrent protocol is NOT the same as HTTP so the two cannot be compared. Link to comment Share on other sites More sharing options...
JMJimmy Posted June 24, 2013 Author Report Share Posted June 24, 2013 BitTorrent protocol is NOT the same as HTTP so the two cannot be compared.I wasn't - hence my above question on whether HTTP/non-p2p traffic would have a similar affect while seeding if it were a duplex problem. Link to comment Share on other sites More sharing options...
ciaobaby Posted June 25, 2013 Report Share Posted June 25, 2013 It won't, because they are two different methods and protocols. Link to comment Share on other sites More sharing options...
JMJimmy Posted June 25, 2013 Author Report Share Posted June 25, 2013 It won't, because they are two different methods and protocols.ok... can you offer any explanation for the consistent upload crashing upon downloading a file? Link to comment Share on other sites More sharing options...
ciaobaby Posted June 25, 2013 Report Share Posted June 25, 2013 Sure ... First: BitTorrent is NOT a constant rate protocol, it spikes all the time, and to diagnose a "issue" based on what you think you see in the speed graphs is not going particularly accurate or complete.Here's a screen shot of my client (3.3.2.29806) Can you tell what is happening from that?You will only track down a problem which may or may not exist by having detailed observations of EVERYTHING that is changing at any point in time, and if UTP is enabled that could mean events that are external to your client and the machine it is running on. Link to comment Share on other sites More sharing options...
JMJimmy Posted June 25, 2013 Author Report Share Posted June 25, 2013 I observe ping rates, tracerts, line stats, and (as best I can) peering activity. Obviously I can't monitor everything but to have very consistent behaviour where upload inexplicably crashes relatively proportionate to download rates suggests a problem on my line. From what I've observed ping rates, tracerts, & line stats all remain normal during these periods - only P2P is affected. I suspect Bhell is up to something and I'd like to track it down but finding reliable information is difficult. I've been trying various mLab tests to see if I can track down the problem but they all seem to do single direction tests not bi-directional. Link to comment Share on other sites More sharing options...
ciaobaby Posted June 25, 2013 Report Share Posted June 25, 2013 ping times are only useful for "least cost" routing which BitTorrent obviously does not use. see if I can track down the problem but they all seem to do single direction tests not bi-directional. How can you do bi-directional testing with anonymous peers. There is no server to do bidirectional testing with.YOUR connection and YOUR client is not THE arbiter of the speeds, both up and down. What connected peers do ALSO affects your speeds.HTTP is a disconnected protocol, a request is made to a server, the byte length of the data stream is returned in the response and the user agent simply reads the incoming stream until the correct number of bytes is reached during this transfer no more requests are made to the server.BitTorrent is a continuous process of data spikes with messages to and from trackers, peers, seeds, DHT, PeX, piece requests and responses from peers, add to this the various algorithms for fetching and sending pieces none of which are synchronised, so you could have several pieces in transit one moment, dropping down to none at all in the next. Link to comment Share on other sites More sharing options...
JMJimmy Posted June 25, 2013 Author Report Share Posted June 25, 2013 I know how BitTorrent works. By bi-directional I mean that some mLab tests will mimic P2P transfers but they will only send data in one direction at a time, not both simultaneously which is where the problem is appearing. The issue is consistent and reproducible - when only seeding upload is consistently near the max (~1MB/s) - when downloading upload becomes unstable (for lack of a better term). We're also talking about 5 minute data point intervals. The kind of ups and downs you're talking about are momentary and for upload especially the "use additional upload slots if upload speed <90%" option should also take over relatively quickly. Link to comment Share on other sites More sharing options...
rafi Posted June 26, 2013 Report Share Posted June 26, 2013 Maybe I missed something: what uT version are you running? Link to comment Share on other sites More sharing options...
JMJimmy Posted June 26, 2013 Author Report Share Posted June 26, 2013 build 29677 Link to comment Share on other sites More sharing options...
rafi Posted June 26, 2013 Report Share Posted June 26, 2013 Move to 3.3.1. Issues with upload balancing were fixed there. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.