Домолинк - 2!

плюс адын, странно, но все ваши проблемы мне чужды. на домолинке уже больше месяца, и все преотлично, безлимитка 256, обрывы оч. редко, скорость стабильная, пожалуй, уходить с него на Корбину не буду торопиться, а подожду ответных шагов домолинка.
И вопрос чуть оффтоп: народ, как быть, если хочу поставить в квартире параллельный телефон? надо два сплиттера на обе розетки? тогда второй будет без провода к модему висеть?

Потап, тебе нужен только один сплиттер... ставишь его ДО телефонов... то есть, входит провод в квартиру, на него сплиттер, из сплиттера - подключаешь модем, а разъём для телефона втыкаешь хоть десять параллельных телефонов...

Дорогой резерв за 100р в месяц

Блин, опять сначала тормоза, а потом вообще наглухо Домолинк отвалился (я на GPRS перешел). Что, с нагрузкой пятничного вечера система категорически не справляется?

Aml, а я кайф ловлю))) Не знаю что у них там случилось, 350-350 трубку не берет, но сайты открываются чудесно, просто в восемь вечера я на инет забил, торрент качает на нормальной скорости, все ок, только за сайты, предварительно выключив торрент - ничего...


через 5 минут...

все, сглазил, те же грабли как и в восемь вечера...

Иногда системные администраторы слышат от пользователей жалобы на то что Интернет работает медленно, страницы не открываются и вообще “ВСЕ ГЛЮЧИТ!”.

Истинный админ верит не слухам, а фактам. И не пугайтесь, если первое что он попросит - показать ему пинг, трейсроут или mtr. Читать дальше>>>

На счёт перегрузки канала связи...
Полазил я тут на досуге и накопал на сайте ВоронежЦентрТелеком преинтереснейшие графики-таблицы,
которые как я понял обновляются в режиме реального времени
загрузка внешнего канала связи ЦентрТелеком(2Гбит)
http://isp.vsi.ru/support/uplink_mspd.html
а так же загрузка внешнего канала связи СтартТелеком(100Мбит)
http://isp.vsi.ru/support/uplink_start.html
Так вот если посмотреть эти графики то можно сделать вывод что каналы то просто напросто пустуют...особенно интересно наблюдать повышение потребления трафика
на канале ЦентрТелекома после того как в октябре в Воронежском Домолинке увеличили
скорости в 3 раза...трафик конечно повысился,но до 2 Гбит как до Луны...
я не думаю,что ситуация в Смоленске намного отличается...
Если это так,то каналы полупустые стоят и нас просто "кидают"

Видимо они решили за 30 рублей ( http://www.domolink.ru/18932 ) протестить насколько вообще есть спрос на выскоскоростной инет и насколько еще выдерживает оборудование. Потестируют, сделают выводы и если запас прочности есть (речь даже не про магистральный 2-Гбитный канал, а просто локальные сети на территории провайдера), то поднимут скорость уже навсегда.
В принципе 1024 Кб/с уже должно хватать для просмотра видео в онлайне, а для закачек и 512 хватает - за ночь фильм закачивается, больше особо и не надо.
Да там и по графику видно, что скорость увеличили в 3 раза, а загрузка канала выросла всего в 1.5 раза. Ну т.е. большой популярностью при стоимости всего 30 рублей эта услуга видимо не пользуется.</div>

проволочник, это данные mrtg (полезная скажу штука, сам такой пользуюсь) так вот.. тут в расчёт берётся теоретический максимум канала, а как известно из теории TCP в сетях наибольший показатель эффективности использования канала достигается при загрузке канала в 50-60%
ЗЫ: за сутки данные усреднённые и берутся из данных по 5 минутному замеру.. так что реальные показатели на 30% выше.. страшна не постоянная загрузка, а её всплески до критических значений.

Вы рано выводы делаете. Как всегда.
Кроме широкого канала нужно ещё, к примеру, включать его во что-то. Маршрутизатор может, к примеру, прекрасно переваривать двухгигабитный канал, и загибаться не от трафика, а от количества сессий. Как раз недавно сталкивались. Серьезные железки стоят далеко не копейки.
То, что ЦТ подбирает ширину канала под пиковую нагрузку, как сказал leo, так это не кидалово, а замечательно.
А цены, как уже много раз писали разные люди, включая меня, определяются не каналами, а рынком.
Так что загрузка каналов Воронежа никак не свидетельствует о кидалове в Смоленске ))

После пятничного вечернего сбоя почему-то поднялась скорость загрузок. Подключен на ExpressLink256, загрузки обычно были в районе 32kB/c, а теперь возросли до 40-47kB/c.
<img src="http://s53.radikal.ru/i141/0810/2b/1d6278fb9083.gif" border="0" class="linked-image" />

на ночном анлиме ExpressNight у нескольких моих знакомых скорость последние недели стабильно 300-400 КБ\с (!!!). ПРичем ежедневно и постоянно. А это около 2 с лишним Мбит\с...

Если качаешь торрентом, то такое возможно из-за сложения локального и внешнего каналов: http://www.sprosiadmina.ru/2008/10/domolink-adsl-features/</div>

http://www.2ip.ru/speed/test.php
вот так можно...нажмите ссылку и подождите немного...

Гугл уже посказал http://speed-tester.info/
<img src="http://s43.radikal.ru/i100/0810/b0/443ffe7bd968.gif" border="0" class="linked-image" />

Результаты измерений соответсвуют реально наблюдаемой скорости закачки.

а у меня аминь какой то... третий разрыв за примерно 40 мин

А вот результат по http://www.2ip.ru/speed/test.php
<img src="http://s46.radikal.ru/i111/0810/78/fc8e864fe64d.gif" border="0" class="linked-image" />

чето не понял: на http://www.2ip.ru/ написано что мой провайдер JSC Central Telecommunication Company. чтобы это могло значить?

<div class='quotetop'>Цитата</div><div class='quotemain'>Вам надо попробывать отключить модем на 10 минут...[/quote]
Когда в пятницу стало совсем глухо, я как раз-таки отключил модем на несколько минут и перезагрузит компьютер. С тех пор такое безобразие творится. </div>

JSC = Joint Stock Company
Соответственно, Закрытое Акционерное Общество Центральная Телекоммуникационная Компания</div>

у меня только одно предположение: шейпер Цт не справляется с запросами, и часть просто дропается по причине недопущения загромождения очереди на железке шейпера.. ведь если подумать глюки при сёрфинге, т.е в трафе высока часть SYN пакетов.. а алгоритм шейпера таков что по умолчанию канал до единичного юзверя не имеет гарантированный пропускной способности (ну что обычно и у всех так), а при приходе запросов от конкреного пользователя и в частности SYN пакетов шейпер почему-то очень долго думает для открытия канала соответсвующей ширины.. и по привышении времени отклика (а если мне память не изменяет в linux это где-то 30 секунд, но возможны вариации или если это первый SYN, то идёт повторный пакет. - это объясняет задержки, на которые жалуются некоторые пользователи ) сбрасывает текущий пакет.. в результате чего многие пользоветели и наблюдают : ' Ошибка. Невозможно найти удаленный сервер' вот если вкратце, то как-то так..

Предлагаю дормолинку разместить такой ответ для простых пользователей у которых что то не грузиться и посмотреть на реакцию </div>

Host--------------------------------------------Loss% ---Sent Recv Best Avrg Wrst Last
192.168.1.1-----------------------------------------0 ---115 115 0 0 16 0
10.130.128.1----------------------------------------0 ---115 115 0 6 16 15
No response from host---------------------------100 ---115 0 0 0 0 0
No response from host---------------------------100 ---115 0 0 0 0 0
No response from host---------------------------100 ---115 0 0 0 0 0
77.51.254.81--------------------------------------10 ---115 104 0 9 32 0
77.51.253.4---------------------------------------73 ---115 32 15 105 828 15
82.196.159.4--------------------------------------11 ---114 102 0 87 953 15
msk-dsr5-vl912.rt-comm.ru---------------------94 ---114 7 0 13 16 16
msk-bgw1-ge1-0-0-0.rt-comm.ru---------------12 ---114 101 0 16 47 32
195.161.165.246----------------------------------11 ---114 102 0 15 62 46
cat01.Moscow.gldn.net---------------------------10 ---114 103 0 18 219 16
mailru-KK12-1-gw.Moscow.gldn.net------------19 ---114 93 15 20 47 16
mail.ru-----------------------------------------------0 ---114 114 15 16 32 16

Ps: Разговор на околодомолинковскую тему: если кто что поймёт и вникнет...

leo_root (20:54:21 19/10/2008)
у меня только одно предположение: шейпер Цт не справляется с запросами, и часть просто дропается по причине недопущения загромождения очереди на железке шейпера.. ведь если подумать глюки при сёрфинге, т.е в трафе высока часть SYN пакетов.. а алгоритм шейпера таков что по умолчанию канал до единичного юзверя не имеет гарантированный пропускной способности (ну что обычно и у всех так), а при приходе запросов от конкреного пользователя и в частности SYN пакетов шейпер почему-то очень долго думает для открытия канала соответсвующей ширины.. и по привышении времени отклика (а если мне память не изменяет в linux это где-то 30 секунд, но возможны вариации или если это первый SYN, то идёт повторный пакет. - это объясняет задержки, на которые жалуются некоторые пользователи ) сбрасывает текущий пакет.. в результате чего многие пользоветели и наблюдают : ' Ошибка. Невозможно найти удаленный сервер' вот если вкратце, то как-то так..

leo_root (20:54:48 19/10/2008)
*CRAZY*это похоже на бред??

squall (21:11:06 19/10/2008)
полный бред

leo_root (21:11:20 19/10/2008)
ага... но кажись так и есть..

squall (21:11:40 19/10/2008)
такая фича не на шейпере, а при QOS

leo_root (21:11:47 19/10/2008)
другое мне в голову не прихоодит как объяснить затыки долболинка

leo_root (2135 19/10/2008)
да дело не в самом шейпере, а в величине очереди запросов.. как мне кажется долболинк перегружают синами и он их дропает направо и налево

squall (2153 19/10/2008)
не... эт полный бред

leo_root (2109 19/10/2008)
ну а по другому я объяснить не могу

squall (21:16:44 19/10/2008)
смысл в том, что шейперу насрать син пакет или нет

squall (2106 19/10/2008)
так бы падали и любые другие пакеты

leo_root (2122 19/10/2008)
ага, но в очереди время жизни меньше

squall (2156 19/10/2008)
просто вносятся задержки между пакетами

leo_root (2105 19/10/2008)
там же 3 сина идёт туда, обратно и опять туда

leo_root (2140 19/10/2008)
причём если первый не принимается, то чрез 10 сек идёт второй, ещё чераз вроде 15 третий.. в общем общее время на запрос 45 сек!

squall (2149 19/10/2008)
какая нах разница скока пакетов подряд? син не син... хоть акк..
сначала идет син пакет, еси дошел возвращается ак

leo_root (2101 19/10/2008)
а очередь ведь ограничена.. в винда 100 вобщепакетов. в никсах можно 256 и выше. но всё равно предел есть

squall (2140 19/10/2008)
предел то есть, но для каждого сорса клиента свой буфер

leo_root (2159 19/10/2008)
тут х.з

squall (2101 19/10/2008)
Принцип алгоритма заключается в том, что первую секунду/две шейпер работает НЕ ограничивая скорость, затем включается ограничение.
Это делается для того, что бы пользователь чувствовал себя комфортно при просмотре интернет-страничек: за первую секунду на огромной скорости любая страничка загружается моментально, у пользователя создается впечатление, что интернет очень быстрый.

leo_root (2147 19/10/2008)
это да, но ведь надо ещё порт открыть.. этот канал выделить..

squall (2103 19/10/2008)
неа

squall (2140 19/10/2008)
канал уже есть

leo_root (2105 19/10/2008)
не.. т.к за юзверем не резервируется ничё

squall (2157 19/10/2008)
мы торкаем юзверя в пайп и там его траф крутится

squall (21:34:58 19/10/2008)
мне вот что то кажется что просто ipfw не успевает открывать пайп...

squall (21:35:12 19/10/2008)
пожтому и затык

squall (21:35:54 19/10/2008)
по ходу железка тупит... не успевает

leo_root (21:36:15 19/10/2008)
я тож к такому выводу пришёл.. в чём именно тупит это уже частности

squall (21:36:33 19/10/2008)
по ходу камень не успевает...

squall (21:47:59 19/10/2008)
dummynet работает, просматривая очередь поставленных на ожидание пакетов с некоторой частотой (по умолчанию - 100 раз в секунду). Вы можете увеличить или уменьшить этот параметр, соответственно повысив точность ограничения скорости ценой повышения нагрузки на процессор, либо уменьшить нагрузку на процессор за счет уменьшения точности ограничения пропускной способности. Имеет смысл менять этот параметр в сторону увеличения только если при нормальной работе Ваш процессор нагружен не более чем на 10%. Уменьшение этого параметра обычно не дает сильного выигрыша при перегруженном процессоре, разве что ограничение полосы пропускания - это основная выполняемая сервером задача. Увеличение этого параметра, кстати, увеличивает нагрев процессора. Чрезмерное увеличение может наоборот приводить к понижению точности работы dummynet, т.к. процессор может не успевать отрабатывать сигналы от таймера.

squall (21:49:07 19/10/2008)
а терь представь насколько жадные люди в долюолинке

squall (21:51:41 19/10/2008)
думаю камень там на все 200% забит

leo_root (21:52:07 19/10/2008)
не.. не думаю.

leo_root (21:52:45 19/10/2008)
там больше узкие места с базой должны быть.. ведь статистика сниматся в реальном времени, + записьв базу

squall (21:53:41 19/10/2008)
думаю что статичтика снимается сенсором от нетфлоу

leo_root (21:54:37 19/10/2008)
ну один фиг чем снимается, но ту подумай сколько жрётся трафа на запись к базе.. ведь она стопудов на отдельной железке

squall (21:55:18 19/10/2008)
она туда скорее всего и стекает с серваков) нетфлоу датчик может лить на сенсор, который на др тачке

leo_root (21:55:58 19/10/2008)
х.з эт уже наши домыслы

squall (21:56:50 19/10/2008)
это разумные мысли, а не домыслы) я бы например со всех шейперов лил на 1 датчик и крутил в базу

squall (21:57:04 19/10/2008)
но тут нада смотреть на нагрузку

leo_root (21:57:07 19/10/2008)
ну эт ты, а то долболинк

squall (21:58:21 19/10/2008)
слууушай... скока у нас порт держится открытым по дефолту?

leo_root (21:58:40 19/10/2008)
до 2х часов

squall (22:00:39 19/10/2008)
просто смотри какая штука...
пинг до яндекса... ждем пока на нас соизволит сработать файр... 2 пакеты ушли...
далльше норм...
через некоторое время простоя коннект падает
снова пингуем...
опять те же 2 пакета простоя

squall (22:00:57 19/10/2008)
осталось засечь время

squall (22:02:24 19/10/2008)
но тут возникает мысль.... а файр ли тормозит?

squall (22:02:39 19/10/2008)
правило то уже загружено с шейпером

leo_root (22:03:29 19/10/2008)
не да.. время соединений можно рулить переменными sysctl/ может порулили кривыми руками???

leo_root (22:04:05 19/10/2008)
sysctl через неё вообще можно сеть довести до полной неработоспособности.. х.з может чего накрутили

squall (22:04:32 19/10/2008)
ты ещё кста не забывай о лимите соединений...

leo_root (22:05:06 19/10/2008)
ага.. я помню. .я ж тебе выше говрил.. в никсах он дефолтом был раньше 256 во всяком случае в RH

squall (22:05:39 19/10/2008)
кста... у тя не было такого?
Jan 1 12:01:05 pppd[247]: sent [PAP AuthReq id=0x1 user="DML1003695@sml" password={hidden}]
Jan 1 12:01:05 pppd[247]: rcvd [LCP EchoRep id=0x0 magic=0x5a1b1673] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jan 1 12:01:05 pppd[247]: rcvd [PAP AuthNak id=0x1 "Exceeded sessions limit."] 00 00 00 00 00 00 00 00 00
Jan 1 12:01:05 pppd[247]: Remote message: Exceeded sessions limit.
Jan 1 12:01:05 pppd[247]: PAP authentication failed
Jan 1 12:01:05 pppd[247]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]

leo_root (22:06:15 19/10/2008)
не

squall (22:06:36 19/10/2008)
эт серв перегружен0

squall (22:06:47 19/10/2008)
PAP

leo_root (22:07:06 19/10/2008)
не вижу.. поэтому и не отвечает

squall (22:07:26 19/10/2008)
это при коннекте к нему

squall (22:07:51 19/10/2008)
иногда вылетает, еси ханово коннект поднимать

leo_root (22:08:09 19/10/2008)
тогда при чём превышение лимиты подключений.. ??

leo_root (22:08:34 19/10/2008)
Exceeded sessions limit.. это ж дословно исчерпан лимит сессий!

squall (22:08:51 19/10/2008)
угу, подключений к пулу

leo_root (22:09:11 19/10/2008)
да ну.. бред какой-то

squall (22:09:26 19/10/2008)
не, не бред... реальность

squall (22:11:14 19/10/2008)
какие я забавные параметры нашел)))
net.inet.ip.dummynet.hash_size - целочисленная переменная. Соответствует размеру хэш-таблицы, используемой dummynet для хранения очередей. Увеличение этого значение ускоряет работу dummynet при большом количестве очередей, естественно в обмен на оперативную память. Значение по умолчанию - 64.

net.inet.ip.dummynet.expire - логическая переменная. При установке в 1 очереди dummynet удаляются через некоторое время после того, как через них перестали "бегать" пакеты. В противном случае очереди удаляются только при нехватке памяти для размещения новых. Значение по умолчанию - 1. Имеет смысл выставлять в 0, если Ваш сервер обслуживает несколько крупных потребителей трафика, постоянно находящихся в режиме on-line - в этом случае кратковременное прекращение активности потребителя не должно вызывать удаления его очереди, чтобы не тратить времени на ее создание заново при появлении потребителя. В случае множества мелких потребителей, подключающихся и отключающихся от сети на длительный срок имеет смысл освобождать ресурсы, чтобы ускорить работу dummynet за счет меньшей таблицы очередей.

net.inet.ip.dummynet.max_chain_len - целочисленная переменная, значение по умолчанию - 16. Количество очередей, способных одновременно храниться в одной ячейке хэш-таблицы. При превышении этого значение пустые очереди удаляются. (или те, которым меньше всего повезло).

leo_root (2251 19/10/2008)
ну я ж говорю если порыца много можно найти.. это ведь всё на ядерном уровне.. х.з что у них там собрано

squall (2209 19/10/2008)
скорее накавыряно

leo_root (2217 19/10/2008)
возможно

squall (2242 19/10/2008)
net.inet.ip.dummynet.expire - логическая переменная. При установке в 1 очереди dummynet удаляются через некоторое время после того, как через них перестали "бегать" пакеты.

squall (2256 19/10/2008)
отсюда недоходящие пакеты

leo_root (2207 19/10/2008)
тоже очень возможно..

leo_root (2243 19/10/2008)
короч определились: какие-то проблемы при постановке пакетов в очередь и удержании сессии в целом.

squall (2203 19/10/2008)
точняк

[attachment=3117:тест2.jpg]
Странно, файлы скачиваются на близко к максимальной скорости,
а время загрузки некоторых страниц скоро можно измерять минутами,
такого даже на диалапе не было.