Обсуждаем техническую "сторону" адсл-провайдера, тарифные планы.
telecom.by
************************
ADSL. Выбор провайдера.
************************
Обсуждаем техническую "сторону" адсл-провайдера, тарифные планы.
telecom.by
************************
ADSL. Выбор провайдера.
************************
Кстати, кто что думает по поводу хитрого обсчёта трафика на тп "Хит"? Меня вот за выходные на 4-5 гигабайт кинули (в час считали по 220 мегабайт вместо теоретически возможных 140), в итоге в среду разорвал контракт и сразу после раскроссировки подключусь к конкуренту. Вот официальная отмазка тех.поддержки:
В связи с участившимися вопросами по поводу несовпадения статистики, предоставляемой провайдером и собранной пользователями самостоятельно на рабочих местах, уведомляем:
Провайдер осуществляет обсчёт всего трафика, пришедшего на IP клиента, т.к. для провайдера весь этот трафик является платным. Несовпадения в статистике происходит по той причине, что пользователи запрашивают доставку большего объёма информации, чем может быть пропущено через канал, соответствующий тарифному плану клиента.
Такая ситуация возникает только при активном запросе больших объёмов информации ("скачивании" информации больших объёмов)
В подобной ситуации мы рекомендуем пользователям ограничивать в download-менеджерах скорость закачки информации. В этом случае менеджер не будет отправлять лишних запросов и на IP клиента не будут приходить "лишние" пакеты, что приведёт к выравниванию значений в статистике.
Кстати, после обращения к ним мне "скостили" полгига, однако меня такие подачки не устраивают и я не собираюсь в дальнейшем платить за неоказанные услуги.
З.ы.: и ещё кое-что накипевшее: падучий биллинг, временами по три-четыре дня не работает. Причём в саппорте по телефону 3572357 о таком слове судя по всему не знали и после разъяснения сказали, что через пару часов исправят (дело было когда-то в пятницу утром, биллинг выдавал ошибку с вечера четверга; в итоге заработал только к понедельнику). Даже при подключении раза четыре пришлось данные свои диктовать, а в какой-то момент девушка-оператор сказала типа вам, наверное, сегодня не повезло, в другой раз подключитесь. Будто бы я к джинну за исполнением желаний пришёл и о подключении на коленях просить должен.
DiMoS1988
Уже не одну страницу комментировали по поводу подсчета на малых анлимах.Т.е. чем меньше канал, тем больше трафика в него может не влезть, если вы ,например, запрашиваете скачку несколькими потоками нескольких файлов( фильмов) не ограничивая запросы.Трафик то провайдеру пришел для вас, но втиснуть его некуда, а считает железяка все, что пришло на ваш адрес.И здесь кроме вас никто ваши запросы не отрегулирует. Провайдеру такие ваши двойные нагрузки думаю не менее лишними будут.
goodim,
Трафик то провайдеру пришел для вас, но втиснуть его некуда,
TCP все сам регулирует, другое дело если это UDP, но сомневаюсь, что много кто по UDP качает..
Думаю проблема на много глубже.. есть вообще бредовая идея что провайдер замутил какой то прокси либо обходной канал тогда все, что угодно может быть.
офлайн
trustmeimanengineer
Senior Member
|
|
2747 |
20 лет на сайте Город:
|
Трафик то провайдеру пришел для вас, но втиснуть его некуда
нормальный провайдер считать должен на интерфейсе юзера а не на входе
Провайдеру такие ваши двойные нагрузки думаю не менее лишними будут.
а что такое двойные нагрузки? санта клаус еще 7600 не подарил?
нормальный провайдер Maximas®
А я думал, что должен считать так, как прописано в договоре
офлайн
trustmeimanengineer
Senior Member
|
|
2747 |
20 лет на сайте Город:
|
goodim, если все технические нюансы прописать в договоре провайдера можно будет порвать на британский флаг.
goodim:нормальный провайдер Maximas®
А я думал, что должен считать так, как прописано в договоре
вы понимаете что речь идёт о не оказанной услуге, и не один договор не может противоречить закону, а в данном случае абонент не получал трафик который он оплатил..все остальное технические вопросы которые являются проблемами провайдера, а не абонента.
офлайн
trustmeimanengineer
Senior Member
|
|
2747 |
20 лет на сайте Город:
|
Casper, с вами можно поспорить. только в каждом подобном случае спорят не на форуме а адвокаты. так что разводить очередное словоблудие у кого длиннее не станем.
goodim,
Уже не одну страницу комментировали по поводу подсчета на малых анлимах.Т.е. чем меньше канал, тем больше трафика в него может не влезть, если вы ,например, запрашиваете скачку несколькими потоками нескольких файлов( фильмов) не ограничивая запросы.Трафик то провайдеру пришел для вас, но втиснуть его некуда, а считает железяка все, что пришло на ваш адрес.И здесь кроме вас никто ваши запросы не отрегулирует. Провайдеру такие ваши двойные нагрузки думаю не менее лишними будут.
На ТП "Первый" проводили эксперимент - с беспарольника на бесплатный хостинг выкладывали файл с мусором внутри, весом ровно 1 мегабайт. Затем качали его флешгетом в один поток без остановок. Потом в течение часа не пользовались инетом вообще. Затем проверяли в биллинге данные. Всегда имели 1,5-1,7 метра входящего трафика (эксперимент проводили несколько раз). Из чего был сделан вывод, что Атлант реально существующую проблему с неправильно считающимся трафиком перекладывает на плечи абонента. Звонки в саппорт ничего не дали. Тему на форуме прибили админы.
В итоге "Первый" был послан нах, человек переключился на "Шерсть". Проблема с тарификацией чудесным образом исчезла...
Выводы делайте сами.
офлайн
trustmeimanengineer
Senior Member
|
|
2747 |
20 лет на сайте Город:
|
Tuxozaur, а где вы видите проблему? формально то провайдер действительно принял трафик. со стороны клиента чем его считали? детальную статистику просили?
Maximas®, в чем он прав? В том, что его оборудование неправильно считает трафик?
Каким образом при скачивании файла размером мегабайт трафик составляет 1,5-1,7 метра?
Откуда берутся эти лишние килобайты?
Tuxozaur, проблема есть действительно. Тут надо знать как работает система ограничения скорости на провайдерских железках. Когда клиент делает запрос на некую инфу, эта инфа, файл, начинает отдаваться клиенту через его провайдера. У провайдера канал очень большой, у клиента - сравнительно маленький. Получается, что провайдер, в каждую единицу времени, получает информации для клиента больше, чем этот самый клиент может получить через свой маленький канал. Что происходит с остатками? Они теряются и пере-запрашиваются снова. Чем меньше у клиента канал, тем больше теряется.
А сам трафик считается с помощью т.н. netflow - эта технология предполагает сбор детальной статистики на маршрутизаторе провайдера. Т.е. нетфлоу считает то, что реально пришло, а клиент - только то, что дошло до него. Вот на этом и набегает такая разница.
Соврешнно очевидно, что провайдер должен считать все на стороне пользователя. Осталось только дождаться предложений как это реализовать.
Каким образом при скачивании файла размером мегабайт трафик составляет 1,5-1,7 метра?
Откуда берутся эти лишние килобайты?
Откуда берутся - объяснили. Сделать чтобы не брались очень просто - загрузить свой канал не на 100%, а на 99.99%
господа, сегодня у меня пропал совсем интернет, пишу с GPRS. DSL активный, PPPOE не подключается...
UPD: появилось..
видимо, что то настраивают, в ИССА подробная статистика по суткам не отображается.
протокол TCP умеет подстраивать скорость под параметры самого узкого места в маршруте от точки А до точки Б, если потери составляют более 10% это уже действительно проблема и проблема с оборудованием в первую очередь.
Кстати, кто что думает по поводу хитрого обсчёта трафика на тп "Хит"? Меня вот за выходные на 4-5 гигабайт кинули (в час считали по 220 мегабайт вместо теоретически возможных 140), в итоге в среду разорвал контракт и сразу после раскроссировки подключусь к конкуренту. Вот официальная отмазка тех.поддержки:
Цитата:
В связи с участившимися вопросами по поводу несовпадения статистики, предоставляемой провайдером и собранной пользователями самостоятельно на рабочих местах, уведомляем:
Провайдер осуществляет обсчёт всего трафика, пришедшего на IP клиента, т.к. для провайдера весь этот трафик является платным. Несовпадения в статистике происходит по той причине, что пользователи запрашивают доставку большего объёма информации, чем может быть пропущено через канал, соответствующий тарифному плану клиента.
Такая ситуация возникает только при активном запросе больших объёмов информации ("скачивании" информации больших объёмов)
В подобной ситуации мы рекомендуем пользователям ограничивать в download-менеджерах скорость закачки информации. В этом случае менеджер не будет отправлять лишних запросов и на IP клиента не будут приходить "лишние" пакеты, что приведёт к выравниванию значений в статистике.
поддерживаю возмущение пользователей. если эта ситуация существует на самом деле, то это не означает что так должно быть. провайдеру стоило бы задуматься над решением этой проблемы и этим бы они сократили свои расходы и одновременно улучшили отношение к себе со стороны клиентов. но перекладывать свои расходы на плечи пользователей - это неверный подход к решению проблемы. тем более что канала итак не хватает, а тут еще прову приходит в 2 раза больше чем доходит до пользователя
Откуда берутся - объяснили. Сделать чтобы не брались очень просто - загрузить свой канал не на 100%, а на 99.99%
откуда берется и так понятно - есть типа анлим с 20 гиговым ограничением но и 20 гиг дать жалко поэтму спи№;%м еще 5
Bond, к сожалению блеснуть знаниями тсп/ип не могу, но вопросы возникают все равно...
нетфлоу работает между клиентом и провайдером. почему он вообще учитывает трафик из вне?
не попытка ли это перекладывать проблемы с провайдера на пользователя, хотя знать такое ему не нужно.
опять же пример Tuxozaur показал, что даже на файле в 1Мб потери 70%!!!!
Internet, в большистве своем, основан на протоколе TCP/IP, а у него есть несколько свойств, которые могут нам помочь. TCP/IP не может узнать пропускной способности сети между двумя хостами, поэтому он начинает передавать данные все быстрее и быстрее (это называется "медленный старт". Когда пакеты начинают теряться из-за перегрузки передающей среды, передача тормозится. На самом деле все немного сложнее и умнее, но об этом позже.
ну не могут быть такие зверские потери на ровном месте.