Mancubus Posted August 23, 2005 Posted August 23, 2005 От чего зависит параметр time при пинге? Впоследнее время она начал расходиться от 30 до 120мс. Может ли это влиять на скорость? Вставить ник Quote
Sirco Posted August 23, 2005 Posted August 23, 2005 Параметер Тиме указывает на скорость прохождения пакета до адресата и обратно . В результате у тебя или загружен канал или загружен _очень_сильно_ отвечающий комп или очень не качественная среда передачи . Параметер тиме не может влиять на скорость передачи - он просто указывает что канал загружен и соответственно тебе прийдеться с кем-то делиться .... тойсь другими словами твой вопрос поставлен не корректно . Если ты хочеш услышать еще подробности - надо более подробно описать ситуацию... Вставить ник Quote
Mancubus Posted August 23, 2005 Author Posted August 23, 2005 Прошу прощения, профессор ;) На самом деле Ваше повествование подтвердило мои предоположения. У меня сейчас начинается самое интересное, всем юзерам становится тесно в канале на 100Мб. Тут напрашивается только один вывод расширяться до 1Гб, но пока не имеется ыизической базы. Врема подскочило совсем недавно, порядка 2-3х дней назад. Кстати насчет скорости... как я понимаю скорость это ПЛ(пионер лагерь =) все измеряется скоростью прохождения пакетов? Некоторые клиенты стали жаловатся на маленькую скорость скачивания с FTP сайтов. Это как-нить связано? Вставить ник Quote
Shiva Posted August 23, 2005 Posted August 23, 2005 Mancubus, ты сам ответил на свой вопрос Вставить ник Quote
Mancubus Posted August 23, 2005 Author Posted August 23, 2005 Если честно, очень жаль. Ждал этого момента, а он пришел немного не по планам.... Вставить ник Quote
smsm Posted August 23, 2005 Posted August 23, 2005 интересно, гига надолго хватит ? Вставить ник Quote
Mancubus Posted August 23, 2005 Author Posted August 23, 2005 Хотя бы хватит запаса прочности, т.к. одномод предпологает до 10Тбит, а вот многомод, который сейчас имею в большом колличестве... ноу комментс. Хотя вопрос риторический. Вставить ник Quote
grama Posted August 24, 2005 Posted August 24, 2005 Разговаривал я тут с одним Гуру на этом форуме и он "озвучил" мысль с которой я согласен : когда не хватает Fasta Eth т е 100 Мб это говорит о не правильном построении сети. А пользователи могут загадить и 10 Gb/ps. Вставить ник Quote
grama Posted August 24, 2005 Posted August 24, 2005 Хотя бы хватит запаса прочности, т.к. одномод предпологает до 10Тбит, а вот многомод, который сейчас имею в большом колличестве... ноу комментс.Хотя вопрос риторический. Может всеже 10 Гигабит ? Если правда одномод позволяет Терабиты запускать, то это просто очень и очень круто :) Вставить ник Quote
Mancubus Posted August 24, 2005 Author Posted August 24, 2005 Спорить по этому поводу не буду, т.к. это приводит к флейму. Построено все, почти корректно. =) Вставить ник Quote
AvrAlex Posted August 25, 2005 Posted August 25, 2005 Кстати немного не потеме.. но у нас тоже странная тенденция с пингами иногда... 25008 bytes from 192.168.20.40: icmp_seq=18 ttl=255 time=38.717 ms 25008 bytes from 192.168.20.40: icmp_seq=19 ttl=255 time=38.826 ms 25008 bytes from 192.168.20.40: icmp_seq=20 ttl=255 time=38.692 ms хотя!!! Это пинг управляемого свича с сервера, который включен 1 метром витухи... Какие мысли? Вопрос номер 2... Чем собрать (какое ПО) статистику по SNMP-протоколу с управляемых свичей из-под Винды... хотелось бы видеть загрузку канала на некоторых участках... Вставить ник Quote
Solo Posted August 25, 2005 Posted August 25, 2005 Чем собрать (какое ПО) статистику по SNMP-протоколу с управляемых свичей из-под Винды Зависит от свичей. Сейчас парактически ко всем известным свичам роизводители дают такое ПО. Если же такого нет, то либо покупать, либо делать самому. Если самому - пример Nagios+Apan Вставить ник Quote
FriedricH Posted August 25, 2005 Posted August 25, 2005 А сколько у вас юзверей в этом сегменте и не занимается ли кто широковещательными гоняниями всякой, в том числе и вирусной, ерунды? Вставить ник Quote
AvrAlex Posted August 25, 2005 Posted August 25, 2005 Машин в сегменте больше 2х сотен.... вирусы конечно бывают.... и кое-где бродкаст еще бегает... доделываемс. Но вот в чем парадокс... Пинг от сервера до управляемого свича (1 метр кабеля) при пакете 64 байта 64 bytes from 192.168.20.40: icmp_seq=2 ttl=255 time=1.632 ms 64 bytes from 192.168.20.40: icmp_seq=3 ttl=255 time=1.722 ms 64 bytes from 192.168.20.40: icmp_seq=4 ttl=255 time=1.729 ms Пинг от сервера до управляемого свича (1 метр кабеля) при пакете 25 Кбайт 25008 bytes from 192.168.20.40: icmp_seq=6 ttl=255 time=38.818 ms 25008 bytes from 192.168.20.40: icmp_seq=7 ttl=255 time=38.922 ms 25008 bytes from 192.168.20.40: icmp_seq=8 ttl=255 time=38.612 ms То есть предполагаем перегруз самого свича по трафику... но если я пингую управляемый свич в другом конце сети (то есть трафик идет через еще 3 таких же управляемых свича...) Пинг от сервера до управляемого свича в другом конце сети при пакете 25 Кбайт 25008 bytes from 192.168.20.170: icmp_seq=4 ttl=255 time=39.956 ms 25008 bytes from 192.168.20.170: icmp_seq=5 ttl=255 time=39.785 ms 25008 bytes from 192.168.20.170: icmp_seq=6 ttl=255 time=39.844 ms То есть нет "линейной" зависимости от колличества "пройденых" свичей... Может это особенность данных свичей (Asotel 1916/1924) и они просто дробят данные пакеты на большое колличество мелких? Вставить ник Quote
Nag Posted August 25, 2005 Posted August 25, 2005 Медленный пинг свитчей это не глюк вроде, а фича. Свитчи не нанимались на пинги отвечать - им коммутировать типа надо. ;-) Иначе кто-нить умный проц свитча перегрузить может... Вставить ник Quote
Nailer Posted August 25, 2005 Posted August 25, 2005 Но вот в чем парадокс...Пинг от сервера до управляемого свича (1 метр кабеля) при пакете 64 байта 64 bytes from 192.168.20.40: icmp_seq=2 ttl=255 time=1.632 ms 64 bytes from 192.168.20.40: icmp_seq=3 ttl=255 time=1.722 ms 64 bytes from 192.168.20.40: icmp_seq=4 ttl=255 time=1.729 ms Пинг от сервера до управляемого свича (1 метр кабеля) при пакете 25 Кбайт 25008 bytes from 192.168.20.40: icmp_seq=6 ttl=255 time=38.818 ms 25008 bytes from 192.168.20.40: icmp_seq=7 ttl=255 time=38.922 ms 25008 bytes from 192.168.20.40: icmp_seq=8 ttl=255 time=38.612 ms То есть предполагаем перегруз самого свича по трафику... но если я пингую управляемый свич в другом конце сети (то есть трафик идет через еще 3 таких же управляемых свича...) Пинг от сервера до управляемого свича в другом конце сети при пакете 25 Кбайт 25008 bytes from 192.168.20.170: icmp_seq=4 ttl=255 time=39.956 ms 25008 bytes from 192.168.20.170: icmp_seq=5 ttl=255 time=39.785 ms 25008 bytes from 192.168.20.170: icmp_seq=6 ttl=255 time=39.844 ms То есть нет "линейной" зависимости от колличества "пройденых" свичей... Может это особенность данных свичей (Asotel 1916/1924) и они просто дробят данные пакеты на большое колличество мелких? Все у вас правильно :-) Рассматривайте управляемый свитч как обычный коммутатор + маленький слабенький компьютер, подключенный через еще один скрытый порт (то бишь, если свитч 24-х портовый, то управляющий комп подключен интерфейсом в 25-ый порт, и вся эта конструкция находится в одном чипе). Когда пакет проходит через коммутатор, среднее время задержки составляет приблизительно 1мс. Если вы пингуете свитч (то есть управляющий компьютер), то пакет проходит через сам свитч (1 мс для режима store&forward, меньше для других вариантов) и попадает на компьютер (~25 мс для свитча норма). Соответственно, если вы пингуете свитч, стоящий за 3 свитча от вас, то суммарная задержка равна 1+1+1 + (1+25) = 29мс. Вставить ник Quote
AvrAlex Posted August 25, 2005 Posted August 25, 2005 Уф... успокоили... а то я уже начал сомниваться в "правильности" выбранной топологии и вендора... Вставить ник Quote
lanc Posted August 26, 2005 Posted August 26, 2005 Медленный пинг свитчей это не глюк вроде, а фича. Свитчи не нанимались на пинги отвечать - им коммутировать типа надо. ;-) Иначе кто-нить умный проц свитча перегрузить может... Верно! Через себя свитчи пакеты быстро коммутируют. А вот ответ на ПИНГ это уже софт свитча, т.е. его логика и ответ на ПИНГ этого самого свитча не влияет на производительность коммутации. DON'T PANIC Вставить ник Quote
Harmer Posted August 27, 2005 Posted August 27, 2005 Может это особенность данных свичей (Asotel 1916/1924) и они просто дробят данные пакеты на большое колличество мелких? Насколько я помню, максимальный размер ethernet-пакета - полкилобайта. Соответственно, если icmp (или другой ip-пакет) больше - он разбивается. Вставить ник Quote
Shiva Posted August 27, 2005 Posted August 27, 2005 lanc, А вот ответ на ПИНГ это уже софт свитча, т.е. его логика и ответ на ПИНГ этого самого свитча не влияет на производительность коммутации. Зато интенсивная комутация влияет на пинг, т.к. проц всё рано грузится филтрами всякими, лукапами и т.д. Так что чем больще нагрузка тем больше плывёт пинг. Harmer, Насколько я помню, максимальный размер ethernet-пакета - полкилобайта В 3 раза больше. На гигабите 9 кил. Вставить ник Quote
nlo1 Posted August 27, 2005 Posted August 27, 2005 Медленный пинг свитчей это не глюк вроде, а фича. Свитчи не нанимались на пинги отвечать - им коммутировать типа надо. ;-) Иначе кто-нить умный проц свитча перегрузить может... Добавлю лишь, что все это относится и к маршрутизаторам. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.