Search
Write a publication
Pull to refresh
9
0
Евгений @IbZ

User

Send message
Почему Россия-США смотрели в интернете меньше чем Россия-Словакия и Россия-Норвегия объясняется очень просто. Россия-США — матч был в выходной день, люди могли посмотреть и дома, но телевизорах. А матчи с Норвегией и Словакией были в рабочие дни, начинались в 16-30 — люди вынуждены были смотреть через интернет.
Вообще хоккей на олимпиадах и ЧМ всегда бил все рекорды по популярности. Раньше у меня была статистика по просмотрам IPTV-каналов. Во времена хоккея (во время таких матчей) мало того что побивались рекорды по кол-ву одновременно смотрящих IPTV людей, так еще и весь пик (до 90-95%) приходился на канал транслировавший этот матч. Даже «реальные пацаны» в первый сезон и «новогодние огоньки» скромно стояли в сторонке.
Футбол, кстати, в нашей стране любят не меньше :)
Спасибо за идею!
Подключил свой сканер Canoscan Lide25 к Raspberry pi (через внешний usb-концентратор со своим питанием) — работает! Сканирует в сетевую папку, сейчас буду принтер прикручивать, идея ксерокопирования одной кнопкой — очень хороша… :)
Cледующий этап — надо сделать механизм чтобы попытаться исправить эти ошибки — т.е. написать скрипт, чтоб он например передергивал программно кам-модуль, или в крайнем случае ребутал ресивер, переключал на резервный, ну и разумеется отправлял почтовое алерты, смс-ки администратору ;)
Еще полезно иметь графики (в виде мртг-шных например) уровня сигнала с ресиверов (на широко распространенных PBI — вполне легко это делается)
Дальше можно продолжить в сторону юзеров — смотреть на какие каналы они подписываются и строить свой рейтинг популярности
В свое время стояло 20 разных впн-серверов. Основные моменты в принципе как во всех выше приведенных примерах:
1. у каждого сервера был свой «вес», коэффициент в зависимости от его процессорной мощности (использовались несколько однотипных платформ, так что при установке нового сервера вес бы уже известен)
2. каждый впн-сервер раз в минуту собирал сам некое взвешенное число получаемое из кол-ва своего трафика в pps'ах и кол-ва сессий. Почему только не один из этих параметров, а совокупность? — потому что большое кол-во сессий не всегда прямо пропорционально трафику (допустим сломалась маршрутизация и т.п, и трафика нет, а балансер будет все кидать и кидать сессии на этот сервер). NAS отдавал эти числа по обычному snmp (exec в snmpd.conf на сервере и snmpwalk .1.3.6.1.4.1.2021.8.1.101 на балансере)
По snmp же строились графики онлайна, загрузки, pps
3. TTL для имени впн-сервера был крайне малым — 1-2 минуты, выдавались 4 самых ненагруженных nas'а роунд-робином

для выключения nas'а из балансировки для обслуживания можно было погасить снмп демон на нем.
так вот кто айфон в морозильник положил! bash.im/quote/416978
К сожалению накрылась домашняя файлопомойка на которой был мой сайт с фотками (а на хабрасторадж мне видно пока по рангу не положено выкладывать) — часть я восстановил, а вот картинку со схемой, к сожалению, смогу восстановить только в понедельник.
Есть скрипт на сервере (php) который выполняет функцию мониторинга — постоянно по кругу проверяет канал один за другим, проверяет есть ли вообще трансляция и если есть — не кодирована ли она. И соответственно при проверке каждого канала делает примерно следующее
         if($arduino_is_live)
         {
           ... заполняется $arduino_msg ...
           $fp=fsockopen("tcp://10.20.30.40", 5555, $errno, $errstr, 3);
           if($fp)
           {
             fwrite($fp, $arduino_msg);
             fclose($fp);
           }
           else
           {
             $arduino_is_live = false;
           }

в переменную $arduino_msg загоняется номер текущего проверяемого канала и все сбойнувшие. В конце цикла — посылается еще раз сообщение где перечислены только сбойнувшие каналы.
Скрипт проверки использует VLC (записывается файл и парсятся/анализируются логи). По результатам проверки, если есть много проблем на каком-то ресивере (больше половины каналов не работает) — ребутает его (snmp или телнет в зависимости от модели ресивера) и отправляет смс-ку если список сбойнувщих каналов изменился.
Согласен. И дешевле еще и проще и эффективнее. На компьютере же все это уже есть, но это все слишком обычно. А когда реализуешь свою давнюю задумку своими руками, а она еще и работает как надо — знаете как приятно? :)
Если к к каждому выходу регистра подключить по одному светодиоду — то да, можно защелкнуть и забыть. Но тогда нужно 160/8 = 20 регистров, что и распаивать тяжелее, да и дороже получается (вначале я кстати так и хотел сделать).
Когда подключаешь матрицу как в моем примере, при защелкивании можно добиться что светодиоды будут гореть какими-нибудь полосами/рядами, но если надо рандомно зажечь два светодиода тут, три в другом углу, 10 штук посередке ромбиком — просто так это уже не сделаешь.
На помощь приходит динамическая индикация.
Защелкивание регистров разумеется здесь происходит — иначе светодиоды не зажгутся просто. Тут используется тот момент что человеческий глаз он инертен, т.е. если быстро зажигать и гасить светодиод в цикле — человеческий глаз не успеет заметить что светодиод гаснет, для него он будет постоянно горящим.
И именно поэтому здесь постоянно поджигается нужные светодиоды из одного рядя, потом из второго, третьего и т.д. и все это по кругу.

Information

Rating
Does not participate
Location
Чебоксары, Чувашия, Россия
Date of birth
Registered
Activity