darkk
0

В https://ooni.torproject.org/ :-)


RIPE Atlas фильтрация контента провайдерами будто бы не сильно интересна, подробности можно найти в мыллистах того же tor.

darkk
0

tcpi_last_data_recv даст что-то похоже на то, что хочется, только он отдаёт не таймштамп, а миллисекунды(1e-3!) с момента получения данных и разрешение у него в jiffies.


Я не уверен, укладывается ли такая точность в определение "тормозов" для конкретного случая.


Про использование обсуждаемых в статье таймштампов применительно TCP я не в курсе, надо исходники читать :-)

darkk
0

Как минимум есть TCP_INFO, где есть некоторые тайминги.

darkk
0

Были б данные за осень — я б не просыпался ночью с мыслью о том, не надо ли online-дообучение доделать к роботу :-)


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


Смежные картинки в train/val/test — это плохо и неправильно

Но, кажется, это лучшее, что доступно.

darkk
+1

MNIST — скучно. И дело не в том, что я живу в Питере и мне эта боль с разводными мостами близка — я поговорил с товарищем, который учится в ШАДе, он теперь тоже озадачен тем, чтоб найти красивую и не суперсложную задачу из "реального мира", которую можно решить методами машинного обучения :)

darkk
0
потому что камера не работала

Я в телеграмном боте выкидываю jpeg-и, где нет баннера с камеры (видеопоток развалился). Благо, баннер статичный и определяется тривиальной маской.

darkk
0

Частично как раз интересность в том, что освещение постоянно меняется (и будет меняться как минимум до 22 декабря), поэтому может быть плохо предсказывать "прошлое", обучаясь на данных из "будущего". По крайней мере на простой линейной модели я попадал на эту граблю.

darkk
0
более простые алгоритмы будут работать на ура

Ох. Спасибо, я б точно не дождался, если б прогон одного цила обучение-валидация занимал 10 минут на GPU (которого у меня нет). Простым задачам — простые решения. :)


Стоит мне, конечно, посмотреть и по этой теме какой-нибудь курс и книжку и освежить понимание топологий, т.к., кажется, тут что-то сложнее MLP. А не только кроп+параметры подбирать на валидации, сидя в обнимку с бокалом сидра и ноутом на коленке =)


Что-то я промазал тредом и написал ответ вместо комментария. Видать, сидр хороший. :)

darkk
0

Есть вот такой сборник jpeg-ов: http://darkk.net.ru/garbage/dataset-for-mittov.tar.torrent Kaiser сказал, что вечером может посидить.


"Всего и побольше" — мне выкладывать некуда пока.

darkk
0

Да, обещали развести с 11-30 до 13-30. В 11-30 и развели, но где-то в 12-40 уже начали сводить, а потом камера выключилась.

darkk
0
если его через 10 минут разводить будут

Обычно въезд на мост закрывают аккурат по расписанию. Польза робота только в ночной сводке.


перекрыт, но сведён (как было, когда его ремонтировали)

Об этом обычно есть оперативные данные, которые навигаторы публикуют. Вот, например, сейчас ремонтируют Тучков мост и на мосту в Яндекс.Картах нарисовано одностороннее движение:


darkk
+1
стильно, модно, молодёжно

Так речь как раз о том, что можно обойтись простейшей линейной моделью, которая "нейронная сеть" лишь формально (один нейрон).


преобразование Хафа

Я о таком слове попросту не знал, никогда не занимался обработкой изображений, в этом и был посыл статьи — можно сделать ненулевую пользу почти не разбираясь, абсолютно "на коленке" :-)


Но да, когда прикручивал мост Александра Невского, я думал об извлечении более сложных фич, собирался начать как раз с угла наклона — но тот же способ с canny(rgb2blue(crop(raw))) успел дать пристойные результаты попросту на большем количестве данных раньше, чем я в режиме "по вечерам" успел разобраться в вопросе получше.

darkk
0
Спасибо за информацию, я vpiter.tv в коде для читаемости оставлял, ещё думал, почему же в вёрстке IP-адрес напрямую зашит.

Кстати, нет планов у вас робота моего забанить по какой-либо причине? :-) Я писал о нём на info at vpiter.com, но ответа там никакого не получил, и решил, «если баннер не вырезать и ссылку оставить, то, наверное, пока ок, а там видно будет».
darkk
+1
С Дворцовым мостом всё было ровно так, как я написал, первая же попытка дала пристойный классификатор, который показывал 0.99+ по F-мере. Там выборка была не сбалансированная, собранная за рабочую неделю и у меня, если честно, она уже потерялась. :-)

С мостом Александра Невского с наскоку не получилось, там качество картинки на голову хуже. Там я составлял выборку следующим образом: захватывал видеопоток с 0:00 до 8:00, нарезал его на блоки по 5 минут, размечал блоки на UP/DOWN/MOV, где в MOV попадали два блока соответствующие началу и концу движения моста. Проще говоря, факт разводки порождал такую последовательность блоков …, down, down, down, mov, mov, up, up, up, …. После этого из всех блоков одного класса я брал ~1000 кадров за кажду ночь и превращал их в фичи.
Качество оценивал разделяя выборку по времени, первые 20 дней в train, 5 в test и 5 в валидационную выборку. По валидации настраивал кроп. Полагаю, разный кроп даёт заметно разные результаты, т.к. рядом с мостом стоит фонарь, который светит прямо в камеру, и из-за этого пороги у `canny` могут получаться бестолковые. Наверное, вместо кропа можно было точно так же пороги подбирать. Когда делал кросс-валидацию по дням, оценка качества получалась завышенной. С одной стороны это понятно (мы учимся на данных «из будущего»), с другой — не очень (чем данные «из будущего» отличаются-то). Этот процесс тоже дал F-меру 0.99+.

Блоки mov я для обучения текущей модели не использовал, а использовал их только для рисования графика «процесс разводки глазами классификатора», чтоб визуально оценить скорость реакции модели на изменение моста. По этому графику я настраивал размер «кворума». Робот отсылает сообщение в telegram только тогда, когда в последних N кадрах было больше двух третей голосов за одно из двух состояний. Этим действием я сглаживал возможный шум в момент переходного процесса — спамящий о своей неуверенности робот мне довольно быстро показался весьма неприятным.

Про датасеты. Размеченных руками у меня сейчас только 3 Gb jpeg-ов Александра Невского, с 2016-06-19 по 2016-07-24. Можно породить ещё разметку классификатором для Ал.Не. и Дворцового за последние две недели, там flv-шки и их сильно больше: 28G с Дворвоцого и 53G с Александра Невского. Есть ещё поворотная камера, которая смотрит на мост лейтенанта Шмидта (две задачи по цене одной — понять, что сейчас на камере нужный мост и понять его состояние) и Литейный, по которому машины ездят, а разводной секци не видно. Что из этого интересно?
darkk
+1
Чтобы не тратить время на составление правил :-)
Машины должны работать. Люди должны думать.
darkk
0

В статье, там примерно четыре строчки кода :-) Вся содержательная часть — это преобразование картинки в вектор фич, которыми потом кормится классификатор с дефолтными параметрами. Но несложно продублировать:


def load_dvorcovy_vpiter_admiral(fname):
    feat = feature.canny(color.rgb2gray(io.imread(fname)[40:360, 110:630]), sigma=2)
    feat = transform.downscale_local_mean(feat, (20, 20))
    assert feat.shape == (16, 26)
    return feat.reshape((np.prod(feat.shape), ))
darkk
0
Я ни с одним из этих утверждений не спорил. Более того, именно так я и планировал решать задачу с Литейным мостом, если не получится найти более пристойного источника данных, чем следы от стоп-сигналов :)

Со следами от стоп-сигналов вот ещё какая беда есть: если машина ошибается (а я не слишком высокого мнения о своих умениях в задачах распознавания), то по контуру моста человек может перепроверить машину. По следам стоп-сигналов это сложнее.
darkk
0
Я хотел сказать, что Гаусс в коробке с `feature.canny`. А из-за каких свойств взяли бы именно median?
darkk
0
Практически это мне кажется более сложной задачей, т.к. надо смотреть на динамику изображений и анализировать, наверное, каждый кадр (а не каждый 50-ый). Если есть интерес, могу предложить неразмеченный датасет с видео Литейного моста, там как раз камера смотрит на участок дороги сбоку, а разводной секции не видно.
darkk
0
Гаусс лежал готовый в коробке и оказался достаточно хорош :-)
darkk
0
Да, в Мостотресте по телефону теоретически что-то можно узнать. По крайней мере на сайте телефон есть.
С рацией есть тонкость — если мосты не разводят из-за непогоды, то бот об этом может принять решение и сказать, «что-то мост не развели по расписанию», а в радиоэфире будет, наверное, тишина.
darkk
0
Про яркость у меня есть смешная картинка «Рассвет над мостом Александра Невского». Когда я разбирался с качеством камеры, которая смотрела на этот мост, я заметил, что она имеет два режима: ночной и дневной. Эти два режима хорошо видны на следующей картинке:

Я взял RGB значения цвета неба над мостом в разные моменты времени за всю ночь и нарисовал их точками на диаграмме. Хорошо видно, что цвет неба имеет разрыв — в какой-то момент он меняется скачком. Кажется, этот момент соответствует выключению городского освещения :-)
darkk
0
2. Если нет желания смотреть датасет, то качество на мосту Александра Невского можно посмотреть ещё в истории Telegram канала.
darkk
0
1. Нет, на linode живёт робот, который пишет в канал, на ноутбуке жила только часть подготовки данных. Сбор данных жил, конечно, на кусочке отдельной железки с достаточным местом на диске, но и там пришлось думать о том, чтоб весь диск не забить видеопотоком :-)
2. Плохо, но обычно видно. Если очень интерено, могу поделиться датасетом.
darkk
0
Синий график показывает вероятность третьего класса «мост в движении». Потом я отказался от данного класса, т.к. в интерфейсе его всё равно не существует. Мусор с камеры оказалось проще всего отслеживать по баннеру, т.к. обычно мусор связан с развалившимся видеопотоком.
По-честному ещё стоит, конечно, отслеживать, что камеру не повернули, и что она смотрит в тот же ракурс, на котором бот обучался.

Вопрос про запас и вероятность я не понял. Глюки видеокамеры обычно выражаются либо в нескольких мусорных кадрах либо в полной её недоступности.
darkk
+1
Более сложные тесты приводят к использованию scapy Automaton, из которого у меня не получалось выжать больше нескольких тысяч PPS, дальше программа упирается в CPU, поэтому вопрос производительности вполне может стоять.
Частично ситуация улучшается при использовании BPF-фильтра: например, если тестируется UDP-сервис, то разделение ответного трафика по нескольким процессам и CPU можно проводить по src-port, но не для всех протоколов есть такая возможность.
darkk
0
dbmsmusings.blogspot.com/2012/05/if-all-these-new-dbms-technologies-are.html — интересная ссылка про транзакции, кстати.
darkk
+1
Хех, у меня как раз все ваши ссылки visited. А почему? Потому, что транзакции работают только в пределах одного документа, а междокументные приходится делать своими руками (1, 2), журналирование вызывает segfault, когда кончается место на диске, а при крэше процесса БД чинится дольше, чем банальный MyISAM у MySQL (10 минут на гигабайтную БД). И многое другое.

В общем, конкретно mongodb до ума не довели пока ещё :)
darkk
0
И в ту же копилку Талеб с его «чёрным лебедем», который всю книгу акцентирует внимание на том, что знание «как не надо» — оно тоже невероятно ценно.
darkk
0
Если с TERM пошаманить сразу по входу — ругательств становится чуть-чуть меньше.
darkk
0
Не-не-не, негрустин!
darkk
0
Нашёл, кстати, решение без хаканья грепа: добавить перевод строки с помощью ^[D перед \x0a

Правда, придётся обрабатывать escape-последовательности, но какой уважающий себя терминал это не делает! :-)
darkk
+3
А как пустые строки попали в вывод egrep натравленного на /etc/awards? :-D
darkk
0
Некоторое время. Довольно часто софтины после сверки пароля не затирают его в памяти, а если еще в промежутке он проходит через сетевые буфера, буфер ввода-вывода и чёрт еще знает что…
darkk
0
Странно, мне пробовали посылать donate на русский paypal аккаунт — донейт просто возвращался через несколько минут отправляющему.
darkk
0
А jingle? :-)
Не сильно хорошо в Linux с NATами.
darkk
0
Ну есть же какие-то хитрости по получению полнотектовых фидов.

Хотя, если честно, я даже рад, что они обрезаны — читать полнотекстовый фид с главной как-то затратно по времени :-)
darkk
0
Это расширение протокола. Например, посмотреть можно на xmpp.org/extensions/xep-0209.html

Но, конечно, всегда можно сделать не совсемстимый ни с чем велосипед на стороне клиента :-)
darkk
0
Увы, вы не правы.
Это и свойство протокола (server-side хранение метаконтактов) и свойство клиента.
darkk
0
Ну как сказать, строго говоря, это не очевидно, т.к. используется один и тот же ключ для двух алгоритмов (только алгоритмы называются не Blowfish и AES, а, соответственно, magicBlowfish и magicAES).

Нет, я не говорю, что у вас какая-то проблема в безопасности, почти наверное, её нет, но с тем, что это очевидно, я не согласен.