Tick9er

Эти ~30 ms у тебя — это от отправки ордера до ack биржи или от появления сигнала до ack?
У меня сейчас полный путь получается примерно 600 ms, хочу понять, сопоставимые ли у нас замеры.

Новый Бингурыч — ржака!  Напоминает того, что в чате был — отвечал в такой же манере

@Artemkickbox
Аналогичная история у меня с лайтером 😄

Продолжаю мучить своё представление рынка: не временные «свечи», а свои синтетические бары, несколько структурных масштабов, логика входа/выхода и управление позицией внутри этого всего.
Если честно, голова уже подкипает 🤯
Выглядит это всё уже достаточно красиво и местами даже внушительно, но пока практического выхлопа нет — по крайней мере такого, чтобы можно было сказать «вот оно».
Но ладно, идём дальше. Надо добить до конца и понять, где именно затык: в конструкции графа, в самом входе или уже в механике исполнения/ведения сделки.

Halo! Давно ничего не писал, хоть и захожу на форум практически каждый день
Последнее время строю собственный Market Graph из сырых данных Lighter — без обычных свечей и готовых индикаторов.
Тут очень пригодилась мысль коллег: выбросить привычные свечи, идти от raw ticks/events и попробовать построить своё представление рынка. Не искать очередной индикатор или готовый паттерн, а сначала понять, как вообще рынок должна «видеть» машина.
Уже собрана первая версия: ликвидность около цены, потребление книги сделками, mark/index, изменения open interest, структура исполненных мейкеров и т.д. Пока это скорее первый рабочий «холст», на котором машина начинает видеть рынок немного иначе, чем через привычный OHLC.
Сейчас дорисовываю этот же граф на нескольких разных днях и параллельно собираю causal-ядро — только из той информации, которую реально можно знать в момент принятия решения.
План дальше максимально короткий:
свой граф → несколько устойчивых физических состояний → постепенно добавлять новые метрики и их комбинации по мере необходимости → простой тест на экономический эффект → live-forward → реальные сделки маленьким размером.
При этом хочется не скатиться в бесконечный набор признаков ради количества. Идея как раз в обратном: каждая новая метрика должна появляться потому, что текущему представлению реально чего-то не хватает, а комбинации уже будут естественно накапливаться по мере развития графа.
Если со стороны всё это выглядит красиво и последовательно, то внутри всё намного веселее 😅 Периодически от количества данных, проверок, ошибок и развилок уже реально болит голова. Иногда садишься и вообще не понимаешь, куда дальше толкать этот вагон, чтобы опять не уйти на неделю не туда.
Потом немного отпускает, собираешь всё обратно по кусочкам и двигаешь дальше, пусть даже маленькими шагами. Постоянно ощущение: «ну вот ещё чуть-чуть... вроде уже почти...», а потом находится новая проблема и ещё один круг 😄
Но когда смотришь назад, вагон всё-таки едет. Поэтому продолжаю. Должно же когда-нибудь получиться
Ну и ниже немного страшилки для глаз — первая версия того, как оно сейчас видит рынок.

У меня вчера вечером было то же самое. Такое окно появлялось только при переходе на последнюю страницу ветки. Но если начинать с первой страницы и листать поочерёдно, всё работало нормально.
Также из свежих проблем: теперь появляются такие предупреждения — и на телефоне, и на компьютере.

Ахах, да, со вторым пунктом я уже разобрался 😄
/usage довольно быстро провёл расследование: 90% расхода пришло из сессий 8+ часов, 81% — из контекста 150k+, 64% — из subagent-heavy сессий.
А потом я посмотрел одну особо «удачную» сессию: $992.64 API-equivalent usage, 1.8B cache read, Opus 100% 😂
Там я действительно разогнал workflow примерно до 15 параллельных readers. Получилось быстро — просто я, видимо, случайно изобрёл способ превратить Max 20x в Max 0x.

И двух дней не прошло с момента ресета недельных лимитов — и тут вот 
Claude Max 20x.
Недельный лимит: 100% used.
Причём сейчас ещё действует временный +50% boost к лимитам.
То ли баг, то ли я немного переусердствовал. Написал в поддержку

@ndr, ты вчера оказался прав 
При расчёте зря удерживался огромный промежуточный массив, который для результата вообще не был нужен.
В итоге два полных прогона прошли успешно, дали байт-в-байт одинаковый результат, а реальное потребление памяти оказалось ~2 GB вместо прогнозируемых 32–64 GB 
Targon взял на заметку — когда действительно упрусь в вычисления, а не в кривую работу с памятью 
Спасибо за совет 👍

@ndr
Вот что сейчас крутится 
В обычном режиме ему хватает, сам сборщик ест всего ~68 MB. 
Думаю основной VPS в перспективе поднять до 8–16 vCPU, чтобы был запас.
Но сейчас хочу прогнать довольно тяжёлый расчёт по историческим данным стакана — обработка большого объёма L2 данных и расчёт исполнимой стоимости по уровням книги. По оценке нужно уже 32–64 GB RAM, поэтому даже апгрейд основного VPS полностью вопрос не решит.
Думаю такие тяжёлые расчёты копить и периодически поднимать под них отдельную мощную машину на несколько часов/сутки. Интересно твоё мнение, как правильнее такое организовать — апгрейдить основной VPS или тяжёлые расчёты всё-таки выносить отдельно?

Теперь упёрся уже не в память модели, а в обычную оперативку и вычислительные ресурсы.
Сейчас часть проекта работает на небольшом VPS. Для постоянных задач его вполне хватает, но появились расчёты, которые на нём уже либо слишком тяжёлые, либо просто нецелесообразно запускать.
Пока решил такие задачи не мучить на слабом железе, а складывать отдельно и потом запускать пачкой на более мощной машине/VPS.
Интересно, кто на чём держит свои проекты?
Сколько CPU/RAM у вашего основного VPS? И если появляются тяжёлые вычисления — апгрейдите основной сервер или поднимаете отдельный мощный инстанс только на время?
Особенно интересно у тех, у кого боты + сбор данных + аналитика/исследования работают 24/7.

@ndr
Спасибо, реально полезно 👍
Прогнал идею на своей системе: большую часть уже по сути реализовал, но нашлись пробелы именно в навигации по накопленной истории.
Решил не делать отдельную LLM-wiki как второй источник правды, а сейчас делаю автоматически собираемый слой поверх основной памяти: карта веток/гипотез, хронология решений и проверки пропущенных связей/противоречий. Сам он ничего не решает и не хранит новую «истину» — его можно удалить и заново собрать из исходных записей.
Посмотрим, как покажет себя  👌

Столкнулся с проблемой памяти проекта.
Контекста стало настолько много, что в какой-то момент проект начал просто теряться: модель уже не всегда помнила, что мы делали, почему приняли то или иное решение и по какой иерархии вообще двигаемся дальше.
В итоге лучшее, что пока придумал — вынести «память» самого проекта отдельно.
Теперь основные решения, текущее состояние, ограничения и следующие шаги фиксируются внутри самого проекта. Плюс периодически делаются checkpoints — условные контрольные снимки состояния (CKPT-000001, CKPT-000002, CKPT-000003 и т.д.). Старые не переписываются, а каждый новый фиксирует очередной важный этап.
Идея в том, что даже если завтра полностью закрыть все сессии и открыть проект с нуля с другой моделью, она должна восстановить всё из этих записей: где мы находимся, как сюда пришли и что делать дальше.
Посмотрим, как покажет себя на практике

Да, в принципе можно, думаю. Но NQ и GC — это уже не крипта, поэтому микроструктура и формат данных там отличаются.
Сам принцип тот же: вместо свечей работать с сырым потоком сделок/ордеров и пытаться восстановить естественные рыночные события. Но возможность восстановить именно отдельный taker-order зависит от того, какие данные и идентификаторы предоставляет конкретная биржа. Конкретно с NQ и GC я сейчас не работаю, поэтому глубже по их данным не разбирался.

Небольшой апдейт по ресёрчу.
Вместо дальнейшего усложнения метрик пошёл обратно к сырым данным и начал искать более естественную единицу рынка.
И тут получилось интересно.
Раньше базовой единицей была свеча:
3 дня BTC на минутках = 4 320 свечей.
Теперь из raw-потока удалось восстановить реальные taker orders — не через придуманный мной таймаут или количество тиков, а по самим order ID биржи.
За те же три дня:
2 574 831 исполнений → 1 484 694 отдельных taker-order событий.
То есть вместо 4,3 тыс. искусственно нарезанных минутных интервалов теперь есть примерно 1,48 млн событий, границы которых определяет сама механика рынка.
Один такой event — это один агрессивный ордер. Он может исполниться одной сделкой, а может пройти несколько уровней стакана и дать несколько исполнений, но для нас это всё одно действие участника рынка.
Сейчас вопрос уже намного интереснее:
Есть ли структура в последовательности самих рыночных событий?
Первые результаты на трёх днях показывают, что переходы между событиями не полностью объясняются просто частотой их появления. Какой-то остаточный порядок есть, причём он виден на всех трёх днях.
Пока пытаюсь восстановить ту единицу, которую создаёт сам рынок.

Вижу, уже двое спрашивают и пока никто не ответил, расскажу тогда о своём небольшом опыте с Hyperscaled.
Пару дней назад всё-таки купил у них челлендж. Правда, со стартом получился небольшой квест 😁 Оплатил через Base, транзакция прошла, но аккаунт почему-то автоматически не активировался.
Написал в поддержку — у них всё через Discord. Разбирались несколько дней, в итоге старую регистрацию сбросили и дали промокод на 100%, чтобы я просто зарегистрировал челлендж заново.
Сейчас всё активировали, аккаунт уже появился в Hyperliquid, можно торговать. Так что с поддержкой в итоге всё разрулили нормально, просто пришлось немного подождать.
Ну и по поводу бесплатных счетов на 1k — их больше не дают, это тоже подтвердили в Discord.

Небольшой апдейт, куда пропал.
Последнее время почти полностью закопался в исследование данных. Сначала продолжил проверять directional-ветку: одну и ту же логику прогнал на минутных, 500-trade и volume-барах. Потом сделал первый вариант вообще без свечей — напрямую по потоку тиков.
Результат пока такой: простая смена способа построения графика сама по себе картину не изменила. Везде получался примерно один и тот же шум. Поэтому перестал перебирать очередные виды баров и немного иначе понял мысль про «свой график».
Сейчас идея не в том, чтобы заменить минутную свечу на тиковую. Сначала нужно нормально описать сам рынок: цену, поток сделок, скорость, объём, серии, энтропию, волатильность, эффективность движения и другие свойства. А уже потом из этого пространства строить состояния и собственное представление.
На текущем этапе собрал каталог из 94 семейств метрик. 75 из них уже можно вычислять на моих данных. После разворачивания на разных масштабах получилось 157 конкретных измерений для каждой сделки. Матрицу построил на трёх полных днях BTC, проверил детерминизм, дубли, численные ошибки и зависимости — фундамент выглядит нормально.
Сейчас следующий шаг — понять геометрию этого пространства: сколько там реально независимых измерений и насколько они стабильны между днями.
📚 На ближайшее время ещё и такое чтение.
Кстати, недавно исполнилось 30 🙂
Темп сейчас не такой, как хотелось бы, но главное — каждый день понемногу двигаться вперёд.