neza4to Опубликовано 2 июля, 2009 · Жалоба Тогда я склоняюсь к 1 своему посту ( имею ввиду Точки 2100 и антены парабалик 24... буду пробывать :)))) а за топиком буду смотреть) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tatuchipapa Опубликовано 2 июля, 2009 (изменено) · Жалоба За последние 2-3 месяца было создано около десятка похожих тем - хочу быстро и дёшево, или хочу просто и чтоб работало. Думаю было бы неплохо создать что-то типа тест раздела, понравилось наподобие тут http://forums.overclockers.ru/viewtopic.php?t=157255 Например 2100АР(1км-10км) и всё по ней, какие расстояния работают, параметры настройки, прошивка, стоимость. Тему прикрепить и начинающие не будут отвлекать простыми вопросами. Идею можно развить. Изменено 2 июля, 2009 пользователем tatuchipapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MaXToP Опубликовано 2 июля, 2009 · Жалоба Черновичок фака по "пионерскому" вайфаю покритикуй есть уже такая тема и что ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fastvd Опубликовано 2 июля, 2009 · Жалоба можно..но тогда модератору форума нужно какойто спецовый раздел сделать для тестов, и чтобы там только тести и ничего кроме тестов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 2 июля, 2009 · Жалоба Микротик будет там же где и ББ, я вас уверяю. А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k? Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду. Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно. Неплохо бы знать азы. Даже в пионернетах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fastvd Опубликовано 2 июля, 2009 (изменено) · Жалоба Микротик будет там же где и ББ, я вас уверяю. А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k? Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду. Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно. Неплохо бы знать азы. Даже в пионернетах. sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика... Изменено 2 июля, 2009 пользователем fastvd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SSD Опубликовано 2 июля, 2009 · Жалоба Микротик будет там же где и ББ, я вас уверяю. А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k? Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду. Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно. Неплохо бы знать азы. Даже в пионернетах. sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика... А где показанно что ппс 80К? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rsst Опубликовано 2 июля, 2009 (изменено) · Жалоба А где показанно что ппс 80К? http://babai.net.ua/clipboard01.jpg Линк, 2 км. Микротик 2.9.27, карточки тп-линк, турборежим. Изменено 2 июля, 2009 пользователем rsst Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rsst Опубликовано 2 июля, 2009 · Жалоба Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно. Неплохо бы знать азы. Даже в пионернетах. простая арифметика показывает, что размер пакета при такой скорости и таком pps приблизительно равен среднему размеру пакета в FastEthernet сетях, что никак не может быть малореальным и теоретическим. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
X0t@bych Опубликовано 3 июля, 2009 · Жалоба sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика...+100абсолютно верно, у меня в таком же режиме реальные 52мбит прокачивает Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду. Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно. Неплохо бы знать азы. Даже в пионернетах. 80k pps, это не показатель пропускной способности линка, вполне можно его превысить и на 36мбит при интерактивном трафе (войс, видео и т.п.). Тут уже будет стоять проблема не в ширине канала, а в мощности роутеров и модемов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 3 июля, 2009 · Жалоба А где показанно что ппс 80К? http://babai.net.ua/clipboard01.jpg Линк, 2 км. Микротик 2.9.27, карточки тп-линк, турборежим. Это ТХ, значит должен быть еще график потерь. на TX можно нарисовать все что угодно! Надо подключать проверенный анализатор пакетов и слушать RX удаленного конца, тогда наступит великое просветление. Микротик будет там же где и ББ, я вас уверяю. А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k? Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду. Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно. Неплохо бы знать азы. Даже в пионернетах. sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика... Молодой челоовек, а вам вобще еще рано эзернетом заниматься. Вам нужно заниматься теоретическими основами начала эзернет и IP. Например узнать что пакеты и байты не одно и тоже. Узнать что файл трансфер идет по протоколу TCP, узнать что TCP старается передавать данные пакетиками по 1500 байт, а не по 2 байта. Короче больше усердия и все придет. И поменьше слов "вы не правы" в тех предметах, в которых не бум бум. 80k pps, это не показатель пропускной способности линка, вполне можно его превысить и на 36мбит при интерактивном трафе (войс, видео и т.п.). Тут уже будет стоять проблема не в ширине канала, а в мощности роутеров и модемов. Синус в военное время может достигать 3 или даже 5. Ужос! Пионеры опровергли арифметику! Не пойму это радиоизлучение или десятелетия реформ так разжижили мозх? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
woddy Опубликовано 3 июля, 2009 · Жалоба спорим тут, а потом окажется топистартер ставит линк себе на дачу чтоб вконтакте читать и в аське сидеть :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
R_cyberax Опубликовано 3 июля, 2009 · Жалоба 2rsst: что у вас там за ужос летит ? :) вот кусочег лога с моста между достаточно крупными сетями: Load Meter 1.3 All results in Mbits per second I N P U T O U T P U T SUM PACKETS Name cur avg max packets cur avg max packets eth0 59 59 59 9097 63 63 63 8977 122 18074 eth0 54 57 59 7949 53 58 63 7700 107 15649 eth0 59 57 59 8346 56 57 63 7994 115 16340 eth0 60 58 60 8801 57 57 63 8493 117 17294 При этом как вы сами видете трафика по 60Мбит FD, летает п2п, видео и остального чучут :) Правда камешек 75-80% нагружен... Вероятно что стоило бы взглянуть сниферу в лицо и понять что у вас там летит, не для проверки кол-ва а именно для изучения... 2woddy: спорим тут, а потом окажется топистартер ставит линк себе на дачу чтоб вконтакте читать и в аське сидеть :)А сюда другие заходют ? ;) остальные разбежались от грозных речей тов.Sonne. З.Ы. неудержусь и вставлю :) ...наверно имелось ввиду что фаил-трансфер(прикл.по) используя tcp or udp идёт поверх ip, т.е. он может идти разными способами ;) А уже tcp в свою очередь договаривается о размере пакета исходя из размеров окна между хостами и потолка mtu, это может быть как 1500байт так и 50байт, что в свою очередь влёчет изменение кол-ва p/s... imho gl Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
itl2044 Опубликовано 3 июля, 2009 · Жалоба Показаные картинки - не более, чем микротиковский тест скорости. Для примера: RAR сможет сжать ПУСТОЙ BMP файл с исходным размером 340 мегабайт до 250 килобайт, но в то же время JPG размером 340 мегабайт сожмет до 350 мегабайт. Если через микротик пустить РЕАЛЬНЫЙ трафик, то pps сразу упадет до 4к. Все очень просто, и чудес, как мы все прекрасно знаем - на свете не бывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 июля, 2009 · Жалоба На Микротике через wireless действительно можно 80kpps в ТЕОРИИ и смотря "как мерять". Только на самом на wireless 80kpps конечно не будет. У MT есть "ip packing" и сам nstreme может допаковывать пакеты в один большой фрейм (до 4000 байт). Ну и сжатие конечно, но в данном случае мы его не учитываем. Пример: 15:35:58.348522 00:13:72:f8:73:ac > 00:06:39:01:0f:53, ethertype IPv4 (0x0800), length 50: (tos 0x0, ttl 113, id 62711, offset 0, flags [none], proto UDP (17), length 36) 81.28.119.197.3432 > X.X.152.82.38111: [udp sum ok] UDP, length 8 Т.е. если даже учесть, что payload 8 byte, с IP/UDP заголовками 36 байт, с Ethernet оверхед 50 байт, плюс минимальный размер Ethernet пакета - 64 байт, т.е. оно будет padded до 64 байт (между FCS и данными). Т.е. по сути к нам на Ethernet приходит 70Mbps/136Kpps таких пакетов, payload там только 36 байт, которые и будут переданы по wireless, и соответственно на самом деле data rate через этот "роутер", если вычесть ethernet overhead и padding будет лишь 39.375 Mbit/s. Если это P2P линк, то при максимальном размере "упихивания" до 4000 байт + скажем заголовок с длиной на каждую структуру (где хранится пакет) в 32 бита(итого 40) и общий overhead для nstreme (от балды) скажем 20 байт, выходит в один nstreme пакет мы можем затолкать ~99 пакетов. Если траффик односторонний (nstreme dual), то реальная пропускная способность на 40 Mhz (Turbo) может достигать 70 Mbps полезных данных (реальный опыт). Это около 2187 pps с 4000 байт nstreme пакетами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rsst Опубликовано 3 июля, 2009 · Жалоба А где показанно что ппс 80К? http://babai.net.ua/clipboard01.jpg Линк, 2 км. Микротик 2.9.27, карточки тп-линк, турборежим. Это ТХ, значит должен быть еще график потерь. на TX можно нарисовать все что угодно! Надо подключать проверенный анализатор пакетов и слушать RX удаленного конца, тогда наступит великое просветление. Все с вами понятно. Вы из тех людей, которым доказать что-то реально невозможно. Вам даже в реале покажи, вы скажете, что "такого не может быть потому, что не может быть никогда". Ужос! Пионеры опровергли арифметику!Не пойму это радиоизлучение или десятелетия реформ так разжижили мозх? Я искринне рад за вас, что вы вышли из пионерского "возраста". Показаные картинки - не более, чем микротиковский тест скорости.Для примера: RAR сможет сжать ПУСТОЙ BMP файл с исходным размером 340 мегабайт до 250 килобайт, но в то же время JPG размером 340 мегабайт сожмет до 350 мегабайт. Если через микротик пустить РЕАЛЬНЫЙ трафик, то pps сразу упадет до 4к. Все очень просто, и чудес, как мы все прекрасно знаем - на свете не бывает. Да, это микротиковский тест скорости. Но это не значит, что в канале используется сжатие. ps: itl2044, ну ведь не тяжело проехать 10-15км и посмотреть на это дело у меня в реале :) На Микротике через wireless действительно можно 80kpps в ТЕОРИИ и смотря "как мерять". Только на самом на wireless 80kpps конечно не будет.У MT есть "ip packing" и сам nstreme может допаковывать пакеты в один большой фрейм (до 4000 байт). Ну и сжатие конечно, но в данном случае мы его не учитываем. Как раз нстрим и помогает делать нам свое черное дело. Фича в том, что пакинг мелких пакетов для юзера прозрачен и производится на уровне протокола, что не мешает мне говорить о пропускной способности канала (pps). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cadmi Опубликовано 4 июля, 2009 · Жалоба а почему на скриншоте http://forum.nag.ru/forum/index.php?act=at...ost&id=2647 "беспроводное подключение используется на 0%" и в статусе у него "не работает" ? там что, фильм по 100 мегабит ethernet'у качается? тогда 5 мегабайт в секунду это даже маловато как-то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fastvd Опубликовано 4 июля, 2009 · Жалоба а почему на скриншоте http://forum.nag.ru/forum/index.php?act=at...ost&id=2647 "беспроводное подключение используется на 0%" и в статусе у него "не работает" ? там что, фильм по 100 мегабит ethernet'у качается? тогда 5 мегабайт в секунду это даже маловато как-то. я к тику кабелм подключён-эт же мост на 5 ггц - что тут не ясного? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 5 июля, 2009 · Жалоба Как раз нстрим и помогает делать нам свое черное дело. Фича в том, что пакинг мелких пакетов для юзера прозрачен и производится на уровне протокола, что не мешает мне говорить о пропускной способности канала (pps). Мешает. Термин канал имеет вполне опредленное значение, так же как и канальный уровень. В модели OSI канальный уровень отвечает за передачу уже сформированых фреймов (кадров). А сжатие данных пррисходит намного выше. Т.е. показывая тесты копрессии нельзя называть это скоростью передачи канала. И, кстати, любая упаковка подразумевает наличие буфера вносящего задержку. Т.е. выигрываешь в скорсти - проигрываешь в задержке и не факт что такая передача данных нужна. Никаких претензий не было если бы вы написали про алгоритм работы сжатия микротика, не связывая его с работой физики wi-fi. Но походу вы сами не знали об этом пока специалист не объяснил. А где показанно что ппс 80К? http://babai.net.ua/clipboard01.jpg Линк, 2 км. Микротик 2.9.27, карточки тп-линк, турборежим. Это ТХ, значит должен быть еще график потерь. на TX можно нарисовать все что угодно! Надо подключать проверенный анализатор пакетов и слушать RX удаленного конца, тогда наступит великое просветление. Все с вами понятно. Вы из тех людей, которым доказать что-то реально невозможно. Вам даже в реале покажи, вы скажете, что "такого не может быть потому, что не может быть никогда". Я из тех людей которые немного дружат с арифметикой и физикой. Помните про бассейн "в одну трубу втекает, в другую трубу вытекает". Впрочем признаю свою принадлежность к вымирающий подвиду людей в этой стране. А вы, очевидно, из тех людей, для которых крутят по телеку рекламные клипы "вдвое больше вкуса" и "еще больше скорости". Именно это и есть критерии вашего выбора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 5 июля, 2009 · Жалоба Sonne - у меня до определенного времени бегало 70 Mbit/s через микротик. Реального траффика. Когда количество линков доросло до 5-и - поставили два Trango на 315 Mbps, т.к. слишком много частотной полосы на 5 Ггц выжирало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 6 июля, 2009 · Жалоба Sonne - у меня до определенного времени бегало 70 Mbit/s через микротик. Реального траффика. Когда количество линков доросло до 5-и - поставили два Trango на 315 Mbps, т.к. слишком много частотной полосы на 5 Ггц выжирало. Мы говорим не про мегабиты, мы про количество пакетов в этих мегабитах и про методику этих измерений. Если мерить поток на выходе эзернета удаленного конца, то количество пактеов не может быть больше физической возможности пропихнуть. Если мерить поток на входах-выходах радиоинтерфейса при включенном сжатии, то за счет склейки из этих десятков тысяч пакетов в реальной передаче идет в десятки раз меньше пакетов. Просто пакетная производительность радио устройств это очень важная величина, она по определению всегда ниже чистого эзернета, за счет особенностей протокола. Это должен понимать любой кто строит радиосеть. А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости. Я считаю что правила типа 2 x 2 = 4 полезно знать в всем, чтобы в магазине за 2 сникерса по 20 рублей не отдавать 60 хитрому продавцу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rsst Опубликовано 6 июля, 2009 · Жалоба Как раз нстрим и помогает делать нам свое черное дело. Фича в том, что пакинг мелких пакетов для юзера прозрачен и производится на уровне протокола, что не мешает мне говорить о пропускной способности канала (pps). Никаких претензий не было если бы вы написали про алгоритм работы сжатия микротика, не связывая его с работой физики wi-fi. Но походу вы сами не знали об этом пока специалист не объяснил. Конечно же когда-то я об этом не знал :) Но вот, похоже, как раз вы об этом узнали совсем недавно (насколько постов назад), чего, почему-то, не хотите признавать. Впрочем у меня к вам каких-либо претензий не возникает по этому поводу. А вы, очевидно, из тех людей, для которых крутят по телеку рекламные клипы "вдвое больше вкуса" и "еще больше скорости". Именно это и есть критерии вашего выбора.Да, именно из тех.... с учетом того, что телевидение я не смотрю уже лет 8 :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rsst Опубликовано 6 июля, 2009 · Жалоба А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости. Микротиковский склейщик оптимизирован под склейку пакетов и не более того, без привязки к какому-либо приложению. Вот вы же спорите об этом даже не удосужившись хоть немного вникнуть в алгоритмы работы того же nstreme протокола, хотя бы просто почитав что-то по этому поводу. ps: Кстати, похоже вам это не известно, rar упаковывает без последующей потери информации при распаковке, а вот jpeg компрессия подразумевает оную. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 6 июля, 2009 · Жалоба А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости. Я считаю что правила типа 2 x 2 = 4 полезно знать в всем, чтобы в магазине за 2 сникерса по 20 рублей не отдавать 60 хитрому продавцу. Не путайте сжатие со склейкой. Микротик склеивает маленькие пакеты в большие. Т.е. скажем при average packet 500 byte (а в локалках и того меньше бывает), и максимальном куске 4000 byte - это четырехкратное увеличение pps. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 6 июля, 2009 · Жалоба А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости. Я считаю что правила типа 2 x 2 = 4 полезно знать в всем, чтобы в магазине за 2 сникерса по 20 рублей не отдавать 60 хитрому продавцу. Не путайте сжатие со склейкой. Микротик склеивает маленькие пакеты в большие. Т.е. скажем при average packet 500 byte (а в локалках и того меньше бывает), и максимальном куске 4000 byte - это четырехкратное увеличение pps. Склейка это процесс объединения пакетов, т.е. размер не меняется, даже добавляется немного клея. Сжатие это процесс при котором размер меняется за счет модификации данных (в данном случае вырезание заголовков), т.е. чисто терминологически то что вы называете склейкой является именно сжатием. Если не согласны - то определение "склейки" и "сжатия" с акцентом на их именно отличие. И, опять же, я говорил что любое сжатие создает delay из-за наличия буфера, что приводит к увеличению задержки. Retry скленого пакета приведет к замено большему джитеру. В вашем примере с пакетами в 500 байт сэкономить от "склейки таких пакетов" мы можем всего 3 заголовка, т.е. примерно 20*3/4000 ~ 1,5 % За эту экономию платим 4 кратным увличением джитера и постоянной задержкой. На обычном трафике ограничение pps не возникает, а экономии полосы нет. Единственный случай заметной экономии это либо поток чистых воипных пакетов, либо чистый флуд от синтетического теста, т.е. ситуаций которые оторваны от реальности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...