OScam: настройка cacheex и cache time для reader

Если вы уже запустили OScam, раздали клиентам доступ и столкнулись с фризами при переключении каналов — скорее всего проблема в таймингах кэша. OScam reader cache time — это не просто одна настройка, а целый пласт взаимосвязанных параметров, которые работают вместе. Выставить их наугад и надеяться, что всё заработает — плохая стратегия. Разберём по-человечески, что происходит внутри и какие цифры реально работают.

Что такое cache time в reader OScam и за что он отвечает

Многие путают два разных механизма кэширования в OScam: локальный кэш reader'а и cacheex. Это принципиально разные вещи с разными параметрами и разной логикой работы. Смешивать их в голове — верный путь к неправильной конфигурации.

Разница между кэшем reader и общим cache (cacheex)

Кэш reader'а — это локальное хранилище DCW-ответов от конкретного источника (карты или прокси). Когда reader получил ответ на ECM-запрос, OScam сохраняет этот DCW у себя. Если через секунду придёт идентичный запрос — он вернётся из памяти, без обращения к карте.

CacheEx — совсем другое. Это механизм обмена DCW между серверами по сети. Один сервер уже получил ключ, второй подключается и берёт его из общего пула. Параметры cacheex_mode, cacheex_maxhop — это про межсерверный обмен, не про локальный кэш reader'а.

Как OScam хранит ответы ECM/DCW во времени

Жизненный цикл ECM-запроса выглядит так: клиент присылает запрос → OScam проверяет кэш → если есть свежая запись, отдаёт DCW немедленно → если нет, идёт к карте или прокси → получает ответ → сохраняет в кэше → отдаёт клиенту.

DCW (ключ расшифровки) действителен ровно один крипто-период. У большинства провайдеров это около 10 секунд. Хранить запись в кэше дольше — значит рисковать отдать устаревший ключ. Канал зафризит, потому что декодер получил ключ от прошлого периода.

Влияние тайминга на скорость переключения каналов

При переключении канала декодер сразу присылает ECM. Если кэш пустой или протухший — запрос уходит к карте. Пока карта думает (50–300 мс для локальной, до 1000 мс для удалённой) — экран чёрный. Правильно настроенный кэш сокращает это время до нуля, если кто-то из других клиентов уже смотрел этот канал секунду назад.

Слишком агрессивный кэш — тоже плохо. Запись живёт 30 секунд, а крипто-период сменился через 10. Все клиенты получают невалидный DCW и фризят одновременно. Это хуже, чем вообще без кэша.

Ключевые параметры тайминга в oscam.server и oscam.conf

Файлы конфигурации OScam лежат в зависимости от дистрибутива: чаще всего это /etc/tuxbox/config/ или /etc/oscam/. Там вас интересуют три файла: oscam.conf, oscam.server и иногда отдельный oscam.cache. Параметры кэша рассыпаны по всем трём.

lb_reopen_seconds и поведение при недоступности reader

Параметр lb_reopen_seconds в секции [global] файла oscam.conf определяет, через сколько секунд OScam попробует снова обратиться к reader'у, который ранее не ответил. Значение по умолчанию — 120 секунд. Если у вас нестабильный VPN-туннель до прокси, это означает двухминутный провал при каждом обрыве.

Для нестабильных соединений можно снизить до 30–60 секунд. Но слишком маленькое значение (например, 5 секунд) будет постоянно дёргать мёртвый reader и создавать лишнюю нагрузку. Разумный компромисс — 45–60 секунд.

Важный момент: пока reader помечен как недоступный, OScam берёт DCW исключительно из кэша. Если кэш протух — фризы неизбежны. Именно поэтому кэш с разумным временем жизни — страховочная сетка при плавающем пинге.

cacheex_maxhop, cacheex_mode и время жизни записи

cacheex_mode определяет направление обмена:

• mode 1 — сервер принимает DCW от других, сам не отдаёт
• mode 2 — сервер отдаёт DCW другим, сам не принимает
• mode 3 — полноценный двунаправленный обмен

cacheex_maxhop ограничивает количество «прыжков» записи между серверами. Значение 2–3 — нормально. Ставить больше 5 смысла нет: запись либо дойдёт за два прыжка, либо устареет раньше, чем пройдёт шесть серверов.

Параметры в [cache]: max_time, max_count, wait_time

Секция [cache] в oscam.conf — сердце настройки. Три главных параметра:

max_time — время хранения записи в секундах. Оптимально: 10–15. Ставить 30 и выше — опасно, именно здесь корень большинства фризов.

max_count — максимальное количество записей в кэше. На сервере с 50+ клиентами ставьте не меньше 1000–2000. Если сервер перегружен и max_count исчерпан, старые записи вытесняются раньше времени — кэш фактически перестаёт работать.

wait_time — сколько миллисекунд OScam ждёт попадания в кэш перед тем, как пойти к карте. Для локальных reader'ов: 50–100 мс. Для удалённых прокси с пингом 150–300 мс: 200–400 мс. Главное правило — wait_time должен быть строго меньше ecm_timeout.

ecm_timeout и его связь с кэшированием

ecm_timeout задаётся в миллисекундах в секции reader'а в oscam.server. Это максимальное время ожидания ответа от карты или прокси. Типичное значение — 3000–5000 мс.

Если вы выставили wait_time = 4000, а ecm_timeout = 3000 — запрос завершится по таймауту раньше, чем OScam вообще проверит кэш. Это классическая ошибка, которая встречается постоянно.

Пример рабочей конфигурации с пояснением каждого значения

Вот рабочая связка для типичного сценария: один удалённый reader через newcamd, 20–40 клиентов, пинг до прокси ~80–150 мс.

Блок [cache] в oscam.conf

[cache]
max_time                = 12      # секунды хранения; 12 = запас над стандартным крипто-периодом 10 сек
max_count               = 1500    # для 30–50 клиентов хватает с запасом
wait_time               = 200     # мс ожидания кэша; меньше ecm_timeout в reader'е

Почему 12, а не 10? Небольшой запас компенсирует сетевые задержки при доставке ответа. Но ставить 15+ — уже риск. У некоторых провайдеров крипто-период нестандартный (7–8 секунд), там лучше снизить до 9.

Настройка cacheex на стороне reader

[reader]
label                   = myproxy_newcamd
protocol                = newcamd
device                  = 192.168.1.100,10000
key                     = 0102030405060708091011121314
user                    = myuser
password                = mypass
caid                    = 0500
ecm_timeout             = 3000    # 3 секунды; wait_time должен быть меньше
cacheex                 = 2       # этот reader отдаёт DCW в общий пул
cacheex_maxhop          = 2
lb_weight               = 100

Параметр cacheex = 2 означает, что reader делится полученными ключами. Если у вас несколько серверов и вы хотите обмен — на принимающей стороне ставьте cacheex = 1 в соответствующем reader'е.

Комбинация с loadbalancer (lb_mode)

При lb_mode = 1 в секции [global] OScam автоматически выбирает быстрейший reader. Кэш работает как фильтр первого уровня: сначала проверка кэша, потом — лучший по статистике reader. Это хорошая связка для сервера с несколькими удалёнными прокси.

Но есть нюанс: если несколько reader'ов отдают DCW на один и тот же канал, кэш может «выбрать» запись от медленного источника и зафиксировать её. Следующий запрос пойдёт уже из кэша, минуя быстрый reader. Это лечится правильной настройкой lb_weight — давайте приоритетному reader'у вес 200 против 100 у резервного.

Диагностика проблем кэша: логи, webif и monitor

Прежде чем крутить цифры, убедитесь, что вообще понимаете что происходит. OScam даёт достаточно инструментов для диагностики — просто большинство не знает куда смотреть.

Чтение строк cache hit / cache miss в логах

Включите отладку через webif: Config → Server → debuglevel. Или запустите OScam с флагом -d 65535 для полного лога. В /var/log/oscam.log (или куда у вас настроен logfile) ищите строки:

• found in cache — запрос обслужен из кэша, хорошо
• cache miss — пошли к карте
• cw cycle — сработала проверка цикла смены ключей, часто из-за кэша
• cache written — запись добавлена в кэш

Если видите много cache miss и мало found in cache — кэш либо отключён, либо max_time слишком мал, либо max_count исчерпан и записи вытесняются раньше времени.

Анализ статистики через веб-интерфейс (порт 8888)

По умолчанию webif доступен на порту 8888: откройте http://ваш_IP:8888. Вкладка Cache показывает текущее количество записей, процент попаданий и среднее время ответа по каждому reader'у.

Смотрите на колонку avg time. Если у локального reader'а там 50–80 мс — это нормально. Если 800+ мс — что-то не так с соединением. Во вкладке Readers видно статистику ECM: сколько запросов ушло к каждому reader'у, сколько пришло из кэша. Это даёт реальную картину без гадания.

Команда oscam -d для отладочного уровня логирования

Если нет возможности использовать webif, запустите OScam вручную:

oscam -d 65535 -c /etc/tuxbox/config/

Флаг -d 65535 включает максимальный уровень отладки. Лог будет подробным — grep помогает фильтровать нужное:

oscam -d 65535 2>&1 | grep -i cache

Для production так не запускают — только для диагностики. Логи раздуются до гигабайтов за час.

Тонкая подстройка тайминга под разные сценарии

Нет универсальных значений, которые работают везде. OScam reader cache time подбирается под конкретный сценарий — и вот как это делается на практике.

Локальная карта против удалённого прокси

Локальная карта через USB-ридер отвечает за 30–80 мс. Кэш при таком раскладе нужен минимальный — wait_time = 50 мс, max_time = 10. Смысл кэша здесь в том, чтобы не гонять карту при одновременных запросах от нескольких клиентов на один канал.

Удалённый прокси с пингом 200 мс — другая история. Здесь wait_time надо поднять до 300–400 мс, иначе OScam не успеет получить ответ из cacheex до того, как самостоятельно пойдёт к прокси. Двойной запрос — двойная нагрузка, и не факт что первый ответит быстрее.

Нестабильный VPN-туннель — особый случай. Кэш маскирует потери соединения: клиент не замечает кратковременного обрыва, пока в кэше есть свежий DCW. Но если туннель лежит дольше max_time — всё равно фризы. Решение: поднять max_time до 15, но тогда убедитесь, что крипто-период провайдера действительно не меньше этого значения.

Много клиентов на одном сервере

При 100+ клиентах кэш становится критичным для производительности карты. Без кэша каждый клиент, смотрящий один канал, гонит отдельный ECM-запрос. Карта обрабатывает их последовательно — очередь растёт, задержка растёт.

С правильным кэшем: первый запрос идёт к карте, все остальные получают DCW из памяти. Нагрузка на карту падает в разы. Но при этом max_count должен быть достаточным — для 100 клиентов и 50+ каналов ставьте 3000–5000. Если max_count исчерпан, OScam начинает вытеснять живые записи, и эффективность кэша обнуляется.

Микширование протоколов (CCcam, newcamd, cs378x)

Старые CCcam-клиенты менее терпимы к задержкам — они имеют жёсткий таймаут на получение ключа, и если OScam не ответил в срок, клиент сбрасывает соединение. При смешанном парке важно держать ecm_timeout в пределах 2000–3000 мс.

Клиенты на cs378x (например, популярные стримминговые боксы) обычно терпимее, но требуют стабильности — им не нравится, когда ключи приходят рывками. Нестабильный кэш с частыми miss при плавающем пинге субъективно воспринимается ими хуже, чем стабильная задержка 300 мс без кэша.

Общий совет для смешанного парка: выставьте ecm_timeout = 3000, wait_time = 200, max_time = 12. Потом смотрите в webif на avg time по каждому типу клиентов и корректируйте.

Ещё один краевой случай, который редко упоминают: нестандартный крипто-период. Большинство провайдеров используют 10-секундный цикл, но встречаются и 6–8 секунд, и даже 4. Если у вас фризы несмотря на правильно настроенный OScam reader cache time — проверьте реальную длину крипто-периода через логи. Строки cw в дебаг-логе покажут, когда именно меняется ключ.