+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Демо настройки очереди "key"

Демо настройки очереди "key", RouterOS

jsuter

Guest

14.07.2006 05:12:00

Я тестирую старую карту etinc pcisync/2, которая завалялась у меня, в старом компьютере с использованием ключа 'demo'. Сейчас через неё проходит T1, но не могу заставить настройки очереди работать. Настройки очереди заблокированы в демо-режиме? Изменение типа synchronous-default не повлияло на производительность вообще. Я убедился, что интерфейс mtsync1 установлен как synchronous-default. В остальном всё выглядит идеально. Если управление очередью заработает, я куплю ещё одну лицензию…

normis Guest	#2 0 14.07.2006 05:35:00 Демонстрация должна быть ограничена одним правилом очереди.

janisk Guest	#3 0 14.07.2006 05:40:00 Для тестирования лучше использовать 24-часовой пробный период.

jsuter Guest	#4 0 14.07.2006 05:42:00 Эмм, извини, я использую 24-часовой формат… Ой.

janisk Guest	#5 0 14.07.2006 05:46:00 Ключ на 24 часа не имеет ограничений, кроме лимита в 24 часа, в остальном он полностью функционален.

jsuter Guest	#6 0 14.07.2006 05:52:00 Хм, значит, настройки очереди не повлияли на время пинга (56 байт) при загрузке (пакеты по 1500 байт на максимальной скорости линии)… Очень странно. Покопаюсь глубже завтра утром (тут уже 2 часа ночи).

normis

Guest

14.07.2006 05:54:00

ping times? Это вообще не способ тестирования. Попробуй сделать простую очередь для веб-трафика (порт 80) и попробуй что-нибудь скачать. Потом останови скачивание, отключи очередь и попробуй скачать снова. [admin@MikroTik] queue simple> add name=Limit-Local interface=Local target-address=192.168.0.0/24 max-limit=65536/131072 — простое правило очереди, которое будет ограничивать скорость скачивания до 128 Кбит/с и загрузки до 64 Кбит/с для клиентов в сети 192.168.0.0/24, обслуживаемых интерфейсом Local.

balimore Guest	#8 0 14.07.2006 06:44:00 Не, идей для ‘DEMO’ ключа Mikrotik слишком много аргументов для каких-то правдоподобных и простых способов,… Мира всем BalimoreDOTcom

jsuter

Guest

14.07.2006 07:04:00

Ну, это будет очередь IP. Мне нужно настроить очередь интерфейса, чтобы поддерживать стабильную работу. С моим старым Cisco, выбор в основном fifo (pfifo), red и fair-queue (sfq). На Cisco, установка интерфейса в режим fifo («no fair-queue»/«no random-early-detection») даст мне ту же производительность, что и сейчас. Я загружаю файлы, все сервисы начинают лагать на 150-250 мс. Если включить sfq или red, время rtt обычно будет ниже 40 мс, даже когда линия загружена практически на максимум (98%+). Я знаю, что при использовании MT в качестве PPPoE или PPTP-сервера, настройка очереди интерфейса работает (pcq в этой ситуации просто потрясающий), но здесь это не работает. Причина, по которой я не хочу использовать очередь, основанную на IP, заключается в том, что мне пришлось бы снизить скорость линии как минимум на 15%, чтобы гарантировать, что очередь tx интерфейса, не управляемая, не переполнится.

jsuter

Guest

#10

14.07.2006 17:42:00

Мой ответ вчера вечером не особо-то и имел смысл… Попробую объяснить лучше… Когда работаешь с PPP по синхронному последовательному интерфейсу, предсказуемость доставки пакетов примерно как у полнодуплексного Ethernet-порта, только значительно ниже (в данном случае 1536 кбит/с). Нет никакого управления потоком, как на обычных последовательных линиях, и скорость всегда одинаковая. Она определяется синхронным сигналом времени, отправляемым телефонной компанией. Судя по всему, на синхронном PPP-интерфейсе есть буфер PFIFO (пакеты, отправленные в порядке первоначальной обработки), примерно на 20 пакетов. Для простоты представим, что T1 на 1536 кбит/с передаёт 190 КБ/с… Буфер на 20 пакетов @ 1500 байт каждый = 35 КБ… 35/190 = 0.1578 = 157 мс потенциальной задержки в пути передачи данных… Ваше предложение – поставить «медленнее» очередь перед буфером интерфейса. Это «вроде бы» сработает в нормальных условиях, но с существенной потерей производительности (мне пришлось бы установить скорость около 1.2-1.3 Мбит/с, чтобы интерфейсный буфер вообще не успевал заполняться). Было бы гораздо эффективнее управлять самим буфером интерфейса… Я знаю, что некоторые драйверы интерфейсов Linux не имеют "хуков" для управления очередью, и, возможно, драйвер DSCC4 относится к их числу, я ещё не проверял.

Eugene Guest	#11 0 24.07.2006 07:57:00 [eugene@SM_BGP] > /queue interface print INTERFACE QUEUE 0 ether1 ethernet-default 1 ether2 ethernet-default default [eugene@SM_BGP] > /queue type print 0 name="default" kind=pfifo pfifo-limit=50 1 name="ethernet-default" kind=pfifo pfifo-limit=50 2 name="wireless-default" kind=sfq sfq-perturb=5 sfq-allot=1514 3 name="synchronous-default" kind=red red-limit=60 red-min-threshold=10 red-max-threshold=50 red-burst=20 red-avg-packet=1000 4 name="hotspot-default" kind=sfq sfq-perturb=5 sfq-allot=1514 5 name="default-small" kind=pfifo pfifo-limit=10 [eugene@SM_BGP] >

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры