Полный OFF для разных споров

а что тут объяснять...

в плохо проложенной сети пинг может зависеть и от солнечной активности...

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

пфффф
Дак это любой ребенок знает про свиное рыло в калашном ряду... Физтех явно не рулит :-( Маздай грамотнее отвечал...

Ох, прикольно читать.
Если время пинга большое, есть не так много вариантов.

Замедлиться в проводе кадр не может, скорость езернета фиксирована и не меняется.
Застрять в свитче кадр не может (буфер слишком мал, что бы это было заметно).
Остается все два места, где кадр может "отдохнуть". Это буфере отсылающего компа или буфер щлюза.
Все, других вариантов нет (если исключить проблемы в движении по стеку OSI).

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

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

Итак, имеем, что:
Большой пинг == большой нагрузке.

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

ДА. Если дефект линии вызывает массовую генерацию битых или не распознающихся кадров. Но это теория.
Если на практике имеется временное увеличение времени пинга без потерь пакетов - я бы не стал винить провода и температуру. Причина в другом - например этот сегмент висит на радиолинке. ;-)
Если идет увеличение времени пинга с массовым пропаданием пакетов - вполне вероятен редкий (действительно редкий) случай хитрого глюка. И то - я бы в первую очередь винил активное оборудование (в первую очередь свитчи-мыльницы СОХО), а не провода.

Воббще, чем дискутировать - не проще глянуть чего творится на сетевушке? Для нормальных карточек софт для смотрения физики (пришедшие пакеты, битые, и т.п.) идет в комплекте.
Или сниффером глянуть, чего творится в езернете... :-)

Уф...

[Сообщение изменено пользователем 26.07.2003 23:20]

Точка. Апплодирую.
Гуллиту итти читать книжки, на горшок и спать.

В общем, у меня имеется хитрый глюк, ровно в 1:00 по местному времени уже 2 дня подряд скорость в локалке (Уралмаш) резко увеличивается с 15Кбит/сек. до 700-800 Кбит/сек. Причём быстро начинает работать также и внутригород и внешка. Затем скорость постепенно снижатся, достикая своего минимума где-то к 12, 13 часам следующего дня. Затем стабильно медленно держится до указанных 1:00 и всё повторяется.
Во время всплесков производительности пинг до шлюза проходит без потери пакетов вообще и с минимальными задержками, в остальное время процент потерь составляет от 50 до 90%%, а также шлюз отвечает со значительными задержками.

Какие будут мысли по этому поводу?

Да, кстати, под скоростью понимается среднее количество скачаных килобайт в секунду.

ermsoft -
1. уточни откуда ты качаешь - из своего сегмента, из города или из австралии
2. элементарным трейсом для начала глнь, где идет резкое увелмчение времени ответа

потом дальше надо будет думать

у меня такая вот бадяга
с понедельника по пятницу
пинг 400-500
время ожидания запроса истекло
как субота воскресенье так всё зашибись
ping 195.58.0.130 -t
Ответ от 195.58.0.130: число байт=32 время=12мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=13мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=11мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=13мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=13мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=10мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=9мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=11мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=13мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=11мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=14мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=10мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=12мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=18мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=12мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=17мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=59мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=77мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=63мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=56мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=77мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=12мс TTL=121
Ответ от 195.58.0.130: число байт=32 время=12мс TTL=121
завтра выложу этот же адрес
кабель прежний

Ночью скорость до 700-800Кбит/сек в локалке (в своём сегменте), скорость внутригорода и внешки оценить пока не берусь, потому как ничего большого не качал, но что-то небольшое, например, manlix.ru с valuehost, качается практически мгновенно, т.е. меньше секунды. Внутригород (ну не совсем ;-) ), скажем, uralmash.ru также отвечает мгновенно. Чего не скажешь про дневное качание, при этом скорость в локалке в лучшем случае 15Кбит/сек, а внешка 0-2Кбит/сек и всё это постоянно сопровождается разрывами соединения. Только что пропинговал шлюз, процент потерь - 38% Это ещё по-божески...
В данное время, если пинг до шлюза походит, то проходит меньше чем за 10 мсек (в данный момент сижу в винде), но частенько ответ не приходит...
Результаты tracertа показывают, что задержка происходит каждый раз в разных местах, т.е. в трёх "колоночках" ;-) его вывода, скорость может меняться от * до <10мсек, причём каждый раз результат меняется, где раньше было * становится <10 и наоборот. Поэтому с увереностью нельзя сказать где именно происходит задержка. Хотя есть подозрения на ближайший шлюз ;-)
Выливается это всё в то, что например, http://www.timus.ru ответил мне где-то минут через 5, после нескольких рефрешей.
Скорость в локалке в данный момент достаточно высока, сейчас пробую слить фильм, скорость прыгает от 400 до 2000 Кбит/сек (На сколько можно верить показаниям KillCopy).
Шлюз 213.140.116.1
Далее идёт циска cs-1.uralmash.ru, потом некий 195.58.3.6, а затем ats51-gw.
В общем в данный момент средняя скорость пока нормальная. Посмотрим что будет дальше...

Да, кстати, скорость скачки с timusa в данный момент 16Кбит/сек.
[Сообщение изменено пользователем 27.07.2003 14:23]

[Сообщение изменено пользователем 27.07.2003 14:29]

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

Дед Мазада, я хотел только сказать, что при 50% потерях - ВРЕМЯ ПИНГА И СКОРОСТЬ СОЕДИНЕНИЯ уменьшаеться уже только по тому, что доступно только 50% TCP фреймов. При небольшой загрузки скорость пингов будет уже значительно падать, нежели при нормальнео функционирующей сети. Более того испорченные пакеты будут генерировать паразитный трафик в домене коллизий, бесполезно загружая сеть. Вот о чем вам хотели втолковать по-моему.

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

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

Ну вот опять 1:00 - Всё летает! И внутригород и внешка и локалка! Только что все эти виды тормозили, и вдруг на тебе! И провода тут ни при чём, не могут же они остыть от нагрева солнцем мгновенно и по расписанию ;-) Короче говоря, проверяйте господа монтажники, что такое в это время происходит, а если и так знаете то поделитесь, пожалуйста с глупыми юзерами. ;-)

Если вам удасться сохранить постоянно ту скорость, которая бывает после 1:00, то это будет вполне приемлемо для комфортной работы.

У меня сложилось некоторая теория по этому поводу. Во всём виноваты ats51 и Уралмашзавод. Т.к. раньше канал был другой. Также я имею некоторую информацию, что Уралмашзавод (далее Уралмаш) недавно вводил некий резервный канал... Возможно следующее, Уралмаш воспользовался "Строим вместе", половина канала идёт Уралмашу, половина остальным. В 1:00 Уралмаш по каким либо причинам освобождает канал и все вздыхают свободно. Потом опять занимает, и все отдыхают. АТС51 не справляется с трафиком Теленета на частичном канале и паразитный трафик создаёт много коллизий между шлюзом Теленета, Уралмашевской циской и АТС. Далее возникает вопрос, а каким образом вся эта бодяга влияет на скорость в локалке? На самом деле вариантов масса. Например, всё дело в MAC авторизации/проверках. Для этого требуется участие шлюза, а он перегружен паразитным трафиком...

Хочу ещё заметить, что в сети наблюдается какой-то паразитный трафик со стороны MAC 0000CA0363B4

1. Вообще изначально диспут разгорался с того - как глючат провода ( глючат они редко).

2. Всем веруующим и не верующим рекомендую поставить следующий опыть:
Взять 3 компа и хаб, соеденить это все на 10 мб. на втором компе поставить до первого компа обычный пинг, он будет равен 1 мс. На витую пару третьего компа поставить сдвоенный резистор ( для чистоты эксперимента) и поставить 3 сессии пингов по 40000 байт и две сессии по 32 байта. Затем начинайте с разной интенсивностью крутить резистор. КОГДА В РЕЗУЛЬТАТЕ ЭТОГО ПИНГ МЕЖДУ ВТОРЫМ И ПЕРВЫМ КОМПОМ СТАНЕТ ОТЛИЧНЫМ ОТ 1МС - поставте себе фофан, или два.

Все, устал спорить.

Г()LLIJt - ок, мне не лень, я поставлю именно такой эксперимент, даже самому интересно.
Если не получится - что будем делать? Придешь честно свой фофан получать?

Не за дело вы ребята решили забить друг друга щелбанами :D.
Вот толькочто гроза снова на Ботанике била...
У Интека опять потерь нет, все в чате, никто не вылетел, по пингам видно было как защиты отработали. А как у Теленета?

Вэри гут, сижу на связи вот с работы:-)
И дома точка тоже тьфу-тьфу.

Деда, ты в отличии от нас живешь и работаешь в правильных местах. Мы рады , что у тебя все сложилось. :-)

Вывод: перезжайте :-)

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

Да, на 3COM, возможно опыт и не пропрет, надо что-нить реальное.

[Сообщение изменено пользователем 28.07.2003 17:33]

Что вы, у нас вполне реальные rtl8139, даже хуже тех которыми телесеть монтаж ведет...

Ох-ох...
Еще и размер пакета такой большой, аж 40000.
Только вот незадача, передаваться кадры будут только по 1400 с хвостиком, или сколько там в МТУ прописано... Так что увеличивая цифирку в пинге получаем только одно - большую вероятность потери пинга.
Ну типа если в караване одного верблюда грохнут, весь караван считается потерянным. :-)

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

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

Nag.ru - вряд ли на линиях сопротивления скачут настолько быстро, так что ограничимся рукой :-)