Квази-мегабит от Голден Телеком

Конечно, это было бы очень важно при измерениях, если бы нас огорчала слишком большая "полоса доступа" или там загрузка интерфейса. Но вот меня огорчает, что со всем якобы шумом в канале я вижу все равно 820 кбпс и не больше. Но раз уж начали, схема у меня следующая:



Все бродкасты и прочий эфирный шум оседают на точке присоединения последней мили, от нее до компа голая маршрутизация, и на собирающий статистику интерфейс прилетает только стерильный интернет и ничего более.



Бредового в них то, что ты собираешься фильтровать мусор после получения его интерфейсом.

Ничерта не понял. В том числе не понятно какие откровения на меня свалятся после всех этих колдунств?

В еще в начале темы все рассказали.

Я предлагаю все же читать сообщения в топике ;-)

коллега подключился в одной из частей юго-западного (ул. Московская), там говорит со скоростью все ок. 120-123 килобайта днем, около 250 ночью. есть версия, озвученная официальным источником, что проблема с установленным железом, что в радиусе нормальные параметры скорости честного мегабита, а некоторые девайсы их не понимают как надо.

Хм, а почему эти же девайсы до 19 марта всё нормально понимали...?
8(

И где это "есть версия, озвученная официальным источником"??

[Сообщение изменено пользователем 28.04.2008 15:36]

одну модель меняли на другую.

Отсюда вопрос: собирается ли "официальный источник" предпринимать какие-либо шаги для исправления данной ситуации и возвращения нормальных скоростей ущемленным юзерам :]
Всё-таки сидеть на 800Кбитке не сильно весело, когда у многих провайдеров за чуть большую сумму уже появились 2-ух мегабитки и судя по отзывам " не обрезанные".

[Сообщение изменено пользователем 28.04.2008 19:08]

Трейсинг покажет путь до ресурса или ресурсов с которых будет произведена закачка и создание графика, в списке будут все узлы стоящие от клиента до этого ресурса, там не должно быть левых узлов, которые могут резать траф.
Открываем cmd.exe и пишем туда tracert имя_узла_или_ip

Пример:

C:\Users\UserUSI>tracert yandex.ru

Трассировка маршрута к yandex.ru [87.250.251.11]
с максимальным числом прыжков 30:

1 9 ms 9 ms 9 ms 212.220.17.6
2 9 ms 9 ms 10 ms 212.220.17.9
3 * * * Превышен интервал ожидания для запроса.
4 12 ms 12 ms 11 ms 90.150.2.101
5 9 ms 10 ms 10 ms 90.150.2.102
6 9 ms 10 ms 9 ms mfist8-pe1.gd.usi.ru [194.85.107.67]
7 11 ms 11 ms 10 ms demidov.yandex.net [194.85.107.57]
8 13 ms 13 ms 12 ms 213.180.208.30
9 41 ms 41 ms 40 ms 213.180.208.26
10 42 ms 40 ms 43 ms 213.180.208.26
11 46 ms 43 ms 45 ms apollo-em0-vlan121.yandex.net [87.250.233.103]
12 40 ms 43 ms 39 ms vavilov-em0-vlan2.yandex.net [87.250.228.129]
13 47 ms 47 ms 51 ms yandex.ru [87.250.251.11]

Трассировка завершена.

Здесь видим что:
6 9 ms 10 ms 9 ms mfist8-pe1.gd.usi.ru [194.85.107.67] - последний усишный узел.
7 11 ms 11 ms 10 ms demidov.yandex.net [194.85.107.57] - уже яндекс.

Ничего левого на пути нету. А вот когда качаешь через p2p сети, то траф идет и через Будапешт и через штаты США бывает. Попробуй потом докажи что режет канал пров, а не что-то другое.

да, упоминалось, что всем ответственным предписано решить проблему.

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

Есть понятие техническая сторона - тут конечно все и без особых измерений ясно, а есть юридическая, так вот с юридической стороны ваш метод измерений рассыпится если попытаетесь его предъявить в качестве доказательств. Не надо путать эти стороны. Торренты у меня канал на максимум не нагружает в некоторых случаях. И не надо мне пистеть какой ты крутой спец, я тоже могу много чего про ndis, miniport-овые фильтры, tdi и прямую работу с ethernet картой через порты в/в для измерения dowstream скорости. Я лишь хотел обратить внимание на некоторые аспекты, в ответ посыпались какие-то левые оскорбления, вы вообще адекватны? откуда агрессия?

А твои выверты наверное юридически чисты? С какой кстати? Методика сбора моей статистики полностью описана, открыта и прозрачна, что делает ее 1) воспроизводимой 2) верифицируемой. Опровергай на здоровье.



Я этого нигде не говорил. Твои фантазии.



И чо?



Никаких оскорблений, ты пишешь малограмотный бред там, где это совсем не нужно. Некоторые аспекты я всестороннейше обдумал, спасибо. Где они, кстати?



Определенно не мне судить. И на "вы" меня совсем не обязательно, пустое.

Перед тем, как написать что-нибудь еще, прошу:
1) Указать конкретные неточности и сомнительные моменты в моих измерениях не прикрываясь всякими имхами и прочей софистикой;
2) Попробовать что-нибудь намерять "по-своему", скажем за 12 часов;
3) Объяснить самому себе разницу в IP трафике с источником в Москве и с источником в Будапеште или САСШ, и на что повлияет количество хопов при транспорте кроме latency time, которое в данном случае не имеет никакого значения. (При том, что в европе и штатах с бродбандом дела обстоят в разы лучше, чем на 1/6 части суши).

Вот тебе уже более нормально и аргументировано.
1. BitTorrent. Скорость получения данных зависит от других пользователей, количество которых неизвестно (из данных), стат данных по этому поводу тоже не имеется ни количества IP ни частоты их изменений, ни качество каналов. То есть вполне допускается ситуация что скачка велась от одного человека с узким каналом, это нужно опровергнуть фактами. P2P клиенты помимо этого имеют ряд особенностей - в некоторых случаях скорость отдачи и приема можно регулировать, все это не было отображено.
2. Нет смысла, результат мне заранее известен.
3. Разница есть. IP трафик идет обычно по сколько? по ~1.5 кило (ethernet MTU). TCP, про поля ack и seq известно? Это синхронный протокол, на каждый пакет должен прийти соответствующий ответ, следующий пакет в это время отправлен не будет (возможна отправка сразу по 2-3 пакета, но это не существенно). Latency time при больших задержках ограничит скорость, канал синхронный. Поэтому я говорил про качество канала. CISCO сами выбирают оптимальный маршрут - он может изменятся, для клиента в США составлять уйму узлов. Высокий Latency time -> медленная скорость доставки пакетов и ответа на них -> низкая скорость закачки. График сжат, можно получить представление только о скорости за минуту, а там возможно были те самые проблемы в виде провалов на более коротких промежутках.

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

P.S. Отбросьте умную лексику, закончите УГТУ и потом будете так разговаривать.

[Сообщение изменено пользователем 30.04.2008 00:25]

Химфак пойдет? Или металлургический?

Вчера показывало 125к
Сегодня 100... Безусловно можно умные мысли излагать... Результат на лицо..

День сегодня напряженный, извините перегнул ))

Интересно, сколько еще раз в теме необходимо сказать, что торрент не единственный источник загрузки. И при каких обстоятельствах, если допустить что канал не зарезан и торрент с прочими загружают канал не до предела, можно получить ровную загрузку в 820 килобит практически на 13 часов измерений? От этого и будем плясать.

Чем статистическая выборка отличается от отдельно взятых результатов надо объяснять?



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



Я настаиваю на этом акте насилия над личностью. Очень хочется сравнить с "заранее известным результатом".



Феерично. А тут многопоточность и очереди, да и время задержки никого не волнует просто по статистическим соображениям - какие бы ни были проблемы у некоторых из пиров, при значительном их количестве я все равно получу источник траффика с заведомо большей полосой. Если вдаваться в частности: торрент DHT - еще один минус latency.

Да, это опять вопрос верификации исходных данных, и опять же к контрольным измерениям.



Еще более феерично. Допустим я тебя понял, и под "cisco" ты имел в виду маршрутизатор произвольного вендора. Сами? Оптимальный? Советую просто для ликбеза почитать про маршрутизацию в интернете, но начать лучше с математики и графов.



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



Ищи в конревом посте по слову telnet.



Использовать простые короткие предложения? Так лучше?



Это был Аргумент Последней Надежды? Не в тот тазик.

Это ты где такие видел? Вот уж бред так бред. Непрерывная очередь фреймов это 3-4 за раз.


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



Нет вручную сидит оператор и выбирает марщрут. Опять бред.

Всегото навсего я указал на недостаток информации и это вылилось в гениальный бред. Мне даже не интересно :-D

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



Тогда зачем ты тут пишешь?

Никаких конкретных неточностей в методике ты так и не назвал, лишь неуверенные попытки зацепится за время задержки и якобы сомнительных исходных данных, которые я в общем-то выложил ровно в том формате и объеме, каким считал нужным для форума.

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

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

Где я не ответил? Только на предложение что-то самому померять. В данном случае вы уже начинаете практиковать подмену понятий, в данном случае вы уже начинаете увиливать от ответов простым неконструктивным бредом, это заметно по последним сообщениям.


Не назвал? Да я в принципе уже показал что сама методика неверна.


Как же то тебя долго доходит, поменяй ты способ нагрузки канала и ВСЁ! нагрузи с близлежащего источника. и выложи доп данные, я это и пытаюсь сказать уже, только вот вы уже сами запутались в своих фактологических высказываниях. Я кстати как раз разрабатываю TCP, IP, PPTP, UDP, DNS стэки, а ты знаешь сколько стоит такой стэк? от 20k$? заплати и я выложу.

убило и разорвало :-D

например:



Считаю это ключевым моментом. Равно как и возможносить измерения по твоей методике.



Можно еще раз, я кажется выходил? Кроме притянутых за уши времени задержки и фальсифицированных исходных данных, которые легко проверяются как сказано выше.



Подменные понятия в студию.



Где?



Опять таки, и чо?

UserUSI, пожта для обсуждения всех аспектов методики измерения и её юридической стороны создайте отд. тему!!

Не надо флудить здесь!!
[ :ultra: :suxx: :suxx: :suxx:

Я тут опять вмешаюсь по поводу:


Бредового в этом ничего нет, т.к. пропускная способность на интерфейсе во много раз больше той скорости, с которой этот мусор поступает + этот шлак идет не из мегабита, а из, скажем, сегмента. Так что зафильтровав его даже на интерфейсе абсолютно ничего не изменится. И пример:

100Мбит/с - пропускная способность интерфейса
1Мбит/с - скорость поступления полезных данных на интерфейс (из инета)
0,1Мбит/с - скорость поступления шлака на интерфейс

В сумме на интерфейс прилетает 1,1Мбит/с. Зафильтровав 0,1Мбит/с всякой ерунды мы как раз получим реальную скорость поступления данных из инета. Не понимаю, почему этого сделать нельзя. По сути ты же точно также фильтруешь этот бред на маршрутизаторе, только ты делаешь это физически, а я логически

Я не отрицаю наличие постороннего трафика, тут ты бесспорно прав. Но ты предлагаешь настраивать фильтры на самом интерфейсе _измерения_ по точно такой же методике. Подумай сам: пакет в любом случае прилетит на интерфейс, повлияет на загрузку (а ведь мы собираем загрузку интерфейса как общую точку транзита всего трафика) и потом уже отфильтруется.

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

Либо собирать схему, как у меня на картинке выше.