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

 
Renat:

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

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

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

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

% затрудняюсь, естественно, озвучить. 

//////////////////////////////

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

обязательно должно присутствовать в расчетах.

Пример: один фиг сутками качаю, чо бы на халяву за почасовую бабки не собирать.

Вопрос: "медленные" (например, по задержкам (пингу)) будут как то отсекаться? или вступать в работу по очередности/производительности?

 //////////////////////////////

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

Что останется продавцам своих ядер?

//////////////////////////////

 Честно сказать, никаких адекватных цифр пока не вижу, исходя из чего считать.

С одной стороны, надо как минимум знать себестоимость облака и отталкиваться от рентабельности предприятия для MetaQuotes (минимально возможный ценник). Допустим, меня как потенциального продавца и/или покупателя устроит 1$ в сутки с ядра. Устроит ли разработчиков 10 центов?

 Со стороны пользователя исходить из стоимости компа... ну хз. Даже в этой ветке озвучены 500 и 2000$. Великоват разброс.

Пожалуй, исходить надо все-таки из того, сколько готов заплатить покупатель и сколько этих покупателей будет.

Может, вообще за старт взять тупо среднюю цену советника (в зависимости от сложности), программисты, работающие на заказ, могут прикинуть? а потом регулировать коэффициентами. От общей нагрузки на облако, как вариант.

 
radioamator:

Предлагаю стоимость часа 100 единиц PR котировать в график, который можно будет посмотреть на сайте MQL5. Покупатели и продавцы процессорного времени через сайт выставляют свои заявки на покупку и продажу часа 100 единиц PR. Все их заявки за какой-то период, например за последние 120 дней (почти квартал), накапливаются и вычисляется равновесная цена PRice120. Эта равновесная цена и будет являться стоимостью часа 100 единиц PR. Если цена заявки продавца процессорного времени ниже цены PRice120, то его процессорное время продаётся, если выше то продажа не осуществляется. С покупателями наоборот.

Период, в течении которого происходит накопление заявок  выбирает каждый покупатель и продавец индивидуально из нескольких вариантов: 30 дней, 60 дней и т.д.. Отклонение его цены от равновесной цены при срабатывании так же выбирает каждый покупатель и продавец.

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

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

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

Вопрос только в том какую цену за основу взять.

 
Mischek:
У Вас есть корпоративные клиенты купившие TeamWox. Наверно кто то из Вашей компании поддерживает с ними отношения. Может стоит попробовать предложить им   "идею повышения утилизации/загрузки все равно простаивающих на 80-90% компьютерных мощностей " . У них уже присутствует доверие к Вашей компании и вопрос цены можно быстро определить.Наверно она получится близкой к справедливой и оптимальной . 

Есть другая идея - мы постараемся привлечь огромные сообщества энтузиастов, которые не один десяток лет участвуют (практически всегда бесплатно) в разнообразных проектах распределенных вычислений (SETI@home и аналогичные на платформе BOINC).

У нас есть хороший стимул - оплата ресурсов.

 

Renat:

Мы заведем несколько синтетических инструментов на сервере MetaQuotes-Demo, где можно будет наблюдать за количеством продавцов, покупателей и ценой. Формула расчета/коррекции цены будет публично доступна, чтобы все было прозрачно.

Если понадобится явным образом изменить базовую цену или скорректировать формулу расчета, то мы это можем сделать с публичным обсуждением.

Хорошая идея. Останется потом только разрешить торговать процессорным временем и все ДЦ умрут от зависти... :)
Renat:

Есть другая идея - мы постараемся привлечь огромные сообщества энтузиастов, которые не один десяток лет участвуют (практически всегда бесплатно) в разнообразных проектах распределенных вычислений (SETI@home и аналогичные на платформе BOINC).

Неужели будем ловить марсиан в графиках? :)
 
Silent:

Вопрос: "медленные" (например, по задержкам (пингу)) будут как то отсекаться? или вступать в работу по очередности/производительности?

Их на облачном сервере определяют и соответствующим образом корректируют "производительность и время". Главным образом это для борьбы с читингом.


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

Что останется продавцам своих ядер?

Мы не планируем продавать свои ресурсы, наша цель - построить огромную распределительную сеть по всему миру.

Конечно же часть своих ресурсов будем раздавать бесплатно как минимум на начальном этапе.

С одной стороны, надо как минимум знать себестоимость облака и отталкиваться от рентабельности предприятия для MetaQuotes (минимально возможный ценник). Допустим, меня как потенциального продавца и/или покупателя устроит 1$ в сутки с ядра. Устроит ли разработчиков 10 центов?

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

Посмотрите на географически распределенный список облачных серверов - при повышении нагрузки их будет больше.

Пожалуй, исходить надо все-таки из того, сколько готов заплатить покупатель и сколько этих покупателей будет.

Простой вариант напрашивается в виде 1 Unit Price =  Base Price * Func( Sellers, Buyers, Time)

В результате цена будет автоматически корректироваться каждый час в зависимости от спроса/предложения.

 
И можно взять за базовую "среднюю по больнице" стоимость уже существующих сервисов облаков.
 
Silent:
И можно взять за базовую "среднюю по больнице" стоимость уже существующих сервисов облаков.
Да, такая мысль тоже была. Но там цена включает в себя целый компьютер с дисками, памятью и CPU и остальной инфраструктурой безопасности и бакапов.
 
Renat:
Спасибо  за разъяснения, так стало понятней.
 
Renat:
Да, такая мысль тоже была. Но там цена включает в себя целый компьютер с дисками, памятью и CPU и остальной инфраструктурой безопасности и бакапов.
По сути - то же, что исходить из стоимости компьютера пользователя...
 
Renat:

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


Я имел ввиду не совсем торговлю. Покупатель процессорного времени хочет купить себе N часов 100 единиц PR. Ему надо каким-то образом это сообщить серверу, что я, Иван_Иванов хочу купить N часов и готов заплатить за это M центов. Покупатель выставляет заявку в личном кабинете на покупку, если его цена выше или равна какой-то цены, базовой, равновесной за 120 дней или ещё какой-то, то покупатель приобретает процессорное время. Смысл в том, что выставляемые через сайт предложения для покупки/продажи процессорного времени являются и командами серверу для покупки/продажи, и статистическими данными для определения цены. А график цены это так, для информативности.
Причина обращения: