Публичное обсуждение формулы расчета стоимости ресурсов в MQL5 Cloud Network

 

С каждым днем MQL5 Cloud Network начинает все активнее дышать. Мы исправляем ошибки, шаг за шагом приближая выпуск системы.

Для тех, кто не в курсе распределенных расчетов, приведу пару скриншотов по типичным агентам облачных вычислений:



В клиентском терминале сеть показывается так:



Следующие пару месяцев MQL5 Cloud Network будет работать в публичном тестовом режиме, чтобы дать возможность разработчикам найти и исправить максимум ошибок. Пока сеть работает в бесплатном режиме. Как только стабилизируем рабочие процессы в сети и включим полный учет потребляемых ресурсов, выпустим релиз.

Просьба ко всем активнее подключаться своими агентами в сеть, чтобы можно было протестировать облако под серьезной нагрузкой. По окончании тестирования всем участникам, предоставившим своих агентов, будут начислены бонусы (их можно будет вывести или потратить)!



Пора поднимать вопрос, который интересует всех пользователей - сколько будут стоить ресурсы при покупке и продаже?

Для начала обсуждения предлагается взять несколько параметров (для каждого агента в отдельности):

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

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

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

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


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

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

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


Например, общая цена продажи ресурсов одного агента может выглядеть так:

TOTALPRICE   = TIME * PR * PRICE


Формула очень простая и в ней не присутствует нормализация показателя PR, который может быть подделан со стороны агента. Проверку, нормализацию и борьбу с читингом оставим на потом. Также от цены в пользу организатора расчетной сети будет взята небольшая комиссия для поддержания сервиса.


Чтобы оценить стоимость ресурсов, можно попробовать использовать такую идею "я покупаю компьютер за 500 долларов и хочу отбить его стоимость, сдавая в аренду по ночам". Для упрощения можно опустить сопутствующие расходы на электричество, охлаждение, интернет и сконцентрироваться на трех показателях:

  1. стоимость компьютера (например, 500 долларов)
  2. срок окупаемости (2 года по 8 часов ночью, TIME)
  3. производительность компьютера (например, 100 единиц PR)

Попробуем посчитать стоимость 1 PR за 1 ms:

Всего часов           = 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 доллара


Получается, что час аренды этого компьютера стоит 17 центов, а 8 часов ночной работы будет стоить 1.38 доллара.

Это "не так много" со стороны продавца, но надо также посмотреть со стороны покупателя. При определенной цене покупателей может и не быть.


Чтобы найти разумную цену, нужен какой-то механизм автоматической балансировки цены за единицу работы. Причем этот механизм должен быть защищен от простых манипуляций.

В качестве корректирующих факторов могут участвовать количество покупателей/продавцов в текущий момент или их среднесуточные значения и аналогичные величины.

А может вообще высчитать стартовую цену единицы ресурсов, а потом раз в 1-3 месяца ее вручную корректировать с публичным оглашением в зависимости от активности сервиса (покупателей и продавцов).


Пока все расчеты на уровне предложений. Просьба всем высказать свое мнение, поправить или предложить свой вариант.

 
Renat:

Чтобы оценить стоимость ресурсов, можно попробовать использовать такую идею "я покупаю компьютер за 500 долларов и хочу отбить его стоимость, сдавая в аренду по ночам". Для упрощения можно опустить сопутствующие расходы на электричество, охлаждение, интернет и сконцентрироваться на трех показателях:

  1. стоимость компьютера (например, 500 долларов)
  2. срок окупаемости (2 года по 8 часов ночью, TIME)
  3. производительность компьютера (например, 100 единиц PR)

сюда же стоит добавить стоимость электорэнергии потребляемой компьютером за час и интернет трафик )
 
sanyooooook:
сюда же стоит добавить стоимость электорэнергии потребляемой компьютером за час и интернет трафик )
Для упрощения можно считать что все это уже входит в желаемую "окупаемую" цену.
 
Renat:


А нет ли у Вас приблизительных или очень приблизительных расчетов востребованности этого сервиса в количестве клиентов-потребителей  за единицу времени ? Например 1 000 оригинальных клиентов- потребителей в месяц хоть раз воспользовались (ются) этим сервисом ?

Может есть смысл провести опрос в течении месяца среди посетителе четвертого и пятого форумов , включая не русскоязычные, на тему -  "Кто принципиально готов предоставлять комп для сервиса за деньги, но  при условии что сумма оплаты пока не известна"   

 
Mischek:

А нет ли у Вас приблизительных или очень приблизительных расчетов востребованности этого сервиса в количестве клиентов-потребителей  за единицу времени ? Например 1 000 оригинальных клиентов- потребителей в месяц хоть раз воспользовались (ются) этим сервисом ?

Может есть смысл провести опрос в течении месяца среди посетителе четвертого и пятого форумов , включая не русскоязычные, на тему -  "Кто принципиально готов предоставлять комп для сервиса за деньги, но  при условии что сумма оплаты пока не известна"   

Интерес к идее есть, причем не обязательно даже опрос проводить, так как идея долго зрела и обсуждалась.

Мы ориентируемся на следующие категории пользователей:

  1. те, кому надо провести расчеты максимально быстро
  2. те, кто готов накапливать ресурсы в неиспользуемое время, чтобы потом иметь возможность быстро воспользоваться накопленным
  3. те, кто готов просто продавать свои (или доступные) ресурсы за деньги, а потом их выводить (пользователи вне трейдинга)

Причем есть ощущение, что через год будет преобладать третья категория пользователей, которые будут пользоваться функцией расписания для продажи ресурсов в неиспользуемое время.

 
Renat:

Интерес к идее есть, причем не обязательно даже опрос проводить, так как идея долго зрела и обсуждалась.

Мы ориентируемся на следующие категории пользователей:

  1. те, кому надо провести расчеты максимально быстро
  2. те, кто готов накапливать ресурсы в неиспользуемое время, чтобы потом иметь возможность быстро воспользоваться накопленным
  3. те, кто готов просто продавать свои (или доступные) ресурсы за деньги, а потом их выводить (пользователи вне трейдинга)

Причем есть ощущение, что через год будет преобладать третья категория пользователей, которые будут пользоваться функцией расписания для продажи ресурсов в неиспользуемое время.

Я например готов сдавать в аренду свои мощности 24 часа в сутки, у меня шестиядерная машина и 50% ее ресурсов пока простаивает.
 

назначите цену, а потом что то поменяется и измените её, и все будут орать на вас что вы такие разплохие и нечестно получиться к тем кто купил по старой цене. это так.... взгляд в будущее.

идеально было бы сделать биржу, и как обычно в рыночных условиях средняя цена бы остановилась на отметки между покупателями и продавцами, и ничего не надо мудрить.

 
Renat:

Пора поднимать вопрос, который интересует всех пользователей - сколько будут стоить ресурсы при покупке и продаже?

Самым логичным для Вас будет сделать формулу адаптивной под спрос\предложение :) .

Далее несколько выводов и предложений.

Надеюсь, понимаете, что возможны откровенные ляпы, так что критикуйте, отсеивайте, модерируйте.

1. Самым логичным считаю PR агента держать на сервере, а собирать актуальную информацию  например могут несколько фейковых ботов-клиентов. Если обезличить клиента, это должно практически гарантировать отсутствие читинга с PR. Альтернативный способ -- ввести центр аттестации агента.

2. По поводу адаптивности. Это как раз тот случай, когда предложение должно превышать спрос. Очевидно, что для получения правильного соотношения, необходимо смоделировать или рассчитать соответствующую модель СМО.

Критерий простой -- вероятность пребывания заявки в очереди не должна превышать заданного порога. Порог, имхо, должен быть не больше нескольких процентов.

Под такую постановку не подходят текущие определения BUYERS и SELLERS.

Можно так:

BUYERS -- средний объем работы для текущего времени (на основе истории, т.к. вряд ли можно оценить задачу в единицах работы до ее выполнения)

SELLERS -- текущее предложение. (или по истории)

Понятно, что в таком виде это выглядит сыровато, но, имхо, здраво.

Еще несколько выводов для такого подхода

-- необходима история выполнения работ, необязательно по транзакциям, можно только объем

-- необходима история расценок (для получения адаптивной рекуррентной формулы и расчетов) хотя бы на некоторый фиксированный период.

-- для уменьшения непоняток расценки нужно менять не чаще раза в день.

Тогда получим примерно следующее:

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  как инвестиция это однозначно не пойдет ( купить комп чтобы только сдавать)

2  есть теоретический клондайк в виде огромаднейшего парка офисных машин , но средний руководитель среднего офиса из 20-30 машин на это тоже не пойдет и  из соображений бзикнутости на безопасности 

    и из соображений ничтожности дохода в сравнении с телодвижениями для его получения

3   абстрактный продвинутый студент (пользователи вне трейдинга) наверно пойдет

всё имхо конечно  

 
TheXpert:


Имхо цену менять нельзя . 

Ну если только через пару лет с учетом инфляции и иных катаклизмов 

 
Mischek:

Имхо цену менять нельзя . 

Для того, чтобы ее не менять ее узнать вначале надо бы. А там смотришь сама застабилизируется.
Причина обращения: