Public discussion of the formula for calculating the cost of resources in the MQL5 Cloud Network
To estimate the cost of resources, you could try the idea "I buy a computer for $500 and want to recoup the cost by renting it out at night". To simplify, you can omit the associated costs of electricity, cooling and internet and concentrate on three metrics:
- cost of the computer (e.g. $500)
- Payback period (2 years at 8 hours a night, TIME)
- computer performance (e.g. 100 PR units)
The cost of electricity consumed per hour and Internet traffic should also be added).
Don't you have a rough or very rough estimate of the demand for this service in terms of the number of customer-consumers per unit of time? For example 1,000 original customer-consumers per month have ever used the service?
Maybe it makes sense to conduct a survey during the month among the visitors of the fourth and fifth forums, including non-Russian ones, on the topic "Who in principle is ready to provide a computer for the service for money, but on condition that the amount of payment is not known yet"?
Don't you have a rough or very rough estimate of the demand for this service in terms of the number of customer-consumers per unit of time? For example 1,000 original customer-consumers per month have ever used the service?
Maybe it makes sense to conduct a survey over the course of a month among the visitors of the fourth and fifth forums, including non-Russian, on the topic "Who in principle is ready to provide a computer for the service for money, but provided that the amount of payment is not known yet?
There is interest in the idea, and not even need to conduct a survey, as the idea has long matured and discussed.
We focus on the following categories of users:
- those who need to make calculations as quickly as possible
- those who are willing to accumulate resources when they are not being used, so they can use what they have accumulated quickly later
- those who are willing to sell their (or available) resources for money, and then withdraw them (non-trading users)
And there is a feeling that in a year's time, the third category of users who will use the schedule function to sell resources in unused time will predominate.
There is interest in the idea, and it is not even necessary to conduct a survey, as the idea has been matured and discussed for a long time.
We are targeting the following categories of users:
- those who need to make calculations as quickly as possible
- those who are willing to accumulate resources when they are not in use, so they can use what they have accumulated quickly later
- those who are willing to sell their (or available) resources for money, and then withdraw them (non-trading users)
And there is a feeling that in a year's time, the third category of users who will use the schedule function to sell resources in unused time will predominate.
You set a price and then something changes and you change it and everyone yells at you for being so bad and unfair to those who bought at the old price. that's how it is.... looking at the future.
The ideal would be to have an exchange, and as usual in a market, the average price would stop at the level between buyers and sellers and you wouldn't have to do anything about it.
It's time to raise the question that all users are interested in - how much will resources cost to buy and sell?
The most logical thing for you to do would be to make the formula adaptable to the demand/supply :) .
The following are a few conclusions and suggestions.
I hope you understand that outright bloopers are possible, so critique, sift, moderate.
1. I think the most logical thing is to keep a PR agent on the server, and collect relevant information e.g. several fake client bots. If we anonymize the client, it should practically guarantee no cheating with PR. An alternative way is to introduce an agent attestation centre.
2. Concerning the adaptability. This is exactly the case when supply should exceed demand. Obviously, in order to get the right ratio, you need to model or calculate the appropriate model.
The criterion is simple - the probability of a request staying in the queue should not exceed a given threshold. The threshold, imho, should not be more than a few percent.
Current definitions of BUYERS and SELLERS do not fit this definition.
You could put it like this:
BUYERS -- average amount of work for the current time (based on history, since it is unlikely to estimate the task in units of work before it is completed)
SELLERS -- current supply. (or based on history)
It is clear that in this form it looks crude, but, imho, it makes sense.
Some more conclusions for this approach
-- History of processing of tasks is necessary, not necessarily by transactions, only by volume.
-- If you want to get adaptive recurrent formula and calculations you need quotation history at least for some fixed period.
-- rates should be changed no more than once a day to reduce confusion.
Then we get roughly the following:
Rate[0] = (1 - alpha)*Rate[1] + alpha*(Rate[1]*(1 + sigm(1 - correction*BUYERS/SELLERS))) где, Rate -- условно -- текущая востребованность сервиса alpha -- максимальный разовый процент изменения рейта sigm -- сигмоидная функция с областью значений от -1 до 1 correction -- тот самый коэффициент в СМО, который выравнивает перекос в отношении спроса\предложения.And the total price
TOTALPRICE = TIME * PR * PRICE * Rate[0]Then PR can be a constant value, a simple average performance.
- www.mql5.com
And there is a feeling that in a year the third category of users will prevail, who will use the schedule function to sell resources at unused times.
I'm not arguing, you tell me, but
1 as an investment it will not work (buy a computer just to rent it out).
2. we have a theoretical Klondike in the form of an enormous fleet of office machines, but the average office manager with 20-30 cars would not buy it either, due to security concerns
an average office manager with a security-fixation and negligible income compared to the effort required to generate it
3 an advanced student (non trading users) would probably go for it
all imho of course
Imho, the price cannot be changed.
Well, only in a couple of years, taking into account inflation and other disruptions.
Imho the price cannot be changed.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Every day the MQL5 Cloud Network starts breathing more actively. We are fixing bugs, step by step, bringing the release of the system closer.
For those who are not aware of distributed calculations, here are a couple of screenshots of typical cloud computing agents:
In the client terminal, the network is shown as follows:
For the next couple of months, the MQL5 Cloud Network will be operating in the public test mode to allow developers to find and fix maximum bugs. For now the network is working in the free mode. As soon as we stabilize the work processes in the network and enable full accounting of the consumed resources, we will issue a release.
Everyone is asked to actively connect their agents to the network, so that they can test the cloud under serious load. At the end of the testing, all participants who have provided their agents will be awarded bonuses (which can be withdrawn or spent)!
It's time to bring up a question that all users are interested in - how much will resources cost to buy and sell?
To start the discussion it is suggested to take a few parameters (for each agent individually):
TIME - затраченное время на расчет задачи(пакета задач) в миллисекундах
PR - индекс производительности агента (недостоверная величина, фальсифицируемая)
PRICE - автоматически высчитываемая цена за единицу работы (самое сложное)
PRJOB - единица работы в виде 1 единицы PR за 1 ms времени TIME
вспомогательные величины:
BUYERS - количество покупателей (количество работ в очереди)
SELLERS - количество продавцов (агентов)
For example, the total selling price of resources per agent might look like this:
TOTALPRICE = TIME * PR * PRICE
The formula is very simple and there is no PR normalisation, which can be tampered with by the agent. Let's leave checking, normalization and fighting cheating for later. Also a small commission will be taken from the price in favour of the settlement network organiser to maintain the service.
To estimate the cost of resources, you could try the idea "I buy a computer for $500 and want to recoup the cost by renting it out at night". To simplify, you can omit the associated costs of electricity, cooling, and internet and focus on three metrics:
Let's try to calculate the cost of 1 PR per 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 доллара
To estimate the cost of selling resources for 1 hour of this computer, let's make a simple calculation:
Миллисекунд = 60 минут * 60 секунд * 1000 миллисекунд = 3 600 000 миллисекунд
Стоимость 1 часа при 100 PR = 3 600 000 миллисекунд * 100 PR * 4,8225308641975308641975308641975e-10 доллара = 0,17361111111111111111111111111111 доллара
It turns out that an hour of renting this computer costs 17 cents, and 8 hours of overnight work would cost $1.38.
This is 'not much' on the seller side, but one must also look at the buyer side. At a certain price, there may be no buyers.
In order to find a reasonable price, some mechanism is needed to automatically balance the price per unit of work. And this mechanism must be protected from simple manipulation.
The number of buyers/sellers at the moment or their average daily values and similar values can be used as adjusting factors.
Or maybe even calculate starting price for resource unit, and then once in 1-3 months it is manually corrected with public announcement depending on the activity of the service (buyers and sellers).
So far all the calculations are at the level of proposals. Please give your opinion, correct it or suggest your own version.