[Ansy]

Из косметических мелочей к веб-интерфейсу мои хотелки:

1. В статистике все же привести единицы измерения в порядок -- где Kbit, где Kbits... давайте уже объемы измерять в целых бАйтах (кто-то их сейчас частями передаёт?), а скорости -- в бИтах/с, ну и пакеты -- в штуках безразмерных. И обозначения единиц в колонку оглавления вынести, а то и так интерфейс тормозит, еще и единицы измерения рядом со значениями обновлять...
   
2. Автоматическое выравнивание ширины колонок в таблицах по значению. Иначе абсурд -- таблица с полупустыми полями не лезет в страницу, зато развернутый список обрезает наименования параметров так, что и не раскрыть их! Посмотрите хотя бы интерфейс вебморды Микротиков, чтоль, хотя это тоже не эталон для подражания, но все же.
   
3. Для мобильных устройств надо не меню в колоночку сворачивать, а графику лишнюю убирать -- кнопки, свистелки. Простой текстовый веб-интерфейс без оформительских наворотов. Когда получится приемлемо по скорости -- можно и для обычных компов приглашать дизайнеров. А у вас как-то наоборот получилось... кстати, у кого есть возможность вывести вебморду тестовой железки на реальник -- попробуйте основные странички на http://sitespeed.ru/ выставить и прогнать, ну вот явно какие-то косяки в интерфейсе вылезут.
   

P.S. У меня вышло только ДО авторизации протестить, но уже навскидку:

• ВЫКЛЮЧЕНО СЖАТИЕ СТРАНИЦЫ
  Включите в веб-сервере сжатие gzip или deflate, чтобы ускорить передачу данных по сети.
  
• СЛИШКОМ МНОГО CSS ИЛИ JS ФАЙЛОВ
  Объедините CSS файлы, чтобы уменьшить их количество. Поступите так же с JS файлами.
  

Учитывая, что CSS + JS дают в сумме ПОЛОВИНУ запросов, а по объему ЧЕТЫРЕ ПЯТЫХ сайта -- понятно, откуда тормоза при первичном открытии вебморды. К тому же скрипты грузятся последовательно и ждут окончания загрузки друг друга, судя по графику.

 

P.P.S. Анализировалась уже самая новая и свежая версия, 2.6.1 на ePMP 1000 Integrated.

Изменено 29 февраля, 2016 пользователем Ansy

[Sonne]

Ansy

 

Интересная информация!

 

Давайте попросим у камбиума пароль к системе и наведем с вебом порядок! Или хакнем уже :)

 

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

[m0sia]

JS и CSS с версии 2.6 кешируются на клиенте и не передаются, если вы уже заходили на этот адрес. Также если посмотреть profiler в Chrome, то вы увидите, что много времени тратится вовсе не на передачу данных, а на исполнение JS и постройку DOM. К сожалению ваши предложения не приведут к существенному ускорению. Более того включение сжатия может ухудшить ситуацию, если устройство нагружено трафиком.

Изменено 1 марта, 2016 пользователем m0sia

[Ansy]

JS и CSS с версии 2.6 кешируются на клиенте и не передаются, если вы уже заходили на этот адрес.

В общем, так оно и есть.

Также если посмотреть profiler в Chrome, то вы увидите, что много времени тратится вовсе не на передачу данных, а на исполнение JS и постройку DOM. К сожалению ваши предложения не приведут к существенному ускорению. Более того включение сжатия может ухудшить ситуацию, если устройство нагружено трафиком.

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

 

Вот еще графики загрузки -- но это только начальная страница перед логином, как в уже авторизованную readonly страницу запустить анализатор -- я не дотумкался пока, да и не моё это дело в общем-то -- сами попробуйте и оцените, зная всю "кухню" изнутри.

 

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

 

На вебинаре Cambium Networks я задавал вопрос насчет различия функционала вебморды и CLI/shell. Насколько понял из ответа -- основное это вебморда, и более того -- разработка шла именно от неё. Логично предположить, что ВНУТРИ ЖЕЛЕЗКИ вебсервер дергает инфу для отображения именно через API CLI, то есть используется ровно тот же механизм/источник данных, что и для CLI, со всеми теми же тормозами?

 

Опять же логично предположить, что "живость" интерфейса управления идет в низком приоритете относительно основных задач устройства. И если вычислительных ресурсов платформы "на всё про всё" не хватает -- только оптимизировать алгоритмы получения и оформления данных из ядра на интерфейсы управления и мониторинга. Возможно даже "в пределе" обойтись чем-то одним (например, SNMP + приложение). Но тут разработчикам опять же виднее.

Изменено 2 марта, 2016 пользователем Ansy

[m0sia]

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

 

Параллельной загрузкой должен заниматься браузер и именно так он и поступает(см скриншот). А статику конечно можно предварительно сжать, идея хорошая, но нетривиальная.

 

На вебинаре Cambium Networks я задавал вопрос насчет различия функционала вебморды и CLI/shell. Насколько понял из ответа -- основное это вебморда, и более того -- разработка шла именно от неё. Логично предположить, что ВНУТРИ ЖЕЛЕЗКИ вебсервер дергает инфу для отображения именно через API CLI, то есть используется ровно тот же механизм/источник данных, что и для CLI, со всеми теми же тормозами?

Действительно CLI появился сильно позже и использует те же механизмы, что и GUI. Только вот это не должно тормозить. Основные тормоза веб интерфейса происходят из-за того, что большое количество JS выполняется в клиентском браузере, а сам механизм выдачи статистики очень быстрый. Если есть примеры того, что именно тормозит в CLI, то было бы очень полезно.

Изменено 2 марта, 2016 пользователем m0sia

[rdc]

Не пойму, почему все жалуются на скорость GUI. У меня всё работает нормально.

 

Но по-прежнему интересует судьба хотелки про заливку учёток в конфиге.

На конкурирующей платформе конфиг вливается полностью, с паролем - не нужно его прописывать руками.

[Sonne]

Еще один фактор который влияет - поток трафика от веб клиента. Если запустить вебинтерфейс, то в мониторинге видно непрерывнй поток около 300 кбит. Это мягко говоря дофига. Что там передается в таком количестве?

 

Так же тормозит пороц. На мониторинге видны долговременные всплески нагрузки процессора под 100 %. Хотя местный маркетолог нам говорит что это не страшно, на трафике не отражается (верю) и это чуть ли не хорошо! Вот в это я не верю, потому что гуй рендерит не святой дух а центральный процессор. Если он постоянно загружен на 100%, значит он может тормозить. Я никакой системы с загрузкой CPU не обнаружил.

[m0sia]

Еще один фактор который влияет - поток трафика от веб клиента. Если запустить вебинтерфейс, то в мониторинге видно непрерывнй поток около 300 кбит. Это мягко говоря дофига. Что там передается в таком количестве?

 

там json со всей статистикой(~7Kb, максимум 10Kb) передается по умолчанию раз в 5сек. Итого должно быть 16кбит полезных(если усреднить за 5с), со всеми накладными l2/l3+tcp будет ну максимум 30кбит. Точно там ничего больше не происходит?

 

Так же тормозит пороц. На мониторинге видны долговременные всплески нагрузки процессора под 100 %. Хотя местный маркетолог нам говорит что это не страшно, на трафике не отражается (верю) и это чуть ли не хорошо! Вот в это я не верю, потому что гуй рендерит не святой дух а центральный процессор. Если он постоянно загружен на 100%, значит он может тормозить. Я никакой системы с загрузкой CPU не обнаружил.

 

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

[Sonne]

Еще один фактор который влияет - поток трафика от веб клиента. Если запустить вебинтерфейс, то в мониторинге видно непрерывнй поток около 300 кбит. Это мягко говоря дофига. Что там передается в таком количестве?

 

там json со всей статистикой(~7Kb, максимум 10Kb) передается по умолчанию раз в 5сек. Итого должно быть 16кбит полезных(если усреднить за 5с), со всеми накладными l2/l3+tcp будет ну максимум 30кбит. Точно там ничего больше не происходит?

 

ВОТ! Я понял! 8 кБайт передается на ваших тестовых конфигурациях. На живом секторе с кучей клиентов передаетсч 100 - СТО Килобайт, каждые 5 секунд!

[Sonne]

JS и CSS с версии 2.6 кешируются на клиенте и не передаются, если вы уже заходили на этот адрес. Также если посмотреть profiler в Chrome, то вы увидите, что много времени тратится вовсе не на передачу данных, а на исполнение JS и постройку DOM. К сожалению ваши предложения не приведут к существенному ускорению. Более того включение сжатия может ухудшить ситуацию, если устройство нагружено трафиком.

 

Не согласен про кеширование!

 

Каждые 5 секунд передается полная статистика по сути в текстовом формате - 8кб. Если на базе много абонентов то капает уже 100 кб при 60. Боюсь представить что там при 100 абонентах происходит.

 

Про исполнение JS и постройку DOM - соглашусь. Очень сложная структура кода - невероятная глубина стека, навскидку несколько десятков уровней. При этом ужасно неэффективны код каждые 5 секунд нагружается огромным объем данных. Если честно, руки бы этим программистам оторвать бы!

 

 

[Sonne]

Короче надо все переделывать!

 

1. Разбить общий запрос/ответ на три разных объекта - обычные конфигурационные параметры, реалтаймовскую статистику базы и статистику клиентов.

2. На сервере разбить выдачу этих параметров на три независимых функции.

3. На клиенте анализировать какую страницу в данный момент смотрит пользователь и запрашивать только нужный раздел.

4. На клиенте тоже сделать три независимых функции обработки статистики.

5. Функцию обработки статистики сделать максимально легковестной. Выкинуть нафиг все фреймворки, только парсер JSON и AJAX обновление окон со статистикой.

 

 

Начать с 1-2-3. По крайней мере сможем нормально жить при конфигурации.

 

Кстати, интересно каким образом работает web сервер nginx? Я обратил внимание что время отклика при запросе css файла составляет почти 80-200 мс.

 

Что там накрутили за nginx? Оригинальная openwrt luci json библиотека написана на lua для под nginx. Это работает чертовски быстро.

 

Что там накрутили если не секрет - неужели php? Ну уж совершенно точно не C/C++!

[Ansy]

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

Параллельной загрузкой должен заниматься браузер и именно так он и поступает(см скриншот). А статику конечно можно предварительно сжать, идея хорошая, но нетривиальная.

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

Опять же, некоторая ПОСЛЕДОВАТЕЛЬНОСТЬ имеет место быть... возможно, есть способ поместить длинные JS-загрузки в начало этой очереди? А мелкие CSS потом? Я ни разу не вебмастер, но вроде простым порядком появления ссылок на вложенные скрипты в первоначальном HTML это регулируется?

 

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

 

На вебинаре Cambium Networks я задавал вопрос насчет различия функционала вебморды и CLI/shell. Насколько понял из ответа -- основное это вебморда, и более того -- разработка шла именно от неё. Логично предположить, что ВНУТРИ ЖЕЛЕЗКИ вебсервер дергает инфу для отображения именно через API CLI, то есть используется ровно тот же механизм/источник данных, что и для CLI, со всеми теми же тормозами?

Действительно CLI появился сильно позже и использует те же механизмы, что и GUI. Только вот это не должно тормозить. Основные тормоза веб интерфейса происходят из-за того, что большое количество JS выполняется в клиентском браузере, а сам механизм выдачи статистики очень быстрый. Если есть примеры того, что именно тормозит в CLI, то было бы очень полезно.

Тормозит:

• первоначальная загрузка (до появления запроса логина/пароля) -- иногда перегружать приходится, думая, что не отвечает устройство или забыл нажать. Даже ввод логина тормозит, иногда успеешь два раза набрать логин в окошке, а потом он дважды отображается.
  
• реакция меню, особенно на мобильных -- нажимаешь несколько раз, думая, что не нажалось, не сработало... а оно потом открывается и сразу закрывается -- то есть тормоза именно в обработке загруженным GUI на локальном устройстве/браузере.
  

Если есть механизм выдачи чисто текущей статистики в JSON или как-то ещё -- то, наверное, возможно и создание ОТДЕЛЬНОГО, СТОРОННЕГО веб-приложения, которое сможет дергать эту статистику из устройства, но обрабатывать и отображать уже СВОИМИ скриптами? Наверное, cnMaestro Remote Management именно так и делает?

 

P.S. Ну да, самые объемные скрипты и библиотеки НАЧИНАЮТ загружаться из самого КОНЦА HTML-файла ;)

     <script src="closure/cambium_libraries.js?v=2.6.1-1456335857"></script>
     <script src="closure/cambium.js?v=2.6.1-1456335857"></script>
  </body>
</html>

Мож все же их в начало HTML забросить?

Изменено 3 марта, 2016 пользователем Ansy

[Ansy]

Насчет реактивности отдачи статистики SNMP через watch:

Every 2,0s: snmpwalk -c public -v 1 10.100.24.72 SNMPv2-SMI::enterprises.17713.21.1.2.30.1.27.1

SNMPv2-SMI::enterprises.17713.21.1.2.30.1.27.1 = STRING: "0002:12:31:08"

Вот нифига оно не успевает за 2 секунды обновлять ОДНО значение (всего три клиента на базе, трафик копеечный, до 3-4Мбит/с суммарно).

И раз в 5 секунд тоже не успевает. Раз в 10 секунд -- ну да, примерно тикает...

А если всю ветку SNMPv2-SMI::enterprises.17713.21.1.2.30.1 дергать, да с хорошо "населенной" базы -- наверное полная жесть будет. Впрочем, для построения графиков чаще минуты наверное и не надо, причем выборочно -- только счетчики?

 

Господа разработчики, а ваша JSON-выдача как-то с механизмом SNMP связана, кореллирует по быстродействию? Или у них там ВООБЩЕ РАЗНЫЕ механизмы обработки?

Изменено 3 марта, 2016 пользователем Ansy

[m0sia]

Короче надо все переделывать!

 

1. Разбить общий запрос/ответ на три разных объекта - обычные конфигурационные параметры, реалтаймовскую статистику базы и статистику клиентов.

2. На сервере разбить выдачу этих параметров на три независимых функции.

3. На клиенте анализировать какую страницу в данный момент смотрит пользователь и запрашивать только нужный раздел.

4. На клиенте тоже сделать три независимых функции обработки статистики.

5. Функцию обработки статистики сделать максимально легковестной. Выкинуть нафиг все фреймворки, только парсер JSON и AJAX обновление окон со статистикой.

 

 

Начать с 1-2-3. По крайней мере сможем нормально жить при конфигурации.

 

Кстати, интересно каким образом работает web сервер nginx? Я обратил внимание что время отклика при запросе css файла составляет почти 80-200 мс.

 

Что там накрутили за nginx? Оригинальная openwrt luci json библиотека написана на lua для под nginx. Это работает чертовски быстро.

 

Что там накрутили если не секрет - неужели php? Ну уж совершенно точно не C/C++!

 

спасибо, капитан :) да, именно так и надо делать, но увы быстро только кошки родятся. Я уже писал тут, что работа в этом направлении идет.

 

Что же касается nginx, то он медленно отдает статику только в случае нагрузки трафиком: работа сервера не в приоритете. Ну и php у нас конечно нет.

 

 

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

 

Они и так пожаты/обфусцированы

 

 

Тормозит:

• первоначальная загрузка (до появления запроса логина/пароля) -- иногда перегружать приходится, думая, что не отвечает устройство или забыл нажать. Даже ввод логина тормозит, иногда успеешь два раза набрать логин в окошке, а потом он дважды отображается.
  
• реакция меню, особенно на мобильных -- нажимаешь несколько раз, думая, что не нажалось, не сработало... а оно потом открывается и сразу закрывается -- то есть тормоза именно в обработке загруженным GUI на локальном устройстве/браузере.
  

Если есть механизм выдачи чисто текущей статистики в JSON или как-то ещё -- то, наверное, возможно и создание ОТДЕЛЬНОГО, СТОРОННЕГО веб-приложения, которое сможет дергать эту статистику из устройства, но обрабатывать и отображать уже СВОИМИ скриптами? Наверное, cnMaestro Remote Management именно так и делает?

 

я имел в виду, что тормозит в CLI. Что в вебе тормозит мне известно.

 

Насчет реактивности отдачи статистики SNMP через watch:

Every 2,0s: snmpwalk -c public -v 1 10.100.24.72 SNMPv2-SMI::enterprises.17713.21.1.2.30.1.27.1

SNMPv2-SMI::enterprises.17713.21.1.2.30.1.27.1 = STRING: "0002:12:31:08"

Вот нифига оно не успевает за 2 секунды обновлять ОДНО значение (всего три клиента на базе, трафик копеечный, до 3-4Мбит/с суммарно).

И раз в 5 секунд тоже не успевает. Раз в 10 секунд -- ну да, примерно тикает...

А если всю ветку SNMPv2-SMI::enterprises.17713.21.1.2.30.1 дергать, да с хорошо "населенной" базы -- наверное полная жесть будет. Впрочем, для построения графиков чаще минуты наверное и не надо, причем выборочно -- только счетчики?

 

Господа разработчики, а ваша JSON-выдача как-то с механизмом SNMP связана, кореллирует по быстродействию? Или у них там ВООБЩЕ РАЗНЫЕ механизмы обработки?

 

если сделать GET .1.3.6.1.4.1.17713.21.2.1.1.0, то счетчики в SNMP принудительно обновятся: будет тикать хоть раз в 500мс

[Sonne]

Господа разработчики, а ваша JSON-выдача как-то с механизмом SNMP связана, кореллирует по быстродействию? Или у них там ВООБЩЕ РАЗНЫЕ механизмы обработки?

 

Полное совпадение! В JSON выдается все то же самое что в SNMP GET/SET. Я писал шаблоны для Cacti, знаю о чем говорю. Глаз машинально зафиксировал все те же названия.

[m0sia]

Кстати отдельное спасибо забыл сказать Ansy и Sonne за конструктивный диалог!

[Sonne]

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

 

https://habrahabr.ru/post/278655/

[Ansy]

Прирастаем абонентскими станциями, вылезают следующие наблюдения/хотелки в интерфейс:

1. Таблицы. Show Detail не даёт никакого преимущества перед Show List. Только переворот столбцов и строк -- причем в "типа детальном" просмотре и названия полей перестают умещаться, и разделители между инфой разных устройств отсутствуют -- попробуй догадайся, где чьи параметры... в табличном виде можно хотя бы строки сортировать по разным критериям и ширину столбцов менять, а "типа детализация" не добавляет сверх "таблицы" даже ни одного параметра (их ровно 10 и там, и там). Косметика, короче... причем неудачная и тяжелая.
   
2. В таблицу Subscriber Module Statistics, что на закладке Monitor - Performance, добавьте, пожалуйста, поля IP Address и Device Name (как в таблице раздела Wireless). Потому что эти два поля мы хотя бы поименовать можем сами, а вот память на заводские MAC-адреса устройств и где они стоят -- у большинства админов, полагаю, неважнецкая... Особенно когда их становится больше двух-трех штук. Параметры же статистики мониторить и сравнивать очень важно. Но об этом следующий пункт.
   
3. Добавьте еще в табличку мониторинга (можно в обе) интегральный параметр качества связи -- полагаю, процент перепосланных пакетов к общему числу отправленных (Downlink Retransmitted Packets / Total Downlink Packets * 100%) достаточно показателен. В железках Ubiquiti есть CCQ, в старом железе KarlNet TurboCell был счетчик ретрансмитов (и мы добивались их не более 10% от общего числа посланных пакетов). А у Cambium вроде и "голубую соточку" качество показывает, а дофига притом теряет http://forum.nag.ru/forum/index.php?showtopic=111346&view=findpost&p=1249054 -- никакой ясности с первого взгляда на эти растущие мегасчетчики, приходится округлять и с калькулятором высчитывать, бегая между страничками.
   

Скриншоты, надеюсь, не нужны -- каждый сам у себя видел?

Изменено 21 марта, 2016 пользователем Ansy

[andryas]

В связи с http://forum.nag.ru/forum/index.php?showtopic=104771&view=findpost&p=1262163 предлагаю разработчикам либо поправить бридж (драйвер радио карты, etc, нужное подчеркнуть) либо запилить костыль типа вачдога для передёргивания радиокарты при фризе линка.

[m0sia]

Прирастаем абонентскими станциями, вылезают следующие наблюдения/хотелки в интерфейс:

1. Таблицы. Show Detail не даёт никакого преимущества перед Show List. Только переворот столбцов и строк -- причем в "типа детальном" просмотре и названия полей перестают умещаться, и разделители между инфой разных устройств отсутствуют -- попробуй догадайся, где чьи параметры... в табличном виде можно хотя бы строки сортировать по разным критериям и ширину столбцов менять, а "типа детализация" не добавляет сверх "таблицы" даже ни одного параметра (их ровно 10 и там, и там). Косметика, короче... причем неудачная и тяжелая.
   
2. В таблицу Subscriber Module Statistics, что на закладке Monitor - Performance, добавьте, пожалуйста, поля IP Address и Device Name (как в таблице раздела Wireless). Потому что эти два поля мы хотя бы поименовать можем сами, а вот память на заводские MAC-адреса устройств и где они стоят -- у большинства админов, полагаю, неважнецкая... Особенно когда их становится больше двух-трех штук. Параметры же статистики мониторить и сравнивать очень важно. Но об этом следующий пункт.
   
3. Добавьте еще в табличку мониторинга (можно в обе) интегральный параметр качества связи -- полагаю, процент перепосланных пакетов к общему числу отправленных (Downlink Retransmitted Packets / Total Downlink Packets * 100%) достаточно показателен. В железках Ubiquiti есть CCQ, в старом железе KarlNet TurboCell был счетчик ретрансмитов (и мы добивались их не более 10% от общего числа посланных пакетов). А у Cambium вроде и "голубую соточку" качество показывает, а дофига притом теряет http://forum.nag.ru/forum/index.php?showtopic=111346&view=findpost&p=1249054 -- никакой ясности с первого взгляда на эти растущие мегасчетчики, приходится округлять и с калькулятором высчитывать, бегая между страничками.
   

Скриншоты, надеюсь, не нужны -- каждый сам у себя видел?

 

все это имеет смысл, спасибо.

 

что же касается "Downlink Retransmitted Packets / Total Downlink Packets * 100%", то быстрее всего это сделать в системе мониторинга. Все равно удобнее иметь всю статистику со всех устройств в одном месте.

[rdc]

напомню хотелку про ping watchdog

сегодня база вдруг "исчезла" - линк есть, но пакетов по проводу с неё нет.

дёрнул по питанию - заработала.

 

а нанки это умеют сами!

[saaremaa]

Когда этот б...кий спектроанализатор в EPMP 1000 будет нормально работать. Если не будет - выпилите его к чертям чтоб глаза не мозолил. Сколько версий просим как не работает нормально так и не работает.

[Zerkal]

Когда этот б...кий спектроанализатор в EPMP 1000 будет нормально работать. Если не будет - выпилите его к чертям чтоб глаза не мозолил. Сколько версий просим как не работает нормально так и не работает.

У нас работает вот так. Разве это не нормально?

[saaremaa]

У нас работает вот так. Разве это не нормально?

Какой браузер?

Какая версия JRE?

Расширения в браузере по блокировке рекламы стоят?

[Zerkal]

Года пол назад, пробовал запускать спектр, из хрома, не помню на какой прошивке, все время вроде писало, что-то типо disconnected или conection lost. С тех пор специально для спектрА пользуюсь мозилой фаерфокс последней версии. Плагины и расширения следующие.