https://github.com/hexresearch/hxrpp

https://github.com/hexresearch/hxrpp

Last synced: 4 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/hexresearch/hxrpp
• Owner: hexresearch
• Created: 2017-10-04T06:49:19.000Z (over 7 years ago)
• Default Branch: master
• Last Pushed: 2017-10-05T11:07:54.000Z (over 7 years ago)
• Last Synced: 2025-01-09T03:56:51.439Z (5 months ago)
• Language: C
• Size: 89.8 KB
• Stars: 0
• Watchers: 13
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        

## 5-oct-2017

Попытка измерять пропускную  способность канала методом packet pairs ( примерно, как в pprate ).

Что видно на текущий момент:

Что хорошо:

 - Канал занимается очень слабо, и его использование не приводит к бану/отключению сетевого

   интерфейса на хостинге. Можно мерять с очень низкими издержками, мало серверов, маленький

   трафик, etc

 - В целом, похоже, что работает. Т.е на разных каналах величины сходятся к цифрам,

   которые соответствуют ширине канала с точностью до выплесков и некоторой 

   систематической погрешности, которые можно устранить.

 - Т.е правдоподобно меряется и ethernet и wifi на текущий момент   

Что плохо:

 - Судя по всему, в условиях, когда канал загружен не полностью,

   меряется максимальная пропускная способность канала **без шейпинга**.

   Более того, шейпинг, *видимо* работает так, что какие-то существенные

   задержки в *packet inter-arrival time intervals* начинают вноситься только

   тогда, когда загрузка канала приближается к максимальной.

   Следовательно, методика меряет физическую пропускную способность

   провода Ethernet, который воткнут в роутер, но не то, насколько

   этот канал зашейплен.

   По крайней мере, на текущий момент ситуация выглядит так, т.е

   если эта гипотеза верна, то даже улучшение точности таймстемпов

   пакетов никак не поможет.

Например, вот гистограмма с шагом 10 мегабит на канале 100 мегабит,

зашейпленном на 80 мегабит у провайдера:

	10 1486   # выплеск, интервалы между двойками пакетов

	20 5

	30 25

	40 6

	50 1

	70 28

	80 80        #

	90 186       # <- куда-то сюда мы должны были попасть

	100 271      # <-- вот это вот всё, что ниже --- объясняется

	110 293      # тем, что времена прибытия пакетов меряется не на роутере,

	120 182      # где канал 100mbit, а на точке за роутером, где 1000mbit,

	130 67       # а пакеты в роутере каким-то образом буферизуются и

	140 41       # интервалы между ними не сохраняются

	150 27       # т.е **в теории**, если мерять непосредственно на роутере

	160 15       # и иметь точные таймстемпы пакетов --- всё может стать

	170 8        # несколько лучше.

	180 7

	190 4

	200 10

	210 4

	220 8

	230 9

	240 4

	250 2

	260 6

	270 16

	280 13

	290 14

	300 13

	310 6

	320 4

	330 4

	340 5

	360 1

	370 3

	380 1

	390 2

	400 3

	410 2

	420 3

	430 4

	440 7

	450 3

	460 9

	470 4

	480 2

	490 26

	500 16

	510 18

	520 7

	530 3

	540 4

	550 2

	660 1

	960 1