Объём файлов истории - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ничё не понял. Ну у меня ноутбук. Простенький, меньше, чем за 1000 долларов. Три терминала в постоянной работе по всем символам что есть. Море графических приложений, 3D-, видео- и аудиоредакторов. Файрфокс открыто постоянно не менее 40 вкладок и пр., пр., пр. ...
Из 186 гиг на С свободно всегда почти 2/3 пространства - в данный момент 114. Запас всегда есть. Скоро ещё в постоянку два-три терминала запущу дополнительно к уже имеющимся.
Ещё ни разу не задумался о месте на С, да и на D тоже...
да вот же,... у меня 4 харда по 3тб + SDD на 500ггб для Windows ... мне хватает за глаза
никаких проблем по емкости истории вообще нет
даже МТ и историю держу на SSD что бы получить высокую скорость обработки
...
стон идет от держателей VPS стоимостью 1-5$ - либо бесплатных
где емкость харда от 20гб до 40гб
из которых сама винда занимает больше половины
если у кого то хард меньше 1тб - ну купите хард на 3тб - удалите всякую херню ... с харда
и не надо стонать по поводу объема истории
...
трейдер у которого емкостью харда от 2тб 3тб такие проблемы не поднимает
как вообще можно заниматься трейдингом не имея нормального железа
...
...
стон идет от держателей VPS стоимостью 1-5$ - либо бесплатных
где емкость харда от 20гб до 40гб
из которых сама винда занимает больше половины
если у кого то хард меньше 1тб - ну купите хард на 3тб - удалите всякую херню ... с харда
и не надо стонать по поводу объема истории
...
...Напомню, что вы начали обсуждение со скорости чтения с диска(медленный hdd), а теперь оказывается у вас ssd. То есть, вопрос о скорости чтения не стоит вообще. И 10 гб под расчетную машину выделить не грех. Особенно, если вы реально запрашивали эти данные.
Может все-таки признаетесь, что все дело в упаковке VPS?
Скорость чтения я привёл лишь как один из аргументов, в тех случаях когда стоит обычный hdd. А сама проблема в избыточном объёме информации, это вроде звучало во всех мои постах. Так вот на SSD это особенно ощущается.
Ваш подход совершенно неоправдан. Ну давайте теперь каждый программа будет резервировать кучу избыточного объёма на диске! Документ word будет занимать 1 гигабайт, ради того что его можно было открыть на 10 мс быстрее, и т.д. Вы считаете это нормально? Или что, МТ обладает какой-то исключительностью? С какой стати? У любого человека есть разные сферы деятельности и разные интересы, соответственно используем много различного софта. Когда-то нужен МТ, когда-то VS, когда-то фотошоп, и т.д. И если каждая прога будет так неэффективно забивать диск, тогда и террабайтников не хватит.
как вообще можно заниматься трейдингом не имея нормального железа
Легко. Большинство выбирает трейдинг не для того, чтобы сидеть на одном месте, привязанным к "нормальному железу" и пялясь в кучу мониторов, а наоборот - работать где угодно, имея под рукой лишь маленький ноутбук.
Легко. Большинство выбирает трейдинг не для того, чтобы сидеть на одном месте, привязанным к "нормальному железу" и пялясь в кучу мониторов, а наоборот - работать где угодно, имея под рукой лишь маленький ноутбук.
для торговли хватит маленьких ресурсов - и нафиг история не нужна
для - тестирования и разработок нужны другие ресурсы
портативные машинки не для этого
для торговли хватит маленьких ресурсов - и нафиг история не нужна
С чего бы это вдруг история не нужна? А анализировать вы что собрались? Захотел просмотреть в МТ5 историю по какому-то символу за 10 лет - прокрутил - опа - и 200 МБ на диске ушло. Непонятно на что.
Не стоит так пофигистически относится к объёму хранимой информации, да и вообще ко всему. Любые затраты должны быть оправданы. Если у вас сжирают гигабайты просто так, не давая ничего взамен, то это неправильно. А то что вы думаете, будто это даёт ускорение работы - это миф.
История подгружается с диска лишь изредка, и лишь по тем символам, с которыми ты работаешь в данный момент, например прокручиваешь график. Поэтому время на однократную распаковку несколько мегабайт - совсем мизерное.
Вот если бы эта история постоянно держалась оперативе - тогда другой разговор, тогда ускорение действительно было бы.
С чего бы это вдруг история не нужна? А анализировать вы что собрались? Захотел просмотреть в МТ5 историю по какому-то символу за 10 лет - прокрутил - опа - и 200 МБ на диске ушло. Непонятно на что.
Не стоит так пофигистически относится к объёму хранимой информации, да и вообще ко всему. Любые затраты должны быть оправданы. Если у вас сжирают гигабайты просто так, не давая ничего взамен, то это неправильно. А то что вы думаете, будто это даёт ускорение работы - это миф.
:-) для повседневного трейдинга нужны цены 1996 года ?
а что 200мб это много ? а что непонятного ?
МТ4 МТ5 очень экономно хранят историю
МТ4 МТ5 очень экономно хранят историю
Ок, сдеайте себе плакат с такой надписью, повесьте дома и можете читать вашу мантру хоть каждый день. Я в первом посте всё подробно расписал в цифрах насчёт этой "экономичности". Если вы думать или считать не умеете - ну это ваше право.
Ок , отвечу в Вашем стиле - разработайте себе терминал который будет быстрее мт4 / мт5 экономней и при этом лучше ( это я по поводу плаката )
Почему разработчики хранят историю так как хранят - они имеет опыт разработки системы МТ много лет
Вот согласитесь что Ваш совет для них похож на совет гроссмейстеру с 20 летним опытом - от ребенка младшей группы детского садика увидевшего шахматы пол года назад
насчет приращения - это бред чистой воды ибо что бы прогнать кусок истории в середине или в конце
нужно будет тащить историю с точки старта - добавлять все приращения
понимаете какой это бред ? и какие будут тормоза ?
а еще Вы знаете что 32 битовый процессор на уровне микрокоманд значительно быстрей обрабатывает команды по передачи данных в 32бита чем 16бит ?
т.е. на 32битовом процессоре команда MOV быстрее перешлет 32бита чем 16бит
а на 64битовом процессоре 64бит передается быстрее чем 32бита ...
насчет приращения - это бред чистой воды ибо что бы прогнать кусок истории в середине или в конце
нужно будет тащить историю с точки старта - добавлять все приращения
понимаете какой это бред ? и какие будут тормоза ?
Всё относительно. Вы не забывайте, что это просто архив, к которому обращение происходит очень редко. А помимо него есть ещё файл с кэшем этой истории, из которого собственно и происходит основное чтение. Так вот спрашивается, если есть кэш, то нахрена тогда весь архив держать в распакованном виде?
Однако я признаю, что погорячился насчёт "миллисекунд". Сейчас набросал код по перегонке запакованных приращений в конечный формат MqlRates. Для минутной истории за 15 лет получается 200 мс. Но это в одном потоке, да и процессор тут слабоватый. Если распараллелить, то получится вполне приемлемо. Тем более что эта история обычно не грузится целиком, а подгружается по мере необходимости, и разбита на файлы по одному году. Так что тащить всю историю с точки старта не нужно. Более того, в начале файла обычно помечаются опорные точки, по которым можно быстро перейти в нужный участок файла. Так что это всё не проблема.
Тормоза могут быть только если начнётся подгрузка одновременно по множеству символов. Для обычного юзера это точно не грозит. Да и это однократная процедура. Потом данные будут уже в кэше.