История изменений

После тщательной проверки можно сказать, что проблема скорее всего не в libtorrent-rasterbar (это было бы странно), а в самом интерфейсе qBittorent. Он просто выдает цифры от балды, не смотря на жестко прописанное [5 мбит/с] на его же нижней панели.

Вот смтри: допустим, у тебя есть некая программа, отправляющая данные через сокеты. В ней можно выставить ограничение скорости. Ты выставляешь ограничение в 16 кбит/час.

Далее программа делает вызов send() и передаёт в него буфер длиной 16 кбит. Если у тебя комп подключен гигабитным кабелем и до получателя тоже везде гигабит, то эти 16 кбит улетают со скоростью 1 гбит/сек. Именно такая будет скорость отправки.

Но так как программа будет вызывать send() ровно раз в час, то твоё ограничение скорости будет выдерживаться. Просто чтобы его увидеть, надо реже делать замеры количества отправленных данных (раз в час или более), или усреднять частые замеры скорости по более длительным периодам (час и более).

Торрент клиент работет не точно так, но очень похожим образом. Сетевой стек в ОС и сетевое железо не может давать произвольную скорость только лишь по твоим хотелкам, там везде есть буферы, очереди, фиксированный битрейт и так далее. Регулировать скорость отправки из одного приложения юзерспейса можно только так - дозируя отправляемые данные, чтобы в среднем, примерно получалась заданная скорость.

Так что проблема qbittorrent или libtorrent-rasterbar видимо в том, что в них неправильно замеряется или считается собственная скорость. Если считаешь, что это так, то создай issue у них в багтрекере. Ссылку кинули выше. И, соотвественно, другие программы измерения скорости передачи данных всё ещё могут показывать пики, вылезающие за твоё ограничение, из-за большей частоты измерения.

После тщательной проверки можно сказать, что проблема скорее всего не в libtorrent-rasterbar (это было бы странно), а в самом интерфейсе qBittorent. Он просто выдает цифры от балды, не смотря на жестко прописанное [5 мбит/с] на его же нижней панели.

Вот смтри: допустим, у тебя есть некая программа, отправляющая данные через сокеты. В ней можно выставить ограничение скорости. Ты выставляешь ограничение в 16 кбит/час.

Далее программа делает вызов send() и передаёт в него буфер длиной 16 кбит. Если у тебя комп подключен гигабитным кабелем и до получателя тоже везде гигабит, то эти 16 кбит улетают со скоростью 1 гбит/сек. Именно такая будет скорость отправки.

Но так как программа будет вызывать send() ровно раз в час, то твоё ограничение скорости будет выдерживаться. Просто чтобы его увидеть, надо реже делать замеры количества отправленных данных (раз в час или более), или усреднять частые замеры скорости по более длительным периодам (час и более).

Торрент клиент работет не точно так, но очень похожим образом. Сетевой стек в ОС и сетевое железо не может давать произвольную скорость только лишь по твоим хотелкам, там везде есть буферы, очереди, фиксированный битрейт и так далее. Регулировать скорость отправки из одного приложения юзерспейса можно только так - дозируя отправляемые данные, чтобы в среднем, примерно получалась заданная скорость.

Так что проблема qbittorrent или libtorrent-rasterbar видимо в том, что в них неправильно замеряется или считается собственная скорость. Если считаешь, что это так, то создай issue у них в багтрекере. Ссылку кинули выше. И, соотвественно, другие программы измерения скорости передачи данных, всё ещё могут показывать пики, вылезающие за твоё ограничение, из-за большей частоты измерения.

После тщательной проверки можно сказать, что проблема скорее всего не в libtorrent-rasterbar (это было бы странно), а в самом интерфейсе qBittorent. Он просто выдает цифры от балды, не смотря на жестко прописанное [5 мбит/с] на его же нижней панели.

Вот смтри: допустим, у тебя есть некая программа, отправляющая данные через сокеты. В ней можно выставить ограничение скорости. Ты выставляешь ограничение в 16 кбит/час.

Далее программа делает вызов send() и передаёт в него буфер длиной 16 кбит. Если у тебя комп подключен гигабитным кабелем и до получателя тоже везде гигабит, то эти 16 кбит улетают со скоростью 1 гбит/сек. Именно такая будет скорость отправки.

Но так как программа будет вызывать send() ровно раз в час, то твоё ограничение скорости будет выдерживаться. Просто чтобы его увидеть, надо реже делать замеры количества отправленных данных (раз в час или более), или усреднять частые замеры скорости по более длительным периодам (час и более).

Торрент клиент работет не точно так, но очень похожим образом. Сетевой стек в ОС и сетевое железо не может давать произвольную скорость только лишь по твоим хотелкам, там везде есть буферы, очереди, фиксированный битрейт и так далее. Регулировать скорость отправки из одного приложения юзерспейса можно только так - дозируя отправляемые данные, чтобы в среднем, примерно получалась заданная скорость.

Так что проблема qbittorrent или libtorrent-rasterbar видимо в том, что в них неправильно замеряется или считается собственная скорость. Если считаешь, что это так, то создай issue у них в багтрекере. Ссылку кинули выше.

После тщательной проверки можно сказать, что проблема скорее всего не в libtorrent-rasterbar (это было бы странно), а в самом интерфейсе qBittorent. Он просто выдает цифры от балды, не смотря на жестко прописанное [5 мбит/с] на его же нижней панели.

Вот смтри: допустим, у тебя есть некая программа, отправляющая данные через сокеты. В ней можно выставить ограничение скорости. Ты выставляешь ограничение в 16 кбит/час.

Далее программа делает вызов send() и передаёт в него буфер длиной 16 кбит. Если у тебя комп подключен гигабитным кабелем и до получателя тоже везде гигабит, то эти 16 кбит улетают со скоростью 1 гбит/сек. Именно такая будет скорость отправки.

Но так как программа будет вызывать send() ровно раз в час, то твоё ограничение скорости будет выдерживаться. Просто чтобы его увидеть, надо реже делать замеры количества отправленных данных (раз в час или более), или усреднять частые замеры скорости по более длительным периодам (час и более).

Торрент клиент работет не точно так, но очень похожим образом. Сетевой стек в ОС и сетевое железо не может давать произвольную скорость только лишь по твоим хотелкам, там везде есть буферы, очереди, фиксированный битрейт и так далее. Регулировать скорость отправки из одного приложения юзерспейса можно только так - дозируя отправляемые данные, чтобы в среднем получалась заданная скорость.

Так что проблема qbittorrent или libtorrent-rasterbar видимо в том, что в них неправильно замеряется или считается собственная скорость. Если считаешь, что это так, то создай issue у них в багтрекере. Ссылку кинули выше.

После тщательной проверки можно сказать, что проблема скорее всего не в libtorrent-rasterbar (это было бы странно), а в самом интерфейсе qBittorent. Он просто выдает цифры от балды, не смотря на жестко прописанное [5 мбит/с] на его же нижней панели.

Вот смтри: допустим, у тебя есть некая программа, отправляющая данные через сокеты. В ней можно выставить ограничение скорости. Ты выставляешь ограничение в 16 кбит/час.

Далее программа делает вызов send() и передаёт в него буфер длиной 16 кбит. Если у тебя комп подключен гигабитным кабелем и до получателя тоже везде гигабит, то эти 16 кбит улетают со скоростью 1 гбит/сек. Именно такая будет скорость отправки.

Но так как программа будет вызывать send() ровно раз в час, то твоё ограничение скорости будет выдерживаться. Просто чтобы его увидеть, надо реже делать замеры количества отправленных данных (раз в час или более), или усреднять частые замеры скорости по более длительным периодам (час и более).

Торрент клиент работет не точно так, но очень похожим образом. Сетевой стек в ОС и сетевое железо не может давать произвольную скорость только лишь по твоим хотелкам, там везде есть буферы, очереди, фиксированный битрейт и так далее. Регулировать скорость отправки из одного приложения юзерспейса можно только так - дозируя отправляемые данные, чтобы в среднем получалась заданная скорость.

Так что проблема qbittorrent или libtorrent-rasterbar видимо в том, что в них неправильно замеряется или считается собственная скорость.