Download Performance

The prime performance criteria of a P2P client is the speed at which files are downloaded. This area of Tribler research specifically examines the source code to improve downloading.

Several other research topics are linked to this activity. All the research topics below relate to the Tribler download core. It is imperative that these efforts are not hindered.

• We will conduct several more years of P2P research with Tribler. The flexibility of the source code is a prime concern. Radical architectural enhancements for the long-term are pursued. Thus it is required that modifications remain easy to make. For example, full incentives for all 8 file sharing activities. This creates tension with efficiency, as Python is easy to modify, but slower then pure C code. In a few months we will even remove the tit-for-tat and unchoke algorithm when two Tribler peers exchange bytes. Instead we will keep accurate accounts of exchanged bytes and global sharing ratios between Tribler peers.
• HTML-page size scalability. We are scaling the Bittorrent protocol for KBytes sized files, meaning it can be used for static-page P2P webhosting.
• Fairness. Replacement of the superseeding algorithm with something superior.
• Donating upload to friends. The Tribler core is the only Bittorrent-compatible client which supports this feature.

"Currently Tribler 4.0 is a Bittorrent client with a secure foundation and pretty interface. However, the download speed leaves something to be desired and needs to be improved. "

Long-term Objective

Objective: Speed testing confirms that Tribler is now the fastest or a fast Bittorrent client :-) With the noted exception of ​clients whom are parasitic.

Project 2 ideas

The aim of this project is to create an extensive testing suite for Bittorrent clients. At this point we have created a scripted environment that measures the performance of several bittorrent clients within the same swarm.

The Bittorrent clients that we've been testing are:

• Bittorent Mainline Client
• Bittornado
• Transmission
• Aria2
• Azureus
• Tribler

The environment setup is:

• 6 PCs each running a different client
• all clients run in the same swarm but with little interraction
• a huge swarm
• a large file (a DVD or HD movie)

We measure:

• the evolution of the download speed for each particular client
• download time
• other aspects based on logging information for each client

In order to achieve important results it is important to test a plethora of situations. Based on the above results we can draw conclusions and find out which facilities end up as the most important ones from a performace evaluator's point of view.

Key performance indicators?

• peer discovery efficiency
• piece request management
• unchoke strategy
• connection management

Stay tuned for more information.

Project 1 results

• 2007-05-04 Initial Project Planning
• 2007-05-04 Measurement Plan
• 2007-05-11 Added logging abilities to BT clients.
• 2007-05-27 Performance Measuring of Azureus, Tribler and Mainline.
• 2007-05-27 Analysis Download Algorithms

Phase 1 in progress:

• Designing Measurement Tool (10%) (mentioned in Design Phase in Revised Project Planning)
• Implementing Measurement Tool (0%)

Measurements graph

Plot using the collected log files the following properties in time.

• Peer discovery (tracker, DHT, PEX)
• Tryout of peers (cumulative optimistic unchoke)
• Usefullness of peers (total download bandwidth)

This provides insight in the:

• peer discovery aggressiveness (tracker interval)
• optimistic unchoke strategy
• relative total P2P performance

Direction of conclusions :

• Smartness of each client
  • Unchoke: random, round robin, etc.
  • Piece picking
    • Endgame
    • First piece
  • Neighborhood health / peer discovery (DHT, PEX)
  • Azureus extra control messages, comments, DHT, and added value
  • Record and ban client with protocol violations or bad hashes
  • Others ? ?
• Efficiency ranking of clients
• Best generic algorithms

Application graphs

• Tribler ​png ​svg ​Postscript
• Mainline bittorrent ​png ​svg ​Postscript
• Azureus ​png ​svg ​Postscript
• Azureus without DHT ​png ​svg ​Postscript

Property graphs

• Unique unchokes, unchokes and chokes ​png ​svg ​Postscript
• Unique unchokes ​png ​svg ​Postscript
• Unchokes ​png ​svg ​Postscript
• Chokes ​png ​svg ​Postscript
• Download progress ​png ​svg ​Postscript
• Peers found via the tracker, buddycast or DHT ​png ​svg ​Postscript
• Total peers found ​png ​svg ​Postscript
• Peers found via Buddycast/DHT ​png ​svg ​Postscript
• Peers found via a tracker ​png ​svg ​Postscript

x-axis in seconds