FC2ブログ

雷でUPSが作動!しかしバッテリー稼働時間が少なすぎて...

危うく電源供給が切れる所でしたが、慌ててシャットダウンした所ギリギリで間に合いました。^^;

自動売買のリスク回避の為に購入したUPSですが、購入してから既に7年が経過しており、バッテリーの容量がかなり低下していたようです。

近頃の雷には何度も助けられたUPSですが、定期的なチェックが必要ですね。

今後もしばらくは雷の時期が続きそうなので、早速代替のバッテリーを注文しておきました。

スポンサーサイト

バックテストで高温になったPCを効率良く冷やす方法

EAを開発していく上で避けて通れないバックテストと最適化(オプティマイズ)ですが、今の時期は気温が高い事もあり、PCの熱暴走に気をつける必要がありますね。

そこで、今回はいかにして効率良くPCを冷却するかを考えてみました。

最も手っ取り早いのはエアコンを稼働させる事ですが、様々な事情によってエアコンが使えない環境もあるかと思います。

そのような時は、PCケースのエアフローを考え直すのも1つの方法かも知れません。

私の使用しているPCは自作の為、PCケースも自前で購入したモノなのですが、このケースは至る箇所にPCファンを搭載出来るようになっている為、ケース自体が穴だらけ(ファンの通気の為)になっています。

全ての箇所にファンを搭載するとPC自体が爆音となってしまいそうなので、必要な部分だけにファンを取り付けて使用していました。

購入した当初は涼しい時期だったので気づかなかったのですが、夏の時期になるとPC内の温度が高温になる事が多くなりました。

そこで色々な試行錯誤した結果、空気の入口と出口が明確になるように吸気・排気のバランスが良くなるようにファンをつけ直しました。(ファンをつけていない穴はマスキングテープで塞いでしまいます)

その結果、劇的にPC内の温度上昇が改善されたのです。

この経験から、必ずしも多くの風をPCケース内に送るだけが効率良く冷やす方法では無い事に気付かされました。

地球温暖化対策としてエアコンの温度を下げすぎないようにする事も大事かも知れませんが、このようなちょっとした工夫をするだけでも、間接的に省エネに繋がっていくのだと思います。


EAの最適化には、PCの熱中症に注意!!

やってしまいました。外気温32℃の屋内にて、エアコン無しで最適化作業を30分程。

ちょっと席を外して戻ってきたら見事にブルスク発生。

幸いにもPCへのダメージを受ける前にブルスクになってくれたお蔭で、問題なく再起動出来ました。

人間にも熱中症対策は必要ですが、PCにも熱対策は怠らないようにしましょう。

OrdersTotal()の罠

EAを作成していると、最大ポジション数を制限したりしたい場合が良くありますね。

このような要求を実装する為には「OrdersTotal()」関数を使用する事が多いのですが、この関数にはちょっとした落とし穴があって、戻り値となる値には接続している口座のポジション数の合計数が返ってきます。

これは、「呼び出したEAのポジション数」とは必ずしもイコールにはならないのです。

つまり、自分自身のEA以外のポジション数もひっくるめて合算された値が返ってくるという事です。

EAを単体稼働する事しか想定しないのでしたら、これで全く問題無いのですが、複数のEAを同時に稼働するような運用を想定する場合には、かなり危険な状態と言えます。

例えば、自分自身のEAが決まった時刻に決済するような動作を行いたい時、

全てのポジションを決済した処理の後に、

if (OrdersTotal() == 0)
{
// 決済完了なので、これ以降の新規エントリーはしないようにする。
:
:
}

と書きたくなります。

ところが、もし別EAがポジションを保持していた場合、「OrdersTotal()」は0を返してくれません。

その為、本来は新規エントリーを抑止したいのにもかかわらず、新規エントリーと決済を延々と続けてしまう結果になってしまいます。

mq4ファイルが存在するEAでしたら、ソースの内容を確認する事でこの問題は回避出来ます。ところが、野良EAのようなex4ファイルしか存在しないEAの場合、どのような実装方法になっているかは確認する術がありません。

野良EAに限らず、どのようなEAでも、デモ口座でテスト運用する事は誰しも行う事ですが、複数のEAを同時にテスト運用する事はあまり無いのではないでしょうか?

この問題は、複数EAを同時運用して初めて発覚する問題です。

大事な運用資金ですから、用心するに越したことは無いですね。

注文番号(チケット番号)の豆知識

MT4では1ポジション毎に注文番号、すなわちチケット番号が自動で採番されます。

この値は接続しているサーバー固有の値となっています。

ところで、この注文番号ですが、指値注文時の注文番号が約定した場合に、その時点で別の値に入れ替わってしまう場合があります。

私も最近知ったのですがOANDA口座がそのような挙動をするようです。

一般的な口座では、指値注文時の注文番号とその指値が約定した場合のポジションの注文番号は同一の値となります。

従って、EAを作成する時に注文番号をキーとして指値が約定したかどうかを判定したい場合には、OANDA口座のような場合には通用しないのです。

それでは、どのような実装方法があるのかと言いますと、私も今の所良いアイディアが浮かばないでいます。^^;

注文日時をキーにする方法も考えたのですが、連続した注文では動作が保証できませんし...。

アクセスカウンター
プロフィール

大和

Author:大和
フリーランスのプログラマーです。

EA作成代行承ります
最新記事
カテゴリ
広告
最新コメント
最新トラックバック
月別アーカイブ
リンク
メールフォーム

名前:
メール:
件名:
本文:

ランキング参加中
応援よろしくお願いします。
検索フォーム
RSSリンクの表示
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード