忍者ブログ
最新記事
カテゴリー
ブログ内検索
カスタム検索
TradersShop検索

リンク
プロフィール
HN:
さとしぃ
性別:
男性
趣味:
ゲーム、読書、インターネット

Mail:forexsystecpractice☆gmail.com
☆→@

自己紹介:


06/12/04 立ち上げ。夢のためにFXを06年3月からやっております。

08/05/11 システムトレードの勉強開始。ソフトはMT4を使用。

08/08/06 FXDDにて自動売買を1000ドルの資金で開始。

08/10/09 3000ドルからまさかの大転落。100年に1度の金融危機で生き残ったシステムはたったの三つ。

08/12/09 3000ドルの資金を再投入。 徹底的に本を読み続けています。

09/03/22 7700ドル達成。

09/08/14 1000ドル割れ。

09/12/17 3500ドル復帰。

10/04/09 修行中

14/11/21 パワーアップして再挑戦



アーカイブ
カウンター
RSS
<<   2024   03   >>
 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31 
19 March 2024            [PR]  |   |
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

02 October 2022            引っ越し  |  システム開発  |  C:0  |
こちらへ引っ越します。

拍手[0回]

PR
多通貨、多指標のテストをMT4で実施しようとすると、
ほぼ不可能(ファイルやMarketInfo関数、DLLなどを駆使すれば可能だが・・・)だ。

実際に作ってみたのだけど、バックテスト時間が膨大に掛かり現実的ではないと判断した。
そもそも多通貨指標(Ku-Powerなど)をバックテストで利用すると、
バックテスト終了時のチャートオープン時に大量のKu-Chartがサブウィンドウに展開される。
iCustomの呼び出し毎にサブウィンドウに追加されているとしたら、各バーごとの計算量は恐ろしいことになっているはずで、その可能性が高いと思われた。

悪あがきは色々したのだが、どうやってもバックテスト時間が長すぎるため、MT4の継続利用は断念した。
そこで円滑なトレードシステム開発のため、経験の長いJavaでバックテスト機能を開発することにした。
他市場の多指標も使えるし、多通貨の指標も使える。
インディケーターの実装も自分で行う必要があるから、勉強にもなるし、いいことづくめだ。

そもそもMQLでは難しかった単体テストの領域も
Javaであれば、Junitにより容易だ。


いったん、最低レベルの目的地点まで到達できた。
1テスト20分以上かかっていたテストが、15秒程度で完了するようになった。


作ってみて思ったのは、スクラッチであるメリットについて。
スクラッチなのだから当たり前だが、バックテスト結果の統計情報として、
様々な情報を計算して出せるため、多角的な視点から諸々の情報を俯瞰できる。

資産残高のHWMの未更新期間、シャープレシオ、平均保有期間など。

拍手[1回]

12 June 2017            構築日記  |  システム開発  |  C:0  |
ティックフィードの再構築中。
mt4 →dll→(ソケット)→サーバまでの一連の流れの実装が一巡した。
ソケットプログラミングは初めてだったが、形にはなった。
例外検知については、調べれば調べるほど奥が深いことがわかってきた。
今の所、実装出来たものとしては、mt4 とフィードサーバの疎通監視のみ。
mt4 とブローカーとの疎通監視はまだ出来てない。他にも気になる例外検知はまだ実装出来てないし、そもそも事象に対する理解もイマイチ。

フィードサーバの環境見直しをしていたところ、メモリ8gであるべきところが4gしか認識していなかったので来週直したい。

nuroに回線を変えた。満足いく速度が出た。回線工事まで1ヶ月以上待ったがその価値はあった。

mt4 稼働サーバは有線LAN環境に移行したい。時間が足らず、無線LAN環境にて今週は乗り切ろうと思うが、先述の切断検知のテストとして割り切る態度も必要か。

今回、フィードに関する実装はとにかくプロジェクトごとの責務を細分化し、クラスにおいても細分化した。
命名が適切であればあるほど、設計記述は省けるはずだから、ここはもっと詰めていきたい。
マルチスレッドプログラミングも行なっているが、フィード受信スレッド、永続化スレッド、切断監視スレッド、マネージャスレッドなどに細分化した。まだまだ増えるだろうが、適切な命名を心掛けたい。
コードを読むより、パッケージと名前を読ませることで、何をしているかを示した方が良いだろうと考えている。将来の自分が見た時にどこで何をしているか分からないコードにはなんの価値もないだろうから。

拍手[0回]

14 May 2017            構築日記  |  システム開発  |  C:0  |
ここ数年は、私生活でいろいろ変化が激しかった。
人生の重要なイベントが1巡した。

時間ができたとは中々言いづらいが、シストレ(実際はシステム構築だが)を再開しようと決心した。
はっきりいって、仕事にまじめに従事していれば生活できる収入はできるし、特に仕事が辛いというわけでもない。不満がないわけではないが、不満を溜め込む性格は矯正し、いかに自分が変わるか、いかに自分の存在感を出し、価値を認めさせるか、そういった働き方にシフトしている。

シストレに関して今までやってきたことが、何の意味もないことは理解したくらいには成長した。ラッキーパンチが当たっただけの素人が勘違いしていたことも痛感している。

これまでここで書いてきたことは無意味とまでは言わないが厚みのない記録だ。だから、新しい場で成長した自分として、記録を残そうかとも思ったが、やめた。
過去を認める意味も含めて、ここで新たな姿勢で記録を残していく。


さて、今後の計画だが、やはりティックデータの収集をしたい。
理由はいろいろある。
ティックベースのシステムの開発をしてみたい。
自分が勝てるフィールドは必ずあるはずだ。そこを探す。

以前に構築したMT4-DDL(JNI)-Java(RMI)のティックフィードシステムだが、RMIを採用した理由はC言語を極力やりたくないという逃げの姿勢が前面に押し出たものだ。
JNIやRMIという本来不必要なものを利用しており、冗長というほかない。
Java側のソースコードも汚く、後から見るとどこで何をしているのか分からない、クラス分割も甘い、情報の取り扱いも冗長と無駄と複雑の積み重ねのようなプログラムとなっていた。
結局、人(私)がバグっているから、良いシステムが作れなかったということに他ならない。
これは、捨てる決心をした。

だが、ティックを取り扱うメインのシステムはJavaとしたい。
長年使っているeclipse上の開発が自分にとって開発コストの面でメリットとなるからだ。


ティックデータの収集方式については、理想はTCP/IP通信ベースによるFX業者システムへの接続、フィードの収集だが、今のところあらゆるハードルが高いため断念している。

上記の事情もあり、以下の構成を検討している。
MT4(DLL)→ソケット→Java→DB

基本的な実装コードの検証はできた。
10万件連続送信しても2ミリ秒程度というレベルであるため、速度的には問題なさそうである。

異常検知系が経験的にも弱いので、ここをどこまで詰めるかという話になってくる。

拍手[0回]

さらなる安定化を目指しメモリ増強に着手。
なぜか、認識はされるがハードウェア予約済みとなっており、OSの手元にいかない。
msconfigのブートオプションのメモリ最大値のチェックを外してみる。
起動しなくなるw
しかも、BIOSから。

メモリを元の4G2枚挿しにし、起動。
BIOSは起動したが、OSは起動しない。
何度か試行すると、OSがセーフモードで立ち上がる。
そこからバックアップドライブよりイメージ復旧。

ここから格闘すること3日ばかり。

ハードウェア予約済みとなっていた理由は、どうも、メモリの一部をRAMディスク化していたせいだったようです。
RAMディスクを解放し、再起動すると増強したメモリの認識に成功しました。

いやはや、外付けバックアップドライブにバックアップがあって九死に一生を得ました。

拍手[0回]

先週の途中でCPU高騰が再発。
再び再調査。
DLLからJNIゴール後のjstring型を解放していなかったために、一定以上の生成数を超えるとCPU使用率が高騰していたことが分かった。

これを修正し再稼働させたところ、金曜夜においても問題なく稼働した。
金曜においては、CPU使用率がそれぞれのターミナルで4,5%の推移、メモリはそれぞれで500MB以下で推移した。

今後はフィーダーの安定稼働を目指しつつ、分析や検証の体制を作りたいところ。グラフィカルな分析環境を作れればモチベーション維持にも役立てられるのでそこは重点的に進めたい。

拍手[0回]

一週間稼働してみたが、まだまだコントロールしきれていない。
少なくともRMI関連のエラーは出なくなり、
フィード受信経路とDB接続経路は安定的に接続できている模様。

稼働の結果、一点問題が発生。
3つほどのブローカーのterminal.exeを稼働させていたが、1ブローカーのterminal.exeのCPU使用率が高騰。
原因は不明。
少なくともCPUがcore i 7であるため、処理量に依存したCPU高騰ではない可能性が高い。
処理待ちとグローバル変数の参照を実装したために問題が起きている可能性が高い。

よって、来週は処理待ちを組み込まない実装を以て迎えたい。

拍手[0回]

9か月振りに少しアイディアが出来たので再開。
売買は一切していません。
スマフォげーと格ゲーばっかりやっていて、
残業もしていないのでワープア入りを果たしそうなため、
そろそろ戻りたいところ。勝てるのかは不明だが・・・

前回の記事で出たエラー群はおそらくノートPCとNUCPC間の通信切断が原因。
NUCPC側に余った無線LAN機をコンバータで接続したので、
明日から再稼働してみて様子を見たいところ。


拍手[0回]

例外発生時にメール通知が出来るよう
GMail連携を作りjarに組み込んで一週間稼働させた結果。

以下の例外が発生した。

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: ・・・1回発生
 Communications link failure

 The last packet sent successfully to the server was 0 milliseconds ago.
 The driver has not received any packets from the server.
  
 Caused by: java.net.ConnectException: Connection timed out: connect

一回のみ発生。DriverがgetConnectionする際に発生。
 closeを早く呼び出しすぎると発生するようだ。
  参考URL

java.lang.NullPointerException ・・・1回発生
 実装バグ。

java.rmi.NoSuchObjectException: no such object in table ・・・4回発生
 RMIサーバーからオブジェクトが外れてしまっている。
 レート配信間隔が大きすぎて、RMIサーバーから外れたのか?
 java.rmi.dgc.leaseValue を大き目に設定する必要がありそうだが、
 デフォルトは10分らしい。10分も配信されないことを問題視したいが・・・。
 もしくは外れるのは別に問題ないとして、外れる際の動作を規定すべきか。
 参考:RMIで公開されたオブジェクトが破棄される時を知る

java.rmi.ServerError: Error occurred in server thread; ・・・1回発生
 nested exception is:
 Caused by: java.lang.NoClassDefFoundError: Could not initialize     
  class 
com.google.api.client.json.jackson2.JacksonFactory$InstanceHolder

原因不明。

⑤java.rmi.UnmarshalException: Error unmarshaling return header; ・・・1060回発生
 nested exception is: java.io.EOFException

これ?

他には、UnmarshalException

リモートメソッド呼び出しのパラメータまたは結果を非整列化しているときに、次の条件のどれかが成立した場合にスローされます。

  • 呼び出しヘッダを非整列化しているときに例外が発生した場合
  • 戻り値のプロトコルが無効な場合
  • パラメータ (サーバ側) または戻り値 (クライアント側) を非整列化しているときに java.io.IOException が発生した場合
  • パラメータまたは戻り値を非整列化しているときに java.lang.ClassNotFoundException が発生した場合
  • サーバ側でスケルトンがロードできない場合。なお、スケルトンは 1.1 スタブプロトコルでは必要だが、1.2 スタブプロトコルでは必要ない
  • メソッドハッシュが無効な (つまり、メソッドが見つからない) 場合
  • 非整列化時に、リモートオブジェクトのスタブに対するリモート参照オブジェクトの作成でエラーが発生した場合
⑥java.rmi.ConnectException: Connection refused to host: 192.168.10.101; ・・・1099回発生
 nested exception is:
        java.net.ConnectException: Connection refused: connect
 Caused by: java.net.ConnectException: Connection refused: connect

 ローカルホストにつなげられない。
 この例外が出るケースには、インスタンスが停止している場合も含まれる(独自調査)。 
 ⑤も同じ原因か。

⑦MT4にて、、、 
indicator is too slow, 16547 ms. rewrite the indicator, please
 ティック送信エラーの影響か?

■対応
根本原因がつかめていないので、ログを詳細化する方向も考えたい。
インスタンスが異常終了して処理継続できていない状況とも考えられるため、
異常終了をしないようエラー検知のみにとどめるよう動作を変える。

sun.rmiプロパティsun.rmi.transport.logLevel、sun.rmi.transport.tcp.logLevel、sun.rmi.client.logCalls、
sun.rmi.server.logLevel、あたりの設定を有効化、詳細化する。

・RMIサーバが異常停止しないよう動作継続は許す。

拍手[0回]

時系列解析を学習しているとホワイトノイズが頻出してくる。
平均および分散を指定しホワイトノイズを生成したくなる。
なかなかネット上に理解出来るものが転がっていなかったので、
調査のうえ、以下で実装できることを確認した。

ポイントは、RandomクラスのnextGaussian、
初期化時の分散→標準偏差への変換で、正規分布の標準偏差を指定の分散で拡大できる。
以下ソース。
public class WhiteNoise {
protected Double average;
protected Double standardDeviation;
protected Random random;
public WhiteNoise(Double average, Double variance) {
this.average = average;
this.standardDeviation = Math.sqrt(variance);
this.random = new Random();
}
public Double calc() {
return average + random.nextGaussian() * standardDeviation;
}
public static void main(String[] args) {
WhiteNoise whiteNoise = new WhiteNoise(0d, 2d);
for (int i = 0; i < 1000; i++) {
System.out.println(whiteNoise.calc());
}
}
}

エクセルで検証した結果も問題なさそうである。

拍手[0回]

開発環境は十分整ったところで問題が発生した。

手持ちのPCとして、IntelNUCとノートPCがあるが、
開発はIntelNUCで行い、
遊びにはノートPCで行いたかった。

ティックフィードは開発機であるNUCに切り替えて継続したかった。外付けHDDもこちらに接続した方が都合がよかった。
しかし、開発機に切り替えたところメモリがまったく足りなかった。
8G中ほぼ7.8Gは占有していたかと思う。
コミット周期を短くすれば解決しそうだが、記憶媒体に負担を掛けたくないので、
その選択は出来なかった。

ノートPCはもともとガチなPCが欲しくて買ったものだ。
かなり高スペックでメモリは32Gb積んでおり、CPUもi7を載せている。

つまり、
・ノートPCの潤沢なリソースを遊び用だけに使うのは意義に欠ける
・IntelNUCは開発機として利用する
・外付けHDDはIntelNUCに接続する

上記を達成するには、以下の役割分担となった

ノートPC:ティックフィード受信&蓄積サーバ
IntelNUC:MySQLサーバ
外付けHDD:データ保管場所

この2週間、この体制を構築するために奔走していた。
この期間で学習したことは、足場はまだまだ脆いということだ。

データを受信し、転送し、貯めこむ。
ただそれだけのシステムなのに様々なことを考えないといけない。

それと痛感したのは、自分が発想したことは、
大抵すでに誰かが発想しており、失敗しているか、成功し遥か先に進んでいるということ。
ティックフィードのアーキテクチャは、ほぼ0から実装したけれど、Java部分に関してはJMSと呼ばれるもので、代替可能であるようだ。

結局下調べが甘いままに着手したため、引き返せず拘ってしまった。

拍手[0回]

これ(SOHORAID SR2

とこれ(HGST 0S03663

で整いました。
これらを合成して、

こんな感じに。かっこいい・・・。

USB3.0&RAID1で利用開始。
速度は・・・

おっせええぇぇ!
RAID1だから???
USB3.0ポートに設定したはずなんだが・・・。

ポートを変えて再チャレンジ

速度でたー!
まぁ、バックアップ用なので速度そこまで重要ではないけれども。

ポート1個死んでるかもしれん((+_+))

拍手[0回]

現在ティックフィードを受信PCに直接取り込んだティックデータを保存している。
PC用のディスクはSSDであり、OSのインストール先も同ディスクである。
早く以下のようなバックアップフローを踏みたいと考えている。
(考えているうちに購入に至っている記事である・・・)

PC→USB3.0接続(外付けHDD(RAID1))→BD

将来的にはBDへ焼いて直近データのみを外付けHDDに貯めこみたい。

さてこれを実現するにあたって必要なものはRAID1を構成するストレージである。
候補は以下2つとなっている。

ラトックシステム USB3.0 RAIDケース(2.5インチHDD/SSD2台用) RS-EC22-U3R
6G eSATA/USB3.0 2ベイ RAID0/RAID1/JBODストレージケース SOHOTANK ST2-SB3-6G

①は、安価で、異常時のブート音やメール通知機能を持つ監視ソフトが付属している。ファンレスのため、SSDでの運用を検討すべきと考えている。2.5インチディスクのみ対応している。RAID0,1対応。若干ダサい(重要)。
②は、①より高価であり、異常時のブート音やメール通知などの監視ソフトは付属していない。ファンが付いておりHDDの運用も検討出来る。格好いい。

まとめるとこんな感じ
  異常時
ブート音
監視
ソフト
ファン 2.5インチ 3.5インチ RAID 自動
リビルド
× × 0,1
× × 0,1 ×

自動リビルド○が付いている①が最有力だが・・・。
ガシガシトランザクションが発行されても良いようなものを目指すと、
HDDがより検討しやすいファン付の②が有力候補である。

では、搭載するディスクはどう選ぶか。
わがままを言えば、信頼性の高いエンタープライズ向けディスクが理想。
しかし、SSDもHDDもエンタープライズ相当のものを探すとかなり高価。

コンシューマ向けで信頼性の高いものは何か。。。
以下ページですぐに分かった。
HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに
今年の統計データである。
上記公表データによればHGST(日立)一強のようだ。
ただ、HGSTはすでにWD社に買収されたとのことだ。
しかしHGST a Wetern Degital Companyというロゴになり、ブランドとしては存続という形の模様。

HGSTで検討したいが、さらなる細かいブランドで構成されているようだ。
・Ultrastar
 24時間365日稼働を前提としたモデル
・MegaScale DC
 年間180TB程度の利用を前提としたモデル
・Travelstar
 携帯性に重きを置いたモデル
・CinemaStar
 ビデオ再生向けの静音モデル
・Endurastar
 環境変化、耐衝撃に重きを置いたモデル

UltrastarかMegaScaleDCだろうか。

より調査を進めると、パッケージ販売や組み込み販売をする前提で卸した企業向け製品の在庫は、PCパーツ専門店などに売却され、部品ごとに分解されたうえで販売されるようだ。
これをバルク品と呼ぶらしい。

HGSTのバルク品を探すと、AMAZONでもすぐに見つかった。
HITACHI HDD HTC SATA3G 3.5"1TB/7200 32M HUA722010CLA330 並行輸入品 HUA722010CLA330
これは、上記ブランドのUltrastarの系列になる。

それ以外にもNAS用として、以下のものが新しく期待度は高い。
HGST(エイチ・ジー・エス・ティー) Deskstar NAS パッケージ版 3.5inch 3TB 64MBキャッシュ 7200rpm 0S03663
キャッシュサイズ、回転数、容量、AFT対応済みと申し分ない。

ということで、本来なら
①+HGST*の組み合わせを採用したい。となるが、
デザイン性は日々のモチベーション維持に重要だと考えているので、
②+HGST 0S03663×2
とした。

しかし、さらなるハイセンスなバージョンがあり、こちらを採用。
デンノー SOHORAID SR2 (eSATA/FireWire 800/USB3.0) SR2-WBS3
シナジーストアという通販サイトで購入。今回の購入で売り切れとなったようだ。
USB3.0、3.5インチ対応、ハイセンスなケースに液晶付、RAID0,1対応、ファン付ということで、
自動リビルドが残念ながら無いので、片側のHDDが死んだ際は、電源を落として復旧作業というが必要な冗長(?)構成となった。注文したばかりなので届くのが楽しみ。

参考情報
Googleによると、ハードディスクは温度や使用頻度に関係なく故障する

拍手[0回]

・偏自己相関の計算がやっと出来た。
 いろいろ本を読み漁って、結局「経済の時系列分析(著:山本拓)」に書いてあった逐次計算方式を実装して、Rと計算結果が合致することを確認。
 疲れたー。

拍手[0回]

・メール通知機能
 通知機能におけるメール内容で統計データを盛り込みたく統計機能を充実させる方向で開発中。
 モチベが維持出来ていれば良いので、本末転倒となりながらもOKとする。

・統計機能
 自己相関まで完成したが、偏自己相関で予想どおり躓いている。
 Rの出力結果と合わないので困ってる。

拍手[0回]

・OAUTH2.0&GMAIL&Java をローカル環境で実装
 かなり大変だったけど、道筋は通るようになった。

 OAUTH2.0は、アプリケーションがユーザーデータを扱うにあたって、
利用するユーザーデータの範囲(スコープ)について申請を行い、
一度ユーザーの認証を受けたら、それ以降はユーザーの同意なしで利用継続する認証技術のようです。
 ・Googleのデベロッパーコンソールよりメール送信用のプロジェクト新規作成
 ・API>APIよりGmailのAPI使用許可
 ・API>認証>新しいクライアントID作成>installedアプリケーション>その他
 ・Jsonキーファイルをダウンロード
 ・Javaにて、
  ・GoogleAuthorizationCodeFlowを生成
  ・credential = new AuthorizationCodeInstalledApp(flow, new LocalServerReceiver()).authorize(userId)
   ※userId=認証のクライアントID
  ・実行後、ブラウザが立ち上がりグーグルアカウントへ認証要求が来るのでOKする。
  ・以降credential.refreshTokenでトークン最新化し利用する。
  ・認証済みcredentialを利用し、Gmailインスタンスを生成。
      Gmail service = new Gmail.Builder(transport, jsonFactory, credential)
       setApplicationName(APP_NAME).build();
  ・メール送信なら、 service.users().messages().send("me", msg).execute();
  ・あとは好きに利用。
  
 メモレベルだが、しっかりまとめたいなぁ。
 とりあえず、これで毎日のフィード件数をメールで受信しよう。
 統計データも多少混ぜていき、日々のモチベーション維持システムを作る。

 OAUTH2.0に関するGoogleのサンプルコードは大量にあるし、ヘルプも充実しているので何とか。日本語ブログによる実装は少なかった・・・。

・MySQLバージョンアップ
 稼働確認中。dumpインポートまであっさり。


拍手[0回]

今週は一度もCPU使用率の高騰を迎えることなく、
メモリリークをも起こらず過ごせた。
ティック受信と取り込みまでの仕組みについては実装完了としたい。

6ブローカーで1.4Gb/1weekとなった。
1.4 * 1年(48) = 67.2Gb
データ量は、そんなに焦る必要は無いかな。
ただ、ファイル単位のサイズは抑えていきたい。
通貨ごとのibdファイルに出来ているけど、パーティション別のファイルに分割したい。
MySQLのバージョンアップを行えば出来るとのことなので、この土日でやりたい。

次は監視体制を整えたい。
ティック受信間隔を取っていると数十秒の間隔が発生していることがある。
MT4クライアントとサーバの接続が途切れていたり、
そもそものネットワークが切断されていたりする可能性がある。

ティックの受信間隔を指標とした場合に上記の問題を無視できない。

・メール通知
 OAUTH 2.0のAuthorizaitionCodeをもらえるとことまで来たが、
 ローカルマシンからGmailへ利用することが出来ない。困った。

拍手[0回]

・ブログのレイアウト変えました
 ブログのページレイアウトがごちゃごちゃしていたので
 シンプルなものに変更しました。
 タイトルは変えようか悩み中。


・メモリリークについて
 ソースコードの見直しを行い、定期コミットのタイミングで参照が残りそうな箇所を修正した。
 DLLには、JVM生成オプションにVisualVMのVisualGCから詳細なメモリ状況が分かるようJMXを追加。
 ヒープメモリは綺麗な直角三角形になった。
 しかし、Old領域に少しずつメモリが残留しているようでなんだろうとは考えている。週次の再起動で済むなら、これ以上の深追いはコストに見合っていないとも感じている。


拍手[0回]

この頃毎日試運用状態で、帰宅するたびにCPU使用率が高騰していた

原因は、JVMのメモリ不足でCPUの性能が良すぎたのか狭い机で、

ものすごく手早く作業をしていたような状態だったようでcpu高騰という形で顕在化していた。



いまは、悲しいことにメモリリークが見られているため、

プロファイラーを用いたり、ソースコードを見直したりしている。



また上記の原因究明のなかで、MT4→DLL→JNI→RMI→DBの流れを可視化したが、

思った以上に俯瞰する効果が高かったので怠惰せず、立ち止まって可視化するプロセスは継続したい。





拍手[0回]

■平均の計算方法
平均を計算する方法は、
①毎回指定時刻から過去へ遡って各値の合計を行い、平均期間で除算する。
②平均量をから期間外となり除外するもの、期間内となり追加するものを考慮して計算する。
2つの方法がある。

②の具体的イメージは以下のとおり、i はデータの並び。真ん中の平均は5期間平均で、現時点がi=6となった瞬間の処理内容である。期間外となるi=0データを除外し、期間内となるi=6データを追加することで計算量の増大を防ぐ。



■実験内容
上記2つの方法において、
値の範囲:1~1000万
値の増加方法:1ずつ
平均期間の範囲:1から99(下記図の横軸)
平均値算出回数:(1~99) × (1000万)
1から99の期間ごとに、1000万回シフトして平均計算した時間(ミリ秒)の遷移を調べた。

・赤字が逐次計算
・青字が平均量計算


凄まじい違いが出た。
時々青字(平均量計算)でブレているのは検証方法の問題ではなく、おそらくJavaの問題。
ある回数のメソッド実行が行われると、最適化が走りJavaバイトコードへのコンパイルが再度行われるとか。

計算回数および平均期間が増大するごとに、①の逐次計算は指数関数的に処理時間が伸びる。
②の平均量計算は、計算回数に対しては一定で、平均期間が増大すると線形に増加する。

拍手[3回]

07 April 2013            最近やってたこと  |  システム開発  |  C:0  |
おそましておめでとうございます。

完全放置でトレード自体もなんの狙いもないトレードを1、2回した程度(しかもマイナス)です。
格闘ゲームばかりやっていました。

■ティックフィードシステムの開発
今年に入ってからは、FXについては少し距離を置いてましたが、置くなりにデータは貯めようという想いの元、ティックフィードシステムを作成しました。

ティックフィード自体はEA+MYSQL用DLLという組み合わせで以前作っていて、一世代前のPCでは取込を行っていたのですが、これが完全にバカでした。
このMYSQL用DDLの作りが1ティック=1コミットとなっており、それをSSDに対して行っていたので、SSDの劣化は恐ろしいスピードだったのでしょう。わずか一年でSSDが昇天しました。

この反省を生かし、次のような構成にしました。
EA+ティックフィードDLL+ティックフィード溜め込みJavaプロセス(RMI)+MYSQL
なぜJAVAなのかといえば、Cで深く実装するスキルが全くなかったこと、仕事ではJavaがメインだったことが理由です。

EAは純粋にティック単位でDLLへティックデータを引数に関数呼出を行うのみ。※問題①
DLLでは、受け取ったティックデータに対して、システム時刻を生成して、それをJavaプロセスへ送信します。※問題②
Javaプロセスでは、受け取ったティックデータをインスタンス変数へ設定し、Listへ追加し溜め込みます。ティックデータが来たタイミングでコミット間隔時間以上経過していたら、その時点で溜め込まれているティックデータをすべてSSDへ永続化します。そのあとは、ティックデータをクリアし、再度ティックデータの受信を待ちます。

■問題
①Windows8でのMT4とDLLの稼働条件
かなり気づくのが遅かったのですが、terminal.exeにXP互換起動設定を行うだけでは足りませんでした。
EA→DLLの連携の際に、4023エラー(詳細不明)が発生してしまいフィードの継続ができなかったのです。
解決策は、簡単で「管理者権限で起動する」により起動することで解決しました。

②正確なシステム時刻
実は今も曖昧な部分ですが、その時刻に受信したのだからその値だとして進めるしかないという結論にいたりました。
調べてみても2000年以前の記事が多く、最近でもOS WINDOWSの仕様による部分が占めていて、MS社に問い合わせを行うしかないです。
Cで取得しても、Javaで取得しても、ミリ秒以下の分解能を持っているとしか思えず、
仮に現実の時刻と多少ズレていたところで、なんの問題もないことが結論で出たので良しとしています(というより現実時間とPC時間がズレいて優位性を失ってしまう戦略は繊細過ぎて現実的ではない気がします。それでも挑むとしたらGPGPUやCUDA、コロケーションの利用など、技術的・金銭的にも高難度の問題をクリアしていく必要があります。これ以外にもたくさんの問題があるのでしょうが知る由もありません。)

■ティックフィード開発で得た知見
ティックデータを使ったトレードシステムを開発する上で、
ブローカー→PC間の通信時間は知っていて損はないと思います。
注文→ブローカー→約定
の間の時間を知ることで現実的なバックテストが実施できるからです。

■これからやること
・GUIの検証システムの充実
GUIを用いたグラフィカルな分析をガンガン出来るようにしていきたいと考えています。
既に、基本のシステム構成は製造済みで、検証観点に注力出来るような構成になっています。

・高校数学の復習
結局難しい本を読む上でここをおさえておかないとにっちもさっちも行かない。

・時系列解析、機械学習、その他統計の理解
オリジナルの考えも大切ですが、同じくらい先人たちの試みも重要です。この領域の勉強は難しくて、どういう前提が置かれた上で成り立っているのか分かっていないととんでもないことをしてしまう怖さがあります。

・考えを深める
仮説を立てることはしょっちゅうやっていましたが、子供の想像の域を脱しておらず、またそれに対する検証があまり無かったのが正直なところです。
前述したGUI検証ツールにより、随時仮説検証を行い、相場に対して明言出来ることを増やしていけば自ずと答えは出せるようになると考えています。

拍手[2回]

忍者ブログ/[PR]

Template by coconuts