torontoxx
|
Date: 3/11/2019
|
|
|
|
Thanks:
|
|
|
|
|
|
Sun_Storm
|
Date: 4/28/2019
|
|
|
|
|
Добрый день. Пробую сейчас сконвертировать данные через этот конвертер. Данные беру отсюда: http://erinrv.qscalp.ru, за апрель Возникли следующие ошибки: При загрузке данных стаканов по акциям Сбербанка возникала ошибка и данные не грузились. Проблему я решил, порывшись в исходниках. там в исходном файле в начале торгов есть строки с ценой и объемом 0 и типом Unknown. Когда тип Unknown, программа сразу выдает исключение: Code
switch (q.Type)
{
case QuoteType.Unknown:
case QuoteType.Free:
case QuoteType.Spread:
throw new ArgumentException(q.Type.ToString());
Написал пока так для себя, не знаю, как в С# принято такое обрабатывать, когда у нас только 2 значения side: Code
switch (q.Type)
{
case QuoteType.Free:
case QuoteType.Spread:
throw new ArgumentException(q.Type.ToString());
case QuoteType.Unknown:
\\throw new ArgumentException(q.Type.ToString());
side = 0;
break;
Второй ошибкой является то, что для всех стаканов (файл quotes) время проставляется одно и то же для каждой строчки на весь файл. Эта ошибка проявляется и для акций и для фьючерсов. Пока не могу её побороть. сохранение в файл делается средствами StockSharp.Algo.Storages, все исходники там, как я понимаю. По отладке не могу понять, какие параметры должны быть у pair, чтобы в строке registry.GetQuoteMessageStorage(pair.Key, format: format).Save(pair.Value.Item1); запись происходила как надо. Пробовал менять LocalTime и ServerTime для каждого набора, всё равно сохраняет неправильно (со временем 35517549, например)
|
|
|
|
Thanks:
|
|
|
|
|
|
Sun_Storm
|
Date: 4/28/2019
Опытным путем разобрался с проблемой времени! Если у вас в папке, из которой вы конвертируете, лежат сразу 3 файла на день из архива http://erinrv.qscalp.ru (Deals, Quotes И AuxInfo), то конвертация будет некорректной! Я скачивал сразу все 3 файла, и из одной папки конвертировал, поэтому была ошибка. Если в папке лежат 2 файла на день - Deals, Quotes, то всё конвертируется нормально (если не считать ошибки по акциям, описанной мной выше) UPD: В общем это я поспешил, что разобрался, всё равно время некорректно ставится. Ошибка плавающая... Я в потоках этих не разбираюсь... Однако, если прописать вместо ServerTime = currentDate.ApplyTimeZone(TimeHelper.Moscow), ServerTime = qr.CurrentDateTime.ApplyTimeZone(TimeHelper.Moscow), то вроде будет работать и время сменяться. Только в файлах начало дня при таком раскладе будет 4 часа.
|
|
|
|
Thanks:
|
|
|
|
|
|
traveller
|
Date: 11/12/2019
Тип Unknown для quotes действительно надо фильтровать, в файле MainWindow.xaml.cs я добавил Where
var quotes2 = quotes.Where(q => q.Type != QuoteType.Unknown).Select(...
что позволяет сразу выкинуть этот тип из рассмотрения.
И цена бывает иногда нулевая, тоже можно фильтровать при желании.
Для правки времени согласен с постом выше, можно использовать
ServerTime = qr.CurrentDateTime.ApplyTimeZone(TimeHelper.Moscow)
и тогда присвоение currentDate выше можно удалить, оно нигде не используется.
|
|
|
|
Thanks:
|
|
|
|
|
|
MichaelShpin
|
Date: 11/15/2019
|
|
|
|
|
Писал подобную утилиту для TSLab и тоже заметил проблему рассинхронизации стакана и сделок. Как я понял эту проблему: - Есть лаг между событием на бирже и записью в локальный фаил. Он может достигать существенное количество секунд. - Записанный отдельно стакан в Quotes.qsh не имеет того самого реального (биржевого события), а только время локальной записи. - Сделка же летит сразу со временем, и можно увидеть этот лаг между временем записи и времен в самой сделке. При генерации из ордер лога всё хорошо, так как в логе есть все записи, а вот с акциями придётся наворачивать. Как поступил я. Если акция я просто создаю сразу 2 QshReader для Deals.qsh и Quotes.qsh. И начинаю их читать опираясь на внутреннее время записи QshReader CurrentDateTime, и стакан синхронизирую относительно времени сделки. Code
if (readers.Count > 1)
{
while (true)
{
if (readers.All(qr => qr.CurrentDateTime == DateTime.MaxValue))
break;
QshReader rd = readers.OrderBy(qr => qr.CurrentDateTime).First();
rd.Read(true);
}
foreach (QshReader r in readers)
r.Dispose();
}
else
{
QshReader qr = readers[0];
while (qr.CurrentDateTime != DateTime.MaxValue)
qr.Read(true);
qr.Dispose();
}
Есть засада, что стаканы до первой сделки придётся проигнорировать, но в моей задаче была цель узнать лучший Бид/Аск в момент сделки и я её так решил. Надеюсь помог. Думаю скоро погружусь в эту задачу и для StokSharp
|
|
|
|
Thanks:
|
|
|
|
|
|
GIP
|
Date: 11/22/2019
Позвольте глупый вопрос... При импорте данных QSH по инструменту RIZ2019 за 20.11.19 первая строка: 064624425;+03:00;637098399844250000;38091733454;143780;1;Buy;Done;PutInQueue;;;; 64624425 это время в миллисекундах с начала дня, получается 18 часов? Или это 06:46? Первая сделка должна проходить в 10:00 мск.
|
|
|
|
Thanks:
|
|
|
|
|
|
samosh
|
Date: 11/30/2019
Здравствуйте, у меня Qsh2bin не видит файлы QSH
|
|
|
|
Thanks:
|
|
|
|
|
|
Di
|
Date: 12/20/2019
Я не трейдер, меня попросили сконвертировать данные в csv или txt, нашел вашу утилиту, но она выдает ошибку при конвертации. qsh.7z исходные файлы и то что получается SBER@FORTS.7z Что делаю не так?
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 2/22/2020
|
|
|
|
|
Обновил утилиту. Перевел на 17ую версию, заобно пофиксил ошибки. Бинарники так же по ссылке https://github.com/StockSharp/Qsh2Bin/releases
Важный момент при анализе записей. QSH не имеет признака временной зоны у времени. Поэтому понять в какой временной зоне записаны данные невозможно. С большей вероятностью она может быть или Московская или UTC. Точно могу сказать, что Церих и Айти в разных временных зонах пишут данные. Как вишенка на торт - временная зона биржевой даты так же может отличаться от временной зоны локальной метки (хотя, это вполне логично, но вдруг для кого-то сюрприз). Как решить это проблему. Конечно же, надо писать всё в UTC. Но данные и формат уже легаси, поэтому в утилите две выпадающих списка. Один для установка временной зоны локальной отметки, другой для биржевой. После конвертации может Гидрой или через S#.Storage API просмотреть полученные данные на предмет времени. Если начало торгов что-то вроде 7 часов утра - значит временная зона была в UTC. Пишите о своём опыте использования. Ошибки старайтесь сами исправить, исходники на Гите. Папку с рефами не заливал, чтобы не захламлять дистрибутив. Думаю, кто умеет код пистать, эту проблему порешает. Данные по качестве средней паршивости и для пипсовых алгоритмов совершенно бесполезные из-за недостоверной отметки времени и пропуска ряда цен внутри спреда (я про стакан). Но объемы более менее совпадают по итогу. Сервис уже достоин медали, что столь долго существует, и его ещё кто-то поддерживает.
|
|
|
|
|
|
|
zoh
|
Date: 7/15/2020
|
|
|
|
|
Mikhail Sukhov Обновил утилиту. Перевел на 17ую версию, заобно пофиксил ошибки. Бинарники так же по ссылке https://github.com/StockSharp/Qsh2Bin/releases
Важный момент при анализе записей. QSH не имеет признака временной зоны у времени. Поэтому понять в какой временной зоне записаны данные невозможно. С большей вероятностью она может быть или Московская или UTC. Точно могу сказать, что Церих и Айти в разных временных зонах пишут данные. Как вишенка на торт - временная зона биржевой даты так же может отличаться от временной зоны локальной метки (хотя, это вполне логично, но вдруг для кого-то сюрприз). Как решить это проблему. Конечно же, надо писать всё в UTC. Но данные и формат уже легаси, поэтому в утилите две выпадающих списка. Один для установка временной зоны локальной отметки, другой для биржевой. После конвертации может Гидрой или через S#.Storage API просмотреть полученные данные на предмет времени. Если начало торгов что-то вроде 7 часов утра - значит временная зона была в UTC. Пишите о своём опыте использования. Ошибки старайтесь сами исправить, исходники на Гите. Папку с рефами не заливал, чтобы не захламлять дистрибутив. Думаю, кто умеет код пистать, эту проблему порешает. Данные по качестве средней паршивости и для пипсовых алгоритмов совершенно бесполезные из-за недостоверной отметки времени и пропуска ряда цен внутри спреда (я про стакан). Но объемы более менее совпадают по итогу. Сервис уже достоин медали, что столь долго существует, и его ещё кто-то поддерживает. А АйТи ещё продолжает шарить записи с qscalp ?
|
|
|
|
Thanks:
|
|
|
|
|