Slow as P2P

Connection issues, drop outs or speed related faults for ADSL and ADSL2+ services
thelazysa
Posts: 5
Joined: Thu Feb 23, 2012 2:14 pm
Location: Shellharbour

Re: Slow as P2P

Post by thelazysa » Mon Jun 04, 2012 11:55 am

Diji1 wrote:So basically the answer to user issues reported here and over at Whirlpool is:

"We're not going to fix the issue - use a different Bittorrent client"

If you guys don't fix this by mid month I'm changing to TPG. I expect an ISP to fix these things - if it's your suppliers then fix it. Or else maybe you don't want me.

My Bittorrent speeds have been pathetic - 20 kB/s if I'm lucky, usually less. Before you ask: I've been using Bittorrent for years, I'm downloading from swarms with huge SLRs and multiple high speed peers which used my entire bandwidth previously.

Recently my line was looked at to diagnose an issue which turned out to be an issue with my router and not Exetels responsibility. However since then I've had absolutely terrible Bittorrent speeds so something changed. You need to fix it.
Mate, i'm not even Exetel staff but threating them is not going to get you anywhere.

The better question ask is; Was the decision to drop the cache a financial reason or other?

User avatar
Dazzled
Volunteer Site Admin
Posts: 6002
Joined: Mon Nov 13, 2006 1:16 pm
Location: Sydney

Re: Slow as P2P

Post by Dazzled » Mon Jun 04, 2012 12:44 pm

The PeerApp devices were originally justified by the huge load that P2P was making on overseas connections. It kept the cost of internet down, as was mentioned in earlier references. A very nice side effect was disguising less than perfect user configs where popular traffic was concerned.

There were some official Exetel announcements made in the recent newsletters, as follows:
March

March will see some exciting network challenges for the engineers at Exetel.

One such challenge is the preparation and then implementation from the current 1G backbone network to a switched 10G network. One challenge we are tasked with is the removal of all three Peerapp devices. We have currently deployed NSW, VIC and QLD. The Peerapp units have been very successful in providing Exetel reduced cost bandwidth for our residential services; however just like the NetEnforcer it is now time to remove this from the network as is no longer justifiable to implement in the future network model.


April

Our engineers have completed all the goals intended for March 2012 which is an excellent achievement for the team. NSW, VIC and QLD have now been upgraded to 10G backbone and have ample supply for the foreseeable future. In April 2012, we will have AAPT IP transit back into our mix of transit providers.

The final Peerapp cache unit that has been faithfully supplying Exetel with caching services. This unit will also finally be decommissioned as an ongoing project. Peering has continued to have outstanding performance. Google has shown continual growth in the delivery along with Akamai.

May

It has been an interesting month for April; we have monitored the performance of the new transit provider and along with the retirement of one of our caching engines. The implementation and upgrading of Google and Akamai caching has meant our original cache server was delivering progressively less traffic, to the point where it was no longer cost effective.
When I read Diji1's post soon after posting I fired up a test torrent, this time the recently released Linux Mint 32 bit Mate DVD, a 900 MB iso. Result -
248 (253) seeders; 18 (59) peers; down speed 873 KiB/s. On a standard Exetel home connection. A better line would have been quicker. This isn't something to complain about. These recent major distros make good tests of torrent configuration.

Diji1
Posts: 21
Joined: Mon Aug 11, 2008 2:48 am
Location: Adelaide

Re: Slow as P2P

Post by Diji1 » Fri Jun 08, 2012 1:41 am

thelazysa wrote:
Diji1 wrote:So basically the answer to user issues reported here and over at Whirlpool is:

"We're not going to fix the issue - use a different Bittorrent client"

If you guys don't fix this by mid month I'm changing to TPG. I expect an ISP to fix these things - if it's your suppliers then fix it. Or else maybe you don't want me.

My Bittorrent speeds have been pathetic - 20 kB/s if I'm lucky, usually less. Before you ask: I've been using Bittorrent for years, I'm downloading from swarms with huge SLRs and multiple high speed peers which used my entire bandwidth previously.

Recently my line was looked at to diagnose an issue which turned out to be an issue with my router and not Exetels responsibility. However since then I've had absolutely terrible Bittorrent speeds so something changed. You need to fix it.
Mate, i'm not even Exetel staff but threating them is not going to get you anywhere.

The better question ask is; Was the decision to drop the cache a financial reason or other?
Seriously? I'm not threatening anyone I'm saying I'm taking my business elsewhere if they do not fix this. If you want to continue recieving substandard service in exchange for your money go ahead, more power to you.

The attitude being displayed here by Exetel - not fixing it and telling users to use a different client - is simply not good enough. If it's a problem with their wholesalers - which I'm suspicious of but let's say that's the reason for arguments sake - then they should be changing wholesalers.

Oh and just to make you aware, the cache has little to nothing to do with p2p speeds or the current problems.

User avatar
Dazzled
Volunteer Site Admin
Posts: 6002
Joined: Mon Nov 13, 2006 1:16 pm
Location: Sydney

Re: Slow as P2P

Post by Dazzled » Fri Jun 08, 2012 10:14 am

Diji1, Exetel senior people have already posted that neither they nor AAPT are filtering torrent connections. Something has changed, and was widely publicised; namely the cache removal, that as a by-product can disguise some torrent problems.

My torrent result is above, done at home on Sunday afternoon immediately after your post came in. Let's keep testing restricted to the major software "public" torrents (Mint, Ubuntu, LibreOffice etc), because we can usually guarantee no difficulties with swarms or people trying to hide their behaviour. The only way I have been able to get terrible results on the major "public" software torrents has been to deliberately interfere with my router and ruin the torrent client configurations. I don't even have to fully optimise my system to get 800+ kB/s. My conclusion has been that people who are slow on these particular downloads probably need to attend to their computers.

I wouldn't run to conspiracy theories as I have read without doing some serious looking of my own. All the software for creating torrent packets, fancy route tracing, router and NIC monitoring, etc, is available on specialist Linux distros if you want to try them. But if I can max my line, why waste time looking elsewhere? More worthwhile would be checking for transient local exchange congestion.

I apologise for getting technical, but so is torrenting:
Have you ever checked the behaviour of your router under huge numbers of connections? (conntrack, TTL, etc). It's a normal computer, and if it is reasonably recent, you really won't need to if you tightly control connections at the client. Have you monitored the traffic through your computer? Most important, think about the choking algorithm and how you handle it (see http://www.bittorrent.org/beps/bep_0003.html). Note the last half page, starting "Choking is done for several reasons". Eittenberger et al, 2011, put it this way:
The peer selection strategy is handled by the so called choking algorithm. To encourage peers to contribute their resources for the data dissemination, a tit-for-tat mechanism is implemented to impede free-riding, i.e. peers not contributing data to the network should not be able to achieve high download rates. Instead, this choking algorithm provides sharing incentives by rewarding peers who contribute data to the system. The algorithm determines the selection of peers to exchange data with. Peers that upload data at high rates are preferred. Once per choking period, usually every ten seconds, a peer evaluates the transmission rates from all the connected peers and selects a fixed number of the fastest ones, depending on its upload capacity. It will only upload data to these unchoked peers in this period. from other peers are denied in this period, i.e. those peers are choked. Another important part of the algorithm is the optimistic unchoking behavior: every 30 seconds one peer is randomly chosen and will be unchoked. This is meant to explore new peers with even higher upload capacities an as a side effect ensures data dissemination to low-capacity peers. Once a leecher has finished the download and enters the seeding state, it follows a different unchoke strategy. In most of the implementations peers in seed state unchoke peers with the highest download capacity to optimize the general dissemination performance of the network and to maintain high upload utilization.
Next consider the number of connections you open. TCP control does not behave optimally with excessive connections, which stress routers, and particularly wireless transmitters. For the least problems here, and to optimise the torrent algorithm, limit upload slots based on upload speed to make sure that each connected peer is getting a reasonable amount of bandwidth.

Some clients do a better default config than others - I have recommended Deluge previously for this reason. It has a comprehensive config GUI, which is easier than tracking down resource files.

jaybee
Posts: 14
Joined: Mon Dec 20, 2010 9:47 am
Location: Brisbane

Re: Slow as P2P

Post by jaybee » Fri Jun 08, 2012 1:14 pm

I tried Utorrent then Deluge last night but both gave about 270k download on the same list of torrents.

This morning, after a month of slowness, Utorrent was giving 450k on the same list. That is about as good as mine line will deliver.

Is there some factor other than the removal of the cache?

Diji1
Posts: 21
Joined: Mon Aug 11, 2008 2:48 am
Location: Adelaide

Re: Slow as P2P

Post by Diji1 » Fri Jun 08, 2012 2:50 pm

Dazzled wrote:Diji1, Exetel senior people have already posted that neither they nor AAPT are filtering torrent connections. Something has changed, and was widely publicised; namely the cache removal, that as a by-product can disguise some torrent problems.

My torrent result is above, done at home on Sunday afternoon immediately after your post came in. Let's keep testing restricted to the major software "public" torrents (Mint, Ubuntu, LibreOffice etc), because we can usually guarantee no difficulties with swarms or people trying to hide their behaviour. The only way I have been able to get terrible results on the major "public" software torrents has been to deliberately interfere with my router and ruin the torrent client configurations. I don't even have to fully optimise my system to get 800+ kB/s. My conclusion has been that people who are slow on these particular downloads probably need to attend to their computers.

I wouldn't run to conspiracy theories as I have read without doing some serious looking of my own. All the software for creating torrent packets, fancy route tracing, router and NIC monitoring, etc, is available on specialist Linux distros if you want to try them. But if I can max my line, why waste time looking elsewhere? More worthwhile would be checking for transient local exchange congestion.

I apologise for getting technical, but so is torrenting:
Have you ever checked the behaviour of your router under huge numbers of connections? (conntrack, TTL, etc). It's a normal computer, and if it is reasonably recent, you really won't need to if you tightly control connections at the client. Have you monitored the traffic through your computer? Most important, think about the choking algorithm and how you handle it (see http://www.bittorrent.org/beps/bep_0003.html). Note the last half page, starting "Choking is done for several reasons". Eittenberger et al, 2011, put it this way:
The peer selection strategy is handled by the so called choking algorithm. To encourage peers to contribute their resources for the data dissemination, a tit-for-tat mechanism is implemented to impede free-riding, i.e. peers not contributing data to the network should not be able to achieve high download rates. Instead, this choking algorithm provides sharing incentives by rewarding peers who contribute data to the system. The algorithm determines the selection of peers to exchange data with. Peers that upload data at high rates are preferred. Once per choking period, usually every ten seconds, a peer evaluates the transmission rates from all the connected peers and selects a fixed number of the fastest ones, depending on its upload capacity. It will only upload data to these unchoked peers in this period. from other peers are denied in this period, i.e. those peers are choked. Another important part of the algorithm is the optimistic unchoking behavior: every 30 seconds one peer is randomly chosen and will be unchoked. This is meant to explore new peers with even higher upload capacities an as a side effect ensures data dissemination to low-capacity peers. Once a leecher has finished the download and enters the seeding state, it follows a different unchoke strategy. In most of the implementations peers in seed state unchoke peers with the highest download capacity to optimize the general dissemination performance of the network and to maintain high upload utilization.
Next consider the number of connections you open. TCP control does not behave optimally with excessive connections, which stress routers, and particularly wireless transmitters. For the least problems here, and to optimise the torrent algorithm, limit upload slots based on upload speed to make sure that each connected peer is getting a reasonable amount of bandwidth.

Some clients do a better default config than others - I have recommended Deluge previously for this reason. It has a comprehensive config GUI, which is easier than tracking down resource files.
Maybe you missed what I said regarding the point that I have been using Bittorrent for many years.

But anyway to show my point if you're going to actually listen and not blame users: Here is uTorrent with default settings, nothing changed except disabling DHT and local Peer Discovery.

The settings were set through the speedtest using ~50% my actual upload speed instead of 80%~. Note the ratio of number of seeds as well as the seed to peer ration (20:1) and the high speed servers which I have helpfully highlighted for you in the attached image. I have stopped ALL torrents except the one you can see in the image - so 1 torrent.

Previously torrent from this this tracker and any other new torrent on a private tracker that I downloaded for that matter filled my entire connection to about ~500kB/s (~90% of my bandwidth). I repeat I have been torrenting for a long time and I know how to get files fast (basically download from private trackers with swarm restrictions leading to high SLR and user high speed servers if anyones interested). The speed here is stuck on 100kB/s and it's hardly changing. You might expect it to go up and down due to swarm conditions but NOPE. Gee, what does that behavior look like to you?

This not choking as evidenced by previous experience with a variety of trackers that have similar characteristics (high speed peers, high SLR) never being slow in the past and it is not settings since uTorrent (oh BTW I'm using v2.2.1 so it's not some change to uT) is quite conservative in its default settings and in any case I have made the settings more conservative. I have also not changed settings until right now in any case.

Furthermore choking leads to clients that upload more being preferred, it does not slow down client speeds if these clients have 100% of the file already.

And perhaps you'd like to explain the consistent sudden increase in speeds that happens every night at midnight as well. Does the Bittorrent protocol suddenly relax choking at this time and routers suddenly become able to handle connections? /Sarcasm

Understand that I've no doubt you're getting fine performance but a number of users are not including me. It annoys me that we're being told that it isn't Exetel's fault - just imagine for a second that it appears to not be the users fault to the user. What should I do here other than leave if Exetel is going to run this line then because it sure isn't going to get fixed?

EDIT: had to reupload pic to external host since I could seem to re-add it as an attachment:

Image

User avatar
Dazzled
Volunteer Site Admin
Posts: 6002
Joined: Mon Nov 13, 2006 1:16 pm
Location: Sydney

Re: Slow as P2P

Post by Dazzled » Fri Jun 08, 2012 5:13 pm

Thank you for the detailed information. I do accept that there are users with problems. I spoke to spoke to two friends on Exetel services about it, and neither were in trouble. I asked one to test default Deluge in Linux Mint for me, and an improvement was got over default μTorrent. I don't know why; the friend didn't check if μTorrent defaults are optimal.

I note that the example shown was quite unlike the sort of test usually recommended. It was a very large file, using a private tracker, with connections mainly in the USA, and with a lot of Comcast customers. Are they cable users subject to bursts? You are using μTorrent, and so are most of the other connections. Is this significant? Does Comcast still slow μtorrents? With a heavy dependence on one country, could you detect any particular slowdown on the undersea trip, or within the US? You can craft torrent packets if you have the right software.

Have you compared this result with one of the Mint/Ubuntu/Libre-Office torrents? DHT on as well as off? In my experience these can beat private trackers (perhaps I don't know a good enough one). Libre-Office will usually have a very fast local mirror server join. Have you monitored the speeds of the connections at any given time coming through your NIC?

My tests mentioned in this thread were done from an old Linux box that has had no application updates for 4 years. There are 5 out-of-date clients on it. There are no firewalls or malware suites, but it has optimal networking and router config. I have kept iftop running on the ethernet port, and occasionally traced back. Netstat was watching too. At one point I monitored the router conntrack data, but stopped when it was clear nothing was untoward. Were you able to try another OS than Windows? Unfortunately the live CD/DVD isos that contain a torrent client, usually Transmission, are full desktop distros, 700MB and up. Most of these can get monitoring tools from their repos and run them in RAM.

I have been running other torrent speed tests most days since this matter came up, on a moderate speed suburban ADSL2 line, and without crippling things, I cannot duplicate the severe speed problem people are writing about on any fast "public" torrent. Deluge with a GUI, and rTorrent in the terminal are much of a muchness. I used Bittornado a few times, but mostly Deluge. I've now got a downloaded distro collection I don't need. I can download obscure stuff and find it slow, but that comes from the limited nature of the swarm. If there is a speed shift at midnight, I haven't seen it at home. Is this a local matter? Indeed have users checked for local congestion with all these connections in play?

There's not much more I can do. James has already commented here. Would NetworkAdmin help?

conrad
Posts: 10
Joined: Mon Jul 23, 2007 9:41 am
Location: Central Coast, NSW

Re: Slow as P2P

Post by conrad » Fri Jun 22, 2012 11:09 am

I have a friend using the same private torrent tracker and I, we are both using uTorrent, we both live in the same suburb and both syncing at around the same (~13mbps) and we both have similar speed test results of around ~1.6mb/s. The only difference is that he is with Internode and I'm with Exetel. We did a test download of a torrent which had at least 3000 seeders and about 200 leechers, my friend downloaded the torrent at around 1.5mb/s, and I couldn't even hit 400kb/s.

I used to be able to max out my bandwidth and hit around 1.6mb/s using uTorrent and downloading from a private tracker. Lately, I can't hit any more than ~500kb/s.

Something has changed and it's frustrating. Kinda not worth being on such a large quota with these P2P speeds...

User avatar
Dazzled
Volunteer Site Admin
Posts: 6002
Joined: Mon Nov 13, 2006 1:16 pm
Location: Sydney

Re: Slow as P2P

Post by Dazzled » Fri Jun 22, 2012 1:52 pm

Did you use the same computer and modem? Otherwise there will be hardware and software differences. Was the test torrent one we can talk about here? A private tracker media file is not really a suitable test.

Try not using μTorrent; try not using Windows (or shut down malware software); try a known fast "public" torrent that's not so bound to the USA, such as the current Mint or Ubuntu; and for the moment ignore the private tracker. Get the client config and router at least near optimal.

To check the current state I have just finished downloading the Linux Mint "Mate" DVD once more - 890 kB/s (roughly line max), again using a superseded Deluge version on the slow machine - 4 fast servers quickly got on board, two in the US, ranging from 50 kB/s up to 300 kB/s and they did much of the total download. Some of these open source software torrents are served by the local aarnet mirror, and if you get it transmitting you really will fly. Torrents fed by fast servers rather than slow household connections demonstrate what can be achieved.

I'm just repeating myself; torrenting still works, but popular stuff is not cached.

conrad
Posts: 10
Joined: Mon Jul 23, 2007 9:41 am
Location: Central Coast, NSW

Re: Slow as P2P

Post by conrad » Fri Jun 22, 2012 2:15 pm

Yes, the torrent was from a private site so it may not be the same as a public release. It's a very suitable test if two completely different results are achieved from 2 different ISPs.

I've replaced my modem with a spare (different) modem to achieve the same results. I get this speed issue from 2 different computers on the network using either wireless or ethernet. There's nothing wrong with uTorrent, I get the same speeds using BitCommet, Vuze and BitTorrent. I get full speeds downloading via http and speed tests indicate no loss of bandwidth - a freshly imaged laptop with Windows 7 eliminates the possibility of malware.

Regardless of what speeds you may achieve with downloading public torrents, the facts are that my speeds are no longer what they used to be. Period.

chronographer
Posts: 31
Joined: Tue Nov 20, 2007 9:38 pm
Location: tasmania

Re: Slow as P2P

Post by chronographer » Sat Jul 21, 2012 8:22 pm

I just moved house, and I quietly hoped my troubles would go away. My situation is this:
1/ I use torrents for many things, and have done for years.
2/ I moved to a telstra wholesale ADSL2 connection a couple of years ago and it has been great
3/ until around 4 months ago, when it slowed down a huge amount...
4/ I have tested it, and I can get good speeds using Deluge, but not uTorrent, xTorrent and a few others.
5/ My media PC, an oldish macmini can not run Deluge (trust me, I tried... even had a go compiling it) and thus is stuck with <100 kbps speeds
6/ I am stuck with the decision to either a) use my NAS to download for me, which is not ideal b) get a new media centre PC, also not ideal c) change ISPs

I like Exetel, I elected to try them again. But like OP I am about to change. I only just moved, so I'm probably stuck for 6 months, but I want a fully functioning connection and so will likely wait the contract period out and move away from Exetel, after ~6 years of nice times.

If you want evidence of my poor connection, let me know what you want and I'll provide it. But trust my anecdotes, as I know what I'm talking about.

User avatar
Dazzled
Volunteer Site Admin
Posts: 6002
Joined: Mon Nov 13, 2006 1:16 pm
Location: Sydney

Re: Slow as P2P

Post by Dazzled » Sat Jul 21, 2012 10:02 pm

The default settings in Deluge are quite good, but it is hard to see why the same settings in μTorrent aren't getting much the same results, unless the packets are being noticed overseas.

Is the MacMini a PowerPC model, or later? Download one of the recent Ubuntu or Mint distros for the processor, install Deluge and run it in RAM from the live CD. (Transmission comes with a default Ubuntu, so perhaps try it also). If you have little RAM available, look at Lubuntu etc depending on processor.

I've been getting excellent results with superseded Deluge 0.5.8.9 in this thread, so you don't need the latest version. There are still a few precompiled distros/Deluges around even for PowerPC.

chronographer
Posts: 31
Joined: Tue Nov 20, 2007 9:38 pm
Location: tasmania

Re: Slow as P2P

Post by chronographer » Sun Jul 22, 2012 8:23 pm

Hi Dazzled

The macmini is a 1.8 Ghz intel dual core. But it can't run Lion, so must be an X86 only. Deluge has compiled binaries for only the latest OSX (this was a month ago I tried, but trust me, I'm an old Linux user... if the software could have been installed it WOULD have been!).

I have toyed with installing Ubuntu, and will do, but I'm now an OSX only house, and getting the ISO onto a USB has bewildered me (dd sounds hard and usually results in an unbootable stick). I'll have to find my DVD drive caddy and a blank disk (they're gathering dust) and burn 10.04 and give it a whirl. I didn't think of the live DVD method of testing, good idea. I'll give it a go.

Having said all that, my current download is coming down on the macmini at 499-500 kbps, which is about what I can get at my new house (speed tested to 8 mbps), so maybe the issue resolved itself overnight? unsure...

Post Reply