Jump to content
Калькуляторы

1км хотябы 5-10 мБит стабильности

Тогда я склоняюсь к 1 своему посту ( имею ввиду Точки 2100 и антены парабалик 24...

 

буду пробывать :)))) а за топиком буду смотреть)

Share this post


Link to post
Share on other sites

За последние 2-3 месяца было создано около десятка похожих тем - хочу быстро и дёшево, или хочу просто и чтоб работало.

Думаю было бы неплохо создать что-то типа тест раздела, понравилось наподобие тут http://forums.overclockers.ru/viewtopic.php?t=157255

Например 2100АР(1км-10км) и всё по ней, какие расстояния работают, параметры настройки, прошивка, стоимость.

Тему прикрепить и начинающие не будут отвлекать простыми вопросами.

Идею можно развить.

Edited by tatuchipapa

Share this post


Link to post
Share on other sites

Черновичок фака по "пионерскому" вайфаю покритикуй

 

есть уже такая тема и что ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Микротик будет там же где и ББ, я вас уверяю.

А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k?

 

Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду.

 

Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно.

 

Неплохо бы знать азы. Даже в пионернетах.

 

Share this post


Link to post
Share on other sites
Микротик будет там же где и ББ, я вас уверяю.

А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k?

 

Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду.

 

Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно.

 

Неплохо бы знать азы. Даже в пионернетах.

sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика...

post-57635-1246540914_thumb.jpg

Edited by fastvd

Share this post


Link to post
Share on other sites
Микротик будет там же где и ББ, я вас уверяю.

А вы пробовали? или вам кто-то рассказал? А у меня, например, есть примеры практического использования микротиковских железок. Или вам привести скрины с 50-60Mbit прокачкой и pps под 80k?

 

Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду.

 

Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно.

 

Неплохо бы знать азы. Даже в пионернетах.

sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика...

А где показанно что ппс 80К?

 

Share this post


Link to post
Share on other sites
А где показанно что ппс 80К?

http://babai.net.ua/clipboard01.jpg

 

Линк, 2 км. Микротик 2.9.27, карточки тп-линк, турборежим.

Edited by rsst

Share this post


Link to post
Share on other sites
Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно.

 

Неплохо бы знать азы. Даже в пионернетах.

простая арифметика показывает, что размер пакета при такой скорости и таком pps приблизительно равен среднему размеру пакета в FastEthernet сетях, что никак не может быть малореальным и теоретическим.

Share this post


Link to post
Share on other sites
sonne - вы не правы! сегоднишнии технологии позволяю прокачать эти 54 мбит - лично у меня на мтике с нстримом и в турбро режими 53 мбита есть чистенького трафика...
+100

абсолютно верно, у меня в таком же режиме реальные 52мбит прокачивает

 

Скорость физического соединения в сетях Ethernet составляет 14 880 пакетов в секунду, а в сетях Fast Ethernet — 148 809 пакетов в секунду.

 

Простая арифметика показывает, что 80 кpps это не менее 54 Мбит/сек, недостижимый теоретический предел совершенно не интересный на практике. так что если вы его достигли, то в вашей сети страшный косяк, ибо ни одно реальное приложение такой бессмысленный флуд генерить не должно.

 

Неплохо бы знать азы. Даже в пионернетах.

80k pps, это не показатель пропускной способности линка, вполне можно его превысить и на 36мбит при интерактивном трафе (войс, видео и т.п.). Тут уже будет стоять проблема не в ширине канала, а в мощности роутеров и модемов.

Share this post


Link to post
Share on other sites
А где показанно что ппс 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.

 

Ужос! Пионеры опровергли арифметику!

 

Не пойму это радиоизлучение или десятелетия реформ так разжижили мозх?

 

 

Share this post


Link to post
Share on other sites
спорим тут, а потом окажется топистартер ставит линк себе на дачу чтоб вконтакте читать и в аське сидеть :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Показаные картинки - не более, чем микротиковский тест скорости.

Для примера: RAR сможет сжать ПУСТОЙ BMP файл с исходным размером 340 мегабайт до 250 килобайт, но в то же время JPG размером 340 мегабайт сожмет до 350 мегабайт.

Если через микротик пустить РЕАЛЬНЫЙ трафик, то pps сразу упадет до 4к.

Все очень просто, и чудес, как мы все прекрасно знаем - на свете не бывает.

Share this post


Link to post
Share on other sites

На Микротике через 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 пакетами.

Share this post


Link to post
Share on other sites
А где показанно что ппс 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).

Share this post


Link to post
Share on other sites

а почему на скриншоте http://forum.nag.ru/forum/index.php?act=at...ost&id=2647

"беспроводное подключение используется на 0%" и в статусе у него "не работает" ? там что, фильм по 100 мегабит ethernet'у качается? тогда 5 мегабайт в секунду это даже маловато как-то.

Share this post


Link to post
Share on other sites
а почему на скриншоте http://forum.nag.ru/forum/index.php?act=at...ost&id=2647

"беспроводное подключение используется на 0%" и в статусе у него "не работает" ? там что, фильм по 100 мегабит ethernet'у качается? тогда 5 мегабайт в секунду это даже маловато как-то.

я к тику кабелм подключён-эт же мост на 5 ггц - что тут не ясного?

Share this post


Link to post
Share on other sites
Как раз нстрим и помогает делать нам свое черное дело. Фича в том, что пакинг мелких пакетов для юзера прозрачен и производится на уровне протокола, что не мешает мне говорить о пропускной способности канала (pps).

 

Мешает. Термин канал имеет вполне опредленное значение, так же как и канальный уровень.

 

В модели OSI канальный уровень отвечает за передачу уже сформированых фреймов (кадров). А сжатие данных пррисходит намного выше. Т.е. показывая тесты копрессии нельзя называть это скоростью передачи канала.

 

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

 

Никаких претензий не было если бы вы написали про алгоритм работы сжатия микротика, не связывая его с работой физики wi-fi.

 

Но походу вы сами не знали об этом пока специалист не объяснил.

 

А где показанно что ппс 80К?

http://babai.net.ua/clipboard01.jpg

 

Линк, 2 км. Микротик 2.9.27, карточки тп-линк, турборежим.

 

Это ТХ, значит должен быть еще график потерь. на TX можно нарисовать все что угодно!

Надо подключать проверенный анализатор пакетов и слушать RX удаленного конца, тогда наступит великое просветление.

Все с вами понятно. Вы из тех людей, которым доказать что-то реально невозможно. Вам даже в реале покажи, вы скажете, что "такого не может быть потому, что не может быть никогда".

 

Я из тех людей которые немного дружат с арифметикой и физикой. Помните про бассейн "в одну трубу втекает, в другую трубу вытекает". Впрочем признаю свою принадлежность к вымирающий подвиду людей в этой стране.

 

А вы, очевидно, из тех людей, для которых крутят по телеку рекламные клипы "вдвое больше вкуса" и "еще больше скорости". Именно это и есть критерии вашего выбора.

Share this post


Link to post
Share on other sites

Sonne - у меня до определенного времени бегало 70 Mbit/s через микротик. Реального траффика. Когда количество линков доросло до 5-и - поставили два Trango на 315 Mbps, т.к. слишком много частотной полосы на 5 Ггц выжирало.

Share this post


Link to post
Share on other sites
Sonne - у меня до определенного времени бегало 70 Mbit/s через микротик. Реального траффика. Когда количество линков доросло до 5-и - поставили два Trango на 315 Mbps, т.к. слишком много частотной полосы на 5 Ггц выжирало.

 

Мы говорим не про мегабиты, мы про количество пакетов в этих мегабитах и про методику этих измерений.

 

Если мерить поток на выходе эзернета удаленного конца, то количество пактеов не может быть больше физической возможности пропихнуть.

 

Если мерить поток на входах-выходах радиоинтерфейса при включенном сжатии, то за счет склейки из этих десятков тысяч пакетов в реальной передаче идет в десятки раз меньше пакетов.

 

Просто пакетная производительность радио устройств это очень важная величина, она по определению всегда ниже чистого эзернета, за счет особенностей протокола.

Это должен понимать любой кто строит радиосеть.

 

А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости.

 

 

Я считаю что правила типа 2 x 2 = 4 полезно знать в всем, чтобы в магазине за 2 сникерса по 20 рублей не отдавать 60 хитрому продавцу.

Share this post


Link to post
Share on other sites
Как раз нстрим и помогает делать нам свое черное дело. Фича в том, что пакинг мелких пакетов для юзера прозрачен и производится на уровне протокола, что не мешает мне говорить о пропускной способности канала (pps).

Никаких претензий не было если бы вы написали про алгоритм работы сжатия микротика, не связывая его с работой физики wi-fi.

Но походу вы сами не знали об этом пока специалист не объяснил.

Конечно же когда-то я об этом не знал :) Но вот, похоже, как раз вы об этом узнали совсем недавно (насколько постов назад), чего, почему-то, не хотите признавать. Впрочем у меня к вам каких-либо претензий не возникает по этому поводу.

 

А вы, очевидно, из тех людей, для которых крутят по телеку рекламные клипы "вдвое больше вкуса" и "еще больше скорости". Именно это и есть критерии вашего выбора.
Да, именно из тех.... с учетом того, что телевидение я не смотрю уже лет 8 :)

 

Share this post


Link to post
Share on other sites
А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости.

Микротиковский склейщик оптимизирован под склейку пакетов и не более того, без привязки к какому-либо приложению. Вот вы же спорите об этом даже не удосужившись хоть немного вникнуть в алгоритмы работы того же nstreme протокола, хотя бы просто почитав что-то по этому поводу.

 

ps: Кстати, похоже вам это не известно, rar упаковывает без последующей потери информации при распаковке, а вот jpeg компрессия подразумевает оную.

 

Share this post


Link to post
Share on other sites
А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например rar оптимизирован под тексты и коды, а jpeg под видеоизображение. Микротиковский склейщик очевидно оптимизирован под его же тест скорости.

 

 

Я считаю что правила типа 2 x 2 = 4 полезно знать в всем, чтобы в магазине за 2 сникерса по 20 рублей не отдавать 60 хитрому продавцу.

Не путайте сжатие со склейкой. Микротик склеивает маленькие пакеты в большие. Т.е. скажем при average packet 500 byte (а в локалках и того меньше бывает), и максимальном куске 4000 byte - это четырехкратное увеличение pps.

Share this post


Link to post
Share on other sites
А вот склейка пакетов это действительно хорошая фича конкретного устройства, только нужно понимать что она оптимизированна под определенное приложение, так же как например 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 не возникает, а экономии полосы нет.

 

Единственный случай заметной экономии это либо поток чистых воипных пакетов, либо чистый флуд от синтетического теста, т.е. ситуаций которые оторваны от реальности.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this