MQL5クラウドネットワークのリソースコスト計算式に関する公開討論会

 

MQL5クラウドネットワークは日々、活発に呼吸を始めています。一歩一歩バグを修正し、リリースを近づけています。

分散計算を ご存じない方のために、典型的なクラウドコンピューティングエージェントのスクリーンショットをいくつかご紹介します。



クライアント端末では、以下のようなネットワークが表示されます。



今後数ヶ月間、MQL5クラウドネットワークは、開発者が最大のバグを発見し修正できるよう、パブリックテストモードで運用されます。今のところ、ネットワークは無料モードで動作しています。ネットワーク上の作業工程が安定し、消費されたリソースの完全なアカウンティングが可能になり次第、リリースする予定です。

皆さんには、 自分のエージェントを 積極的に ネットワークに接続 し、深刻な負荷がかかった状態でクラウドをテストしてもらうことにしています。テスト終了後、エージェントを提供した参加者全員にボーナス(出金・使用可能)が与えられます!(※)。



そろそろ、ユーザーなら誰もが気になる「資源の売買価格は いくらになるのか」という問題を提起してほしい。

議論を始めるにあたり、いくつかのパラメータを取ることが提案されています(各エージェントに個別に)。

TIME    - затраченное время на расчет задачи(пакета задач) в миллисекундах

PR      - индекс производительности агента (недостоверная величина, фальсифицируемая)

PRICE   - автоматически высчитываемая цена за единицу работы (самое сложное)

PRJOB   - единица работы в виде 1 единицы PR за 1 ms времени TIME


вспомогательные величины:

BUYERS  - количество покупателей (количество работ в очереди)

SELLERS - количество продавцов (агентов)


例えば、エージェントごとのリソースの総販売価格は、次のようになります。

TOTALPRICE   = TIME * PR * PRICE


数式は非常にシンプルで、エージェントが改ざんできるようなPRの正規化もありません。チェックや正規化、チート対策は後回しにしましょう。また、サービス維持のため、決済ネットワーク主催者に有利なように価格から少額の手数料を徴収します。


資源コストを見積もるには、「500円でパソコンを購入し、夜間にレンタルしてコストを回収したい」という発想もありでしょう。単純化すると、電気代、冷房費、インターネット代などの関連コストを省き、3つの指標に注目することができます。

  1. コンピュータの費用(例:500ドル)
  2. 投資回収期間(夜間8時間、TIMEで2年間)
  3. ディーピーオー

1PRあたり1msのコストを計算してみよう。

Всего часов           = 360 дней * 8 часов = 2 880
Всего миллисекунд     = 2 880 часов * 60 минут * 60 секунд * 1000 миллисекунд = 10 368 000 000 ms

Стоимость 1PR за 1 ms = 500 долларов / 10 368 000 000 ms / 100 PR = 4,8225308641975308641975308641975e-10 доллара


このコンピュータの1時間分の資源販売コストを試算するために、簡単な計算をしてみましょう。

Миллисекунд                 = 60 минут * 60 секунд * 1000 миллисекунд = 3 600 000 миллисекунд

Стоимость 1 часа при 100 PR = 3 600 000 миллисекунд * 100 PR * 4,8225308641975308641975308641975e-10 доллара = 0,17361111111111111111111111111111 доллара


このパソコンを1時間借りると17セント、8時間の徹夜作業で1.38ドルかかることが判明した。

これは売り手側の「少ない」ですが、買い手側にも目を向けなければなりません。ある価格では、買い手がつかないかもしれない。


適正な価格を見つけるためには、単価を自動的にバランスさせる何らかの仕組みが必要である。そして、この仕組みは単純な操作から保護されなければならない。

現時点での買い手/売り手の数、あるいはその一日の平均値やそれに類する値を調整要素として用いることができる。

あるいは、資源単位の開始価格を算出し、1~3カ月に一度、サービスの活性度(買い手と売り手)に応じて、公表しながら手動で修正することも考えられます。


ここまでは、すべて提案レベルの計算です。ご意見、ご訂正、または独自のバージョンをご提案ください。

 
Renat:

資源コストを見積もるには、「500円でパソコンを購入し、夜間にレンタルしてコストを回収したい」という発想もありでしょう。単純化すると、電気代、冷房費、インターネット代などの関連コストを省き、3つの指標に集中させることができます。

  1. パソコン代
  2. 投資回収期間(夜間8時間、TIMEで2年間)
  3. ディーピーオー

1時間あたりの電気代とインターネット通信量を加算)
 
sanyooooook:
時間当たりの電力消費量やインターネット通信量も加算する必要があります)。
簡単のために、これらのことはすべて、希望する「回収価格」にすでに含まれていると仮定してもよい。
 
Renat:


このサービスの需要を、単位時間当たりの顧客消費者数で、大まかに、あるいは非常に大まかに見積もっていないのでしょうか?例えば月間1,000人のオリジナルカスタマー=コンシューマーがサービスを利用したことがあるのか?

ロシア人以外も含めた第4、第5フォーラムの訪問者に、「原則的にお金を払ってサービスを受けるコンピュータを提供する用意があるが、支払額はまだわからないという条件の人は誰か」というテーマで、今月中にアンケートを取るのが筋ではないでしょうか?

 
Mischek:

このサービスの需要を、単位時間当たりの顧客消費者数で、大まかに、あるいは非常に大まかに見積もっていないのでしょうか?例えば月間1,000人のオリジナルカスタマー=コンシューマーがサービスを利用したことがあるのか?

ロシア人以外も含めた第4、第5フォーラムの訪問者に、「原則的に金銭を対価とするサービスのためにコンピュータを提供する用意があるが、支払額がまだ不明であることを条件とする人は誰か」というテーマで1ヶ月間調査を実施するのは意味があるのかもしれませんね。

このアイデアには関心があり、長い間熟成され議論されてきたため、調査を行う必要すらありません。

私たちは、次のようなユーザーカテゴリーに注目しています。

  1. 計算を早くしたい方
  2. 溜め込んでおけば、後ですぐに使えるという人
  3. 自分の(あるいは利用可能な)資源を売ってお金に換え、それを引き出すことを望む人たち(非取引ユーザー)。

そして、1年後には、スケジュール機能を使って未使用時間のリソースを販売 する第3のカテゴリーのユーザーが優勢になる予感がします。

 
Renat:

このアイデアには関心があり、長い間熟成され議論されてきたため、調査を行う必要さえないのです。

以下のカテゴリーのユーザーを対象としています。

  1. 計算を早くしたい方
  2. 使わないときに溜めておいて、後でさっと使えるようにしたい方
  3. 自分の(あるいは利用可能な)資源を売ってお金に換え、それを引き出すことを望む人たち(非取引ユーザー)。

そして、1年後には、スケジュール機能を使って未使用時間のリソースを販売する第3のカテゴリーのユーザーが優勢になる予感がします。

例えば私は、24時間電力を貸し出す準備ができています。6コアのマシンを持っていますが、そのリソースの50%はまだアイドル状態です。
 

値段を決めておいて、何かが変わって変えたら、昔の値段で買った人が悪い、不公平だとみんなが怒る。そういうものです......。未来を見据える

理想は交換で、市場の 常として、平均価格は買い手と売り手の間のレベルで止まり、何もしなくてもいいということです。

 
Renat:

そろそろ、すべてのユーザーが関心を寄せる「資源の売買価格は いくらになるのか」という問題を提起したい。

最も論理的なのは、需給に適応した方式にすることでしょう :) .

以下は、いくつかの結論と提案である。

そのため、批評、ふるい分け、モデレートが必要です。

1.最も論理的なのは、サーバーにPRエージェントを置いて、例えば複数の偽クライアントボットのような関連情報を収集することだと思うのです。クライアントを匿名化すれば、PRで不正をしないことが実質的に保証されるはずです。別の方法として、代理店認証センターを導入する方法もあります。

2.適応性に関して。まさに、供給が需要を上回るべきケースです。当然ながら、適切な比率を得るためには、WMSの適切なモデルをモデル化したり、計算したりする必要があります。

基準は単純で、リクエストがキューに 留まる確率が、与えられた閾値を 超えてはならない、というものである。その閾値は、イマドキ、数%以下であるべきだと思います。

現在のBUYERSとSELLERSの定義は、この定義に当てはまらない。

こんな感じでいいんじゃないでしょうか。

BUYERS -- 現在の時間の平均的な作業量(タスクを完了する前に作業単位で見積もることは考えにくいので、履歴に基づく)

SELLERS -- 現在の供給状況。(または歴史に基づいて)

この形では明らかに粗雑に見えますが、イマドキは理にかなっているのです。

このアプローチに対する結論をもう少し。

-- タスクの処理履歴が必要で、必ずしもトランザクション単位ではなく、ボリューム単位でなければならない。

-- 適応的な計算式を得るには、少なくとも一定期間の見積もり履歴が必要です。

-- レートの変更は混乱を避けるため、1日1回までとする。

すると、おおよそ次のようになる。

Rate[0] = (1 - alpha)*Rate[1] + alpha*(Rate[1]*(1 + sigm(1 - correction*BUYERS/SELLERS)))

где, Rate -- условно -- текущая востребованность сервиса

alpha -- максимальный разовый процент изменения рейта

sigm -- сигмоидная функция с областью значений от -1 до 1

correction -- тот самый коэффициент в СМО, который выравнивает 
перекос в отношении спроса\предложения.
そして、合計金額
TOTALPRICE   = TIME * PR * PRICE * Rate[0]

そうすると、PRは一定の値、つまり単純な平均的な性能になり得る。

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Виды заявок в стакане цен
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Виды заявок в стакане цен
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Виды заявок в стакане цен - Документация по MQL5
 
Renat:


そして、1年後には、スケジュール機能を使って未使用時のリソースを販売する第3のユーザー層が優勢になる予感がします。

論外だ、と言われそうですが

1 投資としてはうまくいかない(貸すためだけにパソコンを購入する)。

2.膨大な事務機群という理論上のクロンダイクはあるが、20〜30台の車を持つ平均的なオフィスマネージャーもセキュリティ上の懸念から購入しないでしょう

セキュリティにこだわる平凡な会社員で、労力に比して収入は微々たるもの。

3 上級者(トレーディングユーザーでない)なら、おそらく行くだろう。

無論

 
TheXpert:


イミフ、価格は変えられない。

まあ、インフレやその他の混乱を考慮すると、2、3年後にしか無理でしょう。

 
Mischek:

イモト 値段は変えられない。

変えないためには、まず知ることが必要です。そして、自ずと安定するのです。
理由: