Задержки пинга.

Все остальное

Задержки пинга.

Сообщение Андрей » 30 июн 2010, 09:34

Привет всем.
Не знаю как назвать тему, т.к. с таким сталкиваюсь в первые.
Проблема в пингах. иллюстрации говорят сами за себя:
Э1.gif
Э2.gif


Скрины делал одновременно с 2х окон.
На пути пингования стоит сервер доступа NAS с поднятым NAT и роутер CISCO 7505.
Пинги, на интерфейс CISCO 7505, смотрящего в сторону провайдера, идут нормально - без потерь.

Подскажите, в чем может быть проблема?
Заранее благодарен.
.ı|ı..ı|ı.
Андрей
местный житель
 
Сообщения: 1028
Зарегистрирован: 14 янв 2009, 13:37
Откуда: Оренбургская область

Re: Задержки пинга.

Сообщение lehisnoe » 30 июн 2010, 09:53

Подскажите, в чем может быть проблема?

В нагрузке на оборудование либо его конфигурации по дороге к IP назначения.

поставь winmtr и посмотри, на каком хопе начинаются проблемы.
No users
No troubles
No money
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
lehisnoe
Site Admin
 
Сообщения: 539
Зарегистрирован: 11 июн 2008, 14:09
Откуда: Moscow

Re: Задержки пинга.

Сообщение Андрей » 30 июн 2010, 10:54

WinMTR - интересная программка.
Вот её результаты.
WinMTR.gif

172.16.0.1 - IP nat на NAS.
*.253 - ифейс CISCO 7505 смотрящий в мою сторону.
*.185 - gw провайдера.

Судя по наблюдениям - тормозит везде. И на NAS и на входном интерфейсе CISCO (*.253) и у провайдера. Больше всего на gw, конечно.

Пробовал гуглить по вопросу. Наткнулся на интересную статью:
http://dreamcatcher.ru/2009/11/30/Оптимизация-tcp/
Интересная информация указана о FreeBSD:
FreeBSD

Добавьте это в /etc/sysctl.conf и перезагрузитесь:

kern.ipc.maxsockbuf=16777216
net.inet.tcp.rfc1323=1

В FreeBSD 7.0 добавлена функция автокогфигурирования буферов. Но значения их можно отредактировать, так как по умолчанию буферы 256 KB, а это очень мало:

net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216

Для общего развития покажу еще несколько параметров, но их дефолтные значения и так хороши:

net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=8192 # step size
net.inet.tcp.recvbuf_auto=1 # enabled
net.inet.tcp.recvbuf_inc=16384 # step size

У FreeBSD есть кое-какие ограничения, включенным по умолчанию. Это хорошо для модемных подключений, но может быть вредно для пропускной способности на высокоскоростных каналах. Если Вы хотите «нормальное» TCP Reno, сделайте следущее:

net.inet.tcp.inflight.enable=0

По умолчанию, FreeBSD кэширует подробности подключения, такие как порог slow start и размер окна перегрузки(congestion windows) с предыдущего подключения на тот же самый хост в течение 1 часа. В то время как это хорошая идея для веб-сервера, но плохая для тестирования пропускной способности, поскольку 1 большой случай перегрузки задушит производительность в течение следующего часа. Чтобы уменьшить этот эффект, установите это:

net.inet.tcp.hostcache.expire=1

В этом случае мы будем все еще кэшировать значения в течение 5 минут, по причинам, описанным в этой статье от Centre for Advanced Internet Architectures (CAIA) at Swinburne University in Autralia. В ней вы также найдете другую интересную информацию о тюнинге FreeBSD. Также можно использовать H-TCP patch for FreeBSD

Для получения информации о тюнинге NetBSD, обратитесь к этой статье.

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


интересно надо ли оно?
.ı|ı..ı|ı.
Андрей
местный житель
 
Сообщения: 1028
Зарегистрирован: 14 янв 2009, 13:37
Откуда: Оренбургская область

Re: Задержки пинга.

Сообщение lehisnoe » 30 июн 2010, 13:05

А потери при пинге 172.16.0.1 пакетами по 1450 байт есть?
No users
No troubles
No money
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
lehisnoe
Site Admin
 
Сообщения: 539
Зарегистрирован: 11 июн 2008, 14:09
Откуда: Moscow

Re: Задержки пинга.

Сообщение Андрей » 30 июн 2010, 14:32

lehisnoe писал(а):А потери при пинге 172.16.0.1 пакетами по 1450 байт есть?

Было зарезано pf'ом.
Сейчас разрешил пинги, но на 530 пакетов получено 528.
При нагрузке на внешний ифейс ~5.5 kpps и трафике 29 мбит/с.

на gw провайдера из 530 пакетов дошло только 504.

Самое интересное, что ошибок на ифейсе нет:
Код: Выделить всё
# ifconfig | grep ng0
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396

а это netstat
Код: Выделить всё
              input          (ng0)           output
   packets  errs      bytes    packets  errs      bytes colls
        61     0       2604        109     0     114853     0
        37     0       1480         70     0      76190     0
        38     0       1520         69     0      72574     0
        18     0        720         32     0      34048     0
        38     0       2826         66     0      68963     0
        17     0        680         32     0      34048     0
        36     0       1440         66     0      68176     0
        35     0       1400         65     0      68136     0
        26     0       1568         31     0      34008     0
        19     0        844         34     0      43396     0
        30     0       1296         51     0      58308     0
        25     0       3400         23     0      21810     0
        32     0       1436         48     0      54789     0
        21     0        924         34     0      37338     0
        14     0        584         25     0      28994     0
        32     0       4012         48     0      53113     0
        11     0        476         19     0      22836     0
        56     0       2240        109     0     117533     0
        54     0       2160        105     0     108228     0
        13     0        520         22     0      24411     0
        45     0       2028         70     0      78226     0



Только сейчас предостерегло немного - mtu на ng0 - 1396. Я так понимаю, что это вообще не гуд?
Хотя вообще все ng ифейсы с установленным mtu 1396.
.ı|ı..ı|ı.
Андрей
местный житель
 
Сообщения: 1028
Зарегистрирован: 14 янв 2009, 13:37
Откуда: Оренбургская область

Re: Задержки пинга.

Сообщение lehisnoe » 30 июн 2010, 17:42

Андрей писал(а):
lehisnoe писал(а):А потери при пинге 172.16.0.1 пакетами по 1450 байт есть?

Было зарезано pf'ом.

О, как... А как же ты пинговал и делал трассы раньше? Или же у тебя было запрещено хождение фрагментированных пакетов?
Андрей писал(а):Сейчас разрешил пинги, но на 530 пакетов получено 528.

По локалке не должно быть потерь вообще, тут они есть, но ничтожно малы (0,4%).
Андрей писал(а):При нагрузке на внешний ифейс ~5.5 kpps и трафике 29 мбит/с.
на gw провайдера из 530 пакетов дошло только 504.

5% - это уже много.
Что бы исключить NAS из цепочки разбора, запость вывод top -SH и результаты пинга пакетами по 1450 байт IP адреса, висящего на ифейсе NAS в сторону циски 7505.
Андрей писал(а):Самое интересное, что ошибок на ифейсе нет:
а это netstat
Код: Выделить всё
              input          (ng0)           output
   packets  errs      bytes    packets  errs      bytes colls
        61     0       2604        109     0     114853     0
...

Дык смотреть ошибки-то нужно на физическом ифейсе, на ифейсе ng ошибки ты увидишь только тогда, когда уже всему вокруг придет ппц :)
Андрей писал(а):
Код: Выделить всё
# ifconfig | grep ng0
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396

Только сейчас предостерегло немного - mtu на ng0 - 1396. Я так понимаю, что это вообще не гуд?
Хотя вообще все ng ифейсы с установленным mtu 1396.

Мту рулишь ты ;-)
Смотри в настройки mpd - какое значение mtu ты там задал, такое на ифейсе и будет
No users
No troubles
No money
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
lehisnoe
Site Admin
 
Сообщения: 539
Зарегистрирован: 11 июн 2008, 14:09
Откуда: Moscow

Re: Задержки пинга.

Сообщение Андрей » 01 июл 2010, 09:52

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

icmp-траффик на этот Ip был закрыт, хотя каким-то образом, при трассировке, определялся ip, через который проходит пакет. pf.conf имеет строки:
Код: Выделить всё
set timeout { icmp.first 20, icmp.error 10 }
...
pass in quick inet proto icmp from any to 10.10.2.2 icmp-type echoreq keep state


lehisnoe писал(а):запость вывод top -SH

Код: Выделить всё
last pid: 32709;  load averages:  0.70,  0.66,  0.60   up 129+16:44:31 12:35:45
106 processes: 5 running, 83 sleeping, 18 waiting
CPU:  0.2% user,  0.0% nice, 16.2% system,  1.1% interrupt, 82.5% idle
Mem: 57M Active, 1445M Inact, 232M Wired, 5748K Cache, 112M Buf, 260M Free
Swap: 10G Total, 10G Free

  PID USERNAME  PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   14 root      171 ki31     0K     8K CPU0   0 2709.9 93.55% idle: cpu0
   13 root      171 ki31     0K     8K RUN    1 2840.2 89.70% idle: cpu1
   11 root      171 ki31     0K     8K CPU3   3 2750.4 86.87% idle: cpu3
   12 root      171 ki31     0K     8K CPU2   2 2456.3 75.88% idle: cpu2
   33 root      -68    -     0K     8K -      2 429.8H 17.68% em0 taskq
   34 root      -68    -     0K     8K -      0 175.7H  8.50% em1 taskq
    2 root      -68    -     0K     8K sleep  3 186.7H  8.40% ng_queue0
    4 root      -68    -     0K     8K sleep  2 186.6H  8.25% ng_queue2
    5 root      -68    -     0K     8K sleep  1 186.5H  8.06% ng_queue3
    3 root      -68    -     0K     8K sleep  3 186.3H  7.76% ng_queue1
   15 root      -32    -     0K     8K WAIT   0 246.7H  3.27% swi4: clock sio
   57 root       20    -     0K     8K syncer 0 310:02  0.20% syncer
60155 flowtools  44    0  3484K  1616K select 3  29.2H  0.00% flow-capture
57042 root       44    0 62228K 32864K select 0 670:41  0.00% mpd5
   18 root       44    -     0K     8K -      0 534:43  0.00% yarrow
   51 root        8    -     0K     8K pftm   1 192:40  0.00% pfpurge
60228 flowtools  44    0  3740K  1856K select 3 141:09  0.00% flow-fanout

lehisnoe писал(а):результаты пинга пакетами по 1450 байт IP адреса, висящего на ифейсе NAS в сторону циски 7505

Код: Выделить всё
# ping -s 1442 ***.***.***.251
PING ***.***.***.251 (***.***.***.251): 1442 data bytes
1450 bytes from ***.***.***.251: icmp_seq=0 ttl=64 time=6.270 ms
1450 bytes from ***.***.***.251: icmp_seq=1 ttl=64 time=5.604 ms
1450 bytes from ***.***.***.251: icmp_seq=2 ttl=64 time=5.363 ms
1450 bytes from ***.***.***.251: icmp_seq=3 ttl=64 time=5.545 ms
1450 bytes from ***.***.***.251: icmp_seq=4 ttl=64 time=5.557 ms
1450 bytes from ***.***.***.251: icmp_seq=5 ttl=64 time=5.474 ms
1450 bytes from ***.***.***.251: icmp_seq=6 ttl=64 time=5.389 ms
1450 bytes from ***.***.***.251: icmp_seq=7 ttl=64 time=7.020 ms
1450 bytes from ***.***.***.251: icmp_seq=8 ttl=64 time=5.507 ms
1450 bytes from ***.***.***.251: icmp_seq=9 ttl=64 time=5.356 ms
1450 bytes from ***.***.***.251: icmp_seq=10 ttl=64 time=5.618 ms
1450 bytes from ***.***.***.251: icmp_seq=11 ttl=64 time=5.606 ms
1450 bytes from ***.***.***.251: icmp_seq=12 ttl=64 time=5.709 ms
1450 bytes from ***.***.***.251: icmp_seq=13 ttl=64 time=5.655 ms
1450 bytes from ***.***.***.251: icmp_seq=14 ttl=64 time=5.551 ms
1450 bytes from ***.***.***.251: icmp_seq=15 ttl=64 time=5.585 ms
1450 bytes from ***.***.***.251: icmp_seq=16 ttl=64 time=5.572 ms
1450 bytes from ***.***.***.251: icmp_seq=17 ttl=64 time=6.052 ms
1450 bytes from ***.***.***.251: icmp_seq=18 ttl=64 time=5.647 ms
1450 bytes from ***.***.***.251: icmp_seq=19 ttl=64 time=5.672 ms
1450 bytes from ***.***.***.251: icmp_seq=20 ttl=64 time=5.753 ms
1450 bytes from ***.***.***.251: icmp_seq=21 ttl=64 time=5.567 ms
1450 bytes from ***.***.***.251: icmp_seq=22 ttl=64 time=5.796 ms
1450 bytes from ***.***.***.251: icmp_seq=23 ttl=64 time=5.629 ms
1450 bytes from ***.***.***.251: icmp_seq=24 ttl=64 time=5.588 ms
1450 bytes from ***.***.***.251: icmp_seq=25 ttl=64 time=21.843 ms
1450 bytes from ***.***.***.251: icmp_seq=26 ttl=64 time=5.627 ms
1450 bytes from ***.***.***.251: icmp_seq=27 ttl=64 time=6.766 ms
1450 bytes from ***.***.***.251: icmp_seq=28 ttl=64 time=5.673 ms
1450 bytes from ***.***.***.251: icmp_seq=29 ttl=64 time=5.856 ms
1450 bytes from ***.***.***.251: icmp_seq=30 ttl=64 time=5.736 ms
1450 bytes from ***.***.***.251: icmp_seq=31 ttl=64 time=5.554 ms
1450 bytes from ***.***.***.251: icmp_seq=32 ttl=64 time=5.633 ms
1450 bytes from ***.***.***.251: icmp_seq=33 ttl=64 time=5.655 ms
1450 bytes from ***.***.***.251: icmp_seq=34 ttl=64 time=5.734 ms
1450 bytes from ***.***.***.251: icmp_seq=35 ttl=64 time=5.606 ms
1450 bytes from ***.***.***.251: icmp_seq=36 ttl=64 time=5.690 ms
1450 bytes from ***.***.***.251: icmp_seq=37 ttl=64 time=5.446 ms
1450 bytes from ***.***.***.251: icmp_seq=38 ttl=64 time=5.495 ms
1450 bytes from ***.***.***.251: icmp_seq=39 ttl=64 time=5.544 ms
1450 bytes from ***.***.***.251: icmp_seq=40 ttl=64 time=5.524 ms
1450 bytes from ***.***.***.251: icmp_seq=41 ttl=64 time=5.341 ms
1450 bytes from ***.***.***.251: icmp_seq=42 ttl=64 time=5.473 ms
1450 bytes from ***.***.***.251: icmp_seq=43 ttl=64 time=5.715 ms
1450 bytes from ***.***.***.251: icmp_seq=44 ttl=64 time=5.848 ms
1450 bytes from ***.***.***.251: icmp_seq=45 ttl=64 time=5.584 ms
1450 bytes from ***.***.***.251: icmp_seq=46 ttl=64 time=5.565 ms
1450 bytes from ***.***.***.251: icmp_seq=47 ttl=64 time=5.634 ms
1450 bytes from ***.***.***.251: icmp_seq=48 ttl=64 time=5.597 ms
1450 bytes from ***.***.***.251: icmp_seq=49 ttl=64 time=5.618 ms
1450 bytes from ***.***.***.251: icmp_seq=50 ttl=64 time=5.500 ms
1450 bytes from ***.***.***.251: icmp_seq=51 ttl=64 time=5.516 ms
1450 bytes from ***.***.***.251: icmp_seq=52 ttl=64 time=5.666 ms
1450 bytes from ***.***.***.251: icmp_seq=53 ttl=64 time=5.641 ms
1450 bytes from ***.***.***.251: icmp_seq=54 ttl=64 time=5.500 ms
1450 bytes from ***.***.***.251: icmp_seq=55 ttl=64 time=5.614 ms
1450 bytes from ***.***.***.251: icmp_seq=56 ttl=64 time=5.466 ms
1450 bytes from ***.***.***.251: icmp_seq=57 ttl=64 time=5.380 ms
1450 bytes from ***.***.***.251: icmp_seq=58 ttl=64 time=5.544 ms
1450 bytes from ***.***.***.251: icmp_seq=59 ttl=64 time=5.491 ms
1450 bytes from ***.***.***.251: icmp_seq=60 ttl=64 time=5.367 ms
1450 bytes from ***.***.***.251: icmp_seq=61 ttl=64 time=5.509 ms
1450 bytes from ***.***.***.251: icmp_seq=62 ttl=64 time=5.574 ms
1450 bytes from ***.***.***.251: icmp_seq=63 ttl=64 time=5.566 ms
1450 bytes from ***.***.***.251: icmp_seq=64 ttl=64 time=6.378 ms
1450 bytes from ***.***.***.251: icmp_seq=65 ttl=64 time=5.523 ms
1450 bytes from ***.***.***.251: icmp_seq=66 ttl=64 time=5.373 ms
1450 bytes from ***.***.***.251: icmp_seq=67 ttl=64 time=5.385 ms
1450 bytes from ***.***.***.251: icmp_seq=68 ttl=64 time=5.655 ms
1450 bytes from ***.***.***.251: icmp_seq=69 ttl=64 time=5.339 ms
1450 bytes from ***.***.***.251: icmp_seq=70 ttl=64 time=5.834 ms
1450 bytes from ***.***.***.251: icmp_seq=71 ttl=64 time=5.679 ms
1450 bytes from ***.***.***.251: icmp_seq=72 ttl=64 time=6.020 ms
1450 bytes from ***.***.***.251: icmp_seq=73 ttl=64 time=5.615 ms
1450 bytes from ***.***.***.251: icmp_seq=74 ttl=64 time=5.590 ms
1450 bytes from ***.***.***.251: icmp_seq=75 ttl=64 time=5.680 ms
1450 bytes from ***.***.***.251: icmp_seq=76 ttl=64 time=5.624 ms
1450 bytes from ***.***.***.251: icmp_seq=77 ttl=64 time=5.683 ms
1450 bytes from ***.***.***.251: icmp_seq=78 ttl=64 time=5.536 ms
1450 bytes from ***.***.***.251: icmp_seq=79 ttl=64 time=5.414 ms
1450 bytes from ***.***.***.251: icmp_seq=80 ttl=64 time=5.633 ms
1450 bytes from ***.***.***.251: icmp_seq=81 ttl=64 time=5.579 ms
1450 bytes from ***.***.***.251: icmp_seq=82 ttl=64 time=5.601 ms
1450 bytes from ***.***.***.251: icmp_seq=83 ttl=64 time=5.665 ms
1450 bytes from ***.***.***.251: icmp_seq=84 ttl=64 time=5.617 ms
1450 bytes from ***.***.***.251: icmp_seq=85 ttl=64 time=5.493 ms
1450 bytes from ***.***.***.251: icmp_seq=86 ttl=64 time=6.190 ms
1450 bytes from ***.***.***.251: icmp_seq=87 ttl=64 time=5.583 ms
1450 bytes from ***.***.***.251: icmp_seq=88 ttl=64 time=5.632 ms
1450 bytes from ***.***.***.251: icmp_seq=89 ttl=64 time=5.641 ms
1450 bytes from ***.***.***.251: icmp_seq=90 ttl=64 time=5.843 ms
1450 bytes from ***.***.***.251: icmp_seq=91 ttl=64 time=5.745 ms
1450 bytes from ***.***.***.251: icmp_seq=92 ttl=64 time=5.607 ms
1450 bytes from ***.***.***.251: icmp_seq=93 ttl=64 time=6.600 ms
1450 bytes from ***.***.***.251: icmp_seq=94 ttl=64 time=5.656 ms
1450 bytes from ***.***.***.251: icmp_seq=95 ttl=64 time=5.611 ms
1450 bytes from ***.***.***.251: icmp_seq=96 ttl=64 time=5.597 ms
1450 bytes from ***.***.***.251: icmp_seq=97 ttl=64 time=5.630 ms
1450 bytes from ***.***.***.251: icmp_seq=98 ttl=64 time=5.355 ms
1450 bytes from ***.***.***.251: icmp_seq=99 ttl=64 time=5.301 ms
1450 bytes from ***.***.***.251: icmp_seq=100 ttl=64 time=5.487 ms
^C
--- ***.***.***.251 ping statistics ---
101 packets transmitted, 101 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.301/5.808/21.843/1.626 ms


lehisnoe писал(а):Мту рулишь ты Смотри в настройки mpd - какое значение mtu ты там задал, такое на ифейсе и будет

Мож я что не понимаю. :):
Код: Выделить всё
# cat /usr/local/etc/mpd5/mpd.conf | grep mtu
        set link mtu 1460

Получается, что mtu для ng должен задаваться равный 1460, а он задается 1396.
.ı|ı..ı|ı.
Андрей
местный житель
 
Сообщения: 1028
Зарегистрирован: 14 янв 2009, 13:37
Откуда: Оренбургская область

Re: Задержки пинга.

Сообщение Андрей » 01 июл 2010, 13:01

Я почему-то се болше склоняюсь в сторону NAS.
Загуглил по вопросу - нашел что-то типа:
Если кому будет необходимо, проблема была в данном параметре - hw.igb.lro=0
Есго надо было перенести в sysctl.conf (sysctl -w hw.igb.0.enable_lgo = 0


Оно ли?

На что давить в настройках sysctl?
Если не трудно - посоветуйте, какие переменные поднять, а какие занизить. Мне кажется вся проблема в этом. Т.к. почти все tcp сессии глючат.
На форуме нага нашел рекомендации, но для мпд3 и фри6.

Подозреваю в сторону:
Код: Выделить всё
# sysctl -a | grep net.inet.tcp.sendbuf_max
net.inet.tcp.sendbuf_max: 262144
# sysctl -a | grep net.inet.tcp.recvbuf_max
net.inet.tcp.recvbuf_max: 262144

Некоторые люди советуют поднять его до 16777216.

Вообще, если пытаться исключить глюки на NAS - я думаю попробовать пустить трафик через него на максимальной загрузке, только не через gw прова, а только через сам NAS. А дальше - не знаю. Может циска дохлая, а может еще что-то, хотя по числу пакетов - на ифейсах всего около 5-6 kpps. несколько странное поведение.
.ı|ı..ı|ı.
Андрей
местный житель
 
Сообщения: 1028
Зарегистрирован: 14 янв 2009, 13:37
Откуда: Оренбургская область

Re: Задержки пинга.

Сообщение Андрей » 02 июл 2010, 08:41

РПерекинул файл со своего компа через нат на ноут.
Потерь нет. Скорость ~8 мб/с (при текущей нагрузке 30мбит/с). Общее число проходящих пакетов через нат составило ~10kpps.
Проблема обнаружилась на cisco7505. Точнее на порту, который смотрит на гейт прова.
Проблема несколько не стандартная. Опишу последовательность:
1. Сбрасываю статистику по порту.
2. Выставляю полный дуплекс. (автосогласование не поддерживается). Начинаются CRC ошибки и коллизии на приходящих пакетах.
3. Сбрасываю статистику по порту.
4. Выставляю полудуплекс. (автосогласование не поддерживается). Начинаются CRC ошибки и коллизии на исходящих пакетах.

Созванивался с провайдером - у него на портах автосогласование. Попробуем принудительно выставить дуплекс - не знаю что из этого выйдет.
.ı|ı..ı|ı.
Андрей
местный житель
 
Сообщения: 1028
Зарегистрирован: 14 янв 2009, 13:37
Откуда: Оренбургская область

Re: Задержки пинга.

Сообщение root » 05 июл 2010, 11:20

Андрей писал(а):Созванивался с провайдером - у него на портах автосогласование. Попробуем принудительно выставить дуплекс - не знаю что из этого выйдет.

если на одной стороне выставляется жестко, то и на второй стороне нужно сделать тоже самое
CRC ошибки это плохо, отсюда и потери.
Если жесткое выставление не поможет, то переобожмите кабель, опять же с двух сторон, смените порты на оборудовании.
С уважением, root

Изображение
------------
www.mega-net.ru - IT аутсорсинг
Аватара пользователя
root
Site Admin
 
Сообщения: 1894
Зарегистрирован: 11 июн 2008, 13:05
Откуда: Moscow, Russia

След.

Вернуться в Разное (networks)

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15

cron