changed semantics of send_buffer_watermark_factor to be specified as a percentage

This commit is contained in:
Arvid Norberg 2011-09-23 21:12:28 +00:00
parent 85db40e2c5
commit 451c31828f
5 changed files with 18 additions and 14 deletions

View File

@ -1,3 +1,4 @@
* changed semantics of send_buffer_watermark_factor to be specified as a percentage
* add incoming_connection_alert for logging all successful incoming connections
* feature to encrypt peer connections with a secret AES-256 key stored in .torrent file
* deprecated compact storage allocation

View File

@ -4697,10 +4697,12 @@ memory will be wasted. The actual watermark may be lower than this in case
the upload rate is low, this is the upper limit.
``send_buffer_watermark_factor`` is multiplied to the peer's upload rate
to determine the low-watermark for the peer. This is clamped to not
exceed the ``send_buffer_watermark`` upper limit. This defaults to 1.
For high capacity connections, setting this higher can improve upload
performance and disk throughput.
to determine the low-watermark for the peer. It is specified as a percentage,
which means 100 represents a factor of 1.
The low-watermark is still clamped to not exceed the ``send_buffer_watermark``
upper limit. This defaults to 50. For high capacity connections, setting this
higher can improve upload performance and disk throughput. Setting it too
high may waste RAM and create a bias towards read jobs over write jobs.
``auto_upload_slots`` defaults to true. When true, if there is a global upload
limit set and the current upload rate is less than 90% of that, another upload
@ -6950,7 +6952,7 @@ send_buffer_watermark_too_low
The number of bytes that we keep outstanding, requested from the disk, is calculated
as follows::
min(512, max(upload_rate * send_buffer_watermark_factor, send_buffer_watermark))
min(512, max(upload_rate * send_buffer_watermark_factor / 100, send_buffer_watermark))
If you receive this alert, you migth want to either increase your ``send_buffer_watermark``
or ``send_buffer_watermark_factor``.

View File

@ -136,8 +136,8 @@ namespace libtorrent
#endif
, free_torrent_hashes(true)
, upnp_ignore_nonrouters(false)
, send_buffer_watermark(700 * 1024)
, send_buffer_watermark_factor(1)
, send_buffer_watermark(500 * 1024)
, send_buffer_watermark_factor(50)
#ifndef TORRENT_NO_DEPRECATE
// deprecated in 0.16
, auto_upload_slots(true)
@ -486,11 +486,12 @@ namespace libtorrent
int send_buffer_watermark;
// the current upload rate to a peer is multiplied by
// this factor to get the send buffer watermark. This
// product is clamped to the send_buffer_watermark
// this factor to get the send buffer watermark. The
// factor is specified as a percentage. i.e. 50 -> 0.5
// This product is clamped to the send_buffer_watermark
// setting to not exceed the max. For high speed
// upload, this should be set to a greater value than
// 1. The default is 1.
// 100. The default is 50.
int send_buffer_watermark_factor;
#ifndef TORRENT_NO_DEPRECATE

View File

@ -4354,7 +4354,7 @@ namespace libtorrent
int upload_rate = int(m_statistics.upload_rate());
int buffer_size_watermark = upload_rate
* m_ses.settings().send_buffer_watermark_factor;
* m_ses.settings().send_buffer_watermark_factor / 100;
if (buffer_size_watermark < 512) buffer_size_watermark = 512;
else if (buffer_size_watermark > m_ses.settings().send_buffer_watermark)

View File

@ -274,12 +274,12 @@ namespace libtorrent
// the bandwidth delay product. Assuming an RTT
// of 500 ms, and a send rate of 20 MB/s, the upper
// limit should be 10 MB
set.send_buffer_watermark = 10 * 1024 * 1024;
set.send_buffer_watermark = 2 * 1024 * 1024;
// put 10 seconds worth of data in the send buffer
// put 1.5 seconds worth of data in the send buffer
// this gives the disk I/O more heads-up on disk
// reads, and can maximize throughput
set.send_buffer_watermark_factor = 10;
set.send_buffer_watermark_factor = 150;
// don't retry peers if they fail once. Let them
// connect to us if they want to