Discussão pública da fórmula de cálculo do custo dos recursos na MQL5 Cloud Network
Para estimar o custo dos recursos, poderia experimentar a ideia "Eu compro um computador por $500 e quero recuperar o custo alugando-o à noite". Para simplificar, pode omitir os custos associados de electricidade, refrigeração e Internet e concentrar-se em três métricas:
- custo do computador (por exemplo $500)
- Período de retorno (2 anos a 8 horas por noite, HORÁRIO)
- desempenho do computador (por exemplo, 100 unidades PR)
O custo da electricidade consumida por hora e do tráfego na Internet também deve ser acrescentado).
Não tem uma estimativa aproximada ou muito aproximada da procura deste serviço em termos do número de clientes-consumidores por unidade de tempo? Por exemplo, 1.000 clientes-consumidores originais por mês alguma vez utilizaram o serviço?
Talvez faça sentido realizar um inquérito durante o mês entre os visitantes do quarto e quinto fóruns, incluindo fóruns não russos, sobre o tema - "Quem, em princípio, está disposto a fornecer um computador para o serviço por dinheiro, mas na condição de o montante do pagamento ainda não ser conhecido"?
Não tem uma estimativa aproximada ou muito aproximada da procura deste serviço em termos do número de clientes-consumidores por unidade de tempo? Por exemplo, 1.000 clientes-consumidores originais por mês alguma vez utilizaram o serviço?
Talvez faça sentido realizar um inquérito ao longo de um mês entre os visitantes do quarto e quinto fóruns, incluindo os não-russos, sobre o tema "Quem, em princípio, está disposto a fornecer um computador para o serviço por dinheiro, mas desde que o montante do pagamento ainda não seja conhecido?
Há interesse na ideia, e nem sequer necessidade de realizar um inquérito, uma vez que a ideia amadureceu e foi discutida durante muito tempo.
Concentramo-nos nas seguintes categorias de utilizadores:
- aqueles que precisam de fazer cálculos o mais rapidamente possível
- aqueles que estão dispostos a acumular recursos quando não estão a ser utilizados, para que possam utilizar o que acumularam rapidamente mais tarde
- aqueles que estão dispostos a vender os seus recursos (ou disponíveis) por dinheiro, e depois retirá-los (utilizadores não negociantes)
E há a sensação de que dentro de um ano, a terceira categoria de utilizadores que irão utilizar a função de programação para vender recursos em tempo não utilizado irá predominar.
Há interesse na ideia, e nem sequer é necessário realizar um inquérito, uma vez que a ideia foi amadurecida e discutida durante muito tempo.
Estamos a visar as seguintes categorias de utilizadores:
- aqueles que precisam de fazer cálculos o mais rapidamente possível
- aqueles que estão dispostos a acumular recursos quando não estão a ser utilizados, para que possam utilizar o que acumularam rapidamente mais tarde
- aqueles que estão dispostos a vender os seus recursos (ou disponíveis) por dinheiro, e depois retirá-los (utilizadores não negociantes)
E há a sensação de que dentro de um ano, a terceira categoria de utilizadores que irão utilizar a função de programação para vender recursos em tempo não utilizado irá predominar.
Estabelece-se um preço e depois algo muda e muda-se e todos gritam connosco por sermos tão maus e injustos para com aqueles que compraram pelo preço antigo. é assim que é.... olhando para o futuro.
O ideal seria ter uma troca, e como de costume num mercado, o preço médio pararia no nível entre compradores e vendedores e não teria de fazer nada a esse respeito.
É altura de levantar a questão que interessa a todos os utilizadores - quanto custarão os recursos para comprar e vender?
A coisa mais lógica a fazer seria tornar a fórmula adaptável à procura/fornecimento :) .
Apresentam-se a seguir algumas conclusões e sugestões.
Espero que compreendam que é possível um desabrochar total, por isso, critiquem, peneirem, moderem.
1. Penso que o mais lógico é manter um agente de relações públicas no servidor, e recolher informação relevante, por exemplo, vários bots falsos de clientes. Se anonimizarmos o cliente, deverá praticamente garantir que não se faz batota com RP. Uma forma alternativa é introduzir um centro de atestação de agentes.
2. No que diz respeito à adaptabilidade. Este é exactamente o caso em que a oferta deve exceder a procura. Obviamente, para obter a relação certa, é necessário modelar ou calcular o modelo apropriado de WMS.
O critério é simples - a probabilidade de um pedido permanecer na fila não deve exceder um determinado limiar. O limiar, imho, não deve ser superior a alguns por cento.
As definições actuais de COMPRADORES e VENDEDORES não se enquadram nesta definição.
Poderia fazê-lo desta forma:
COMPRADORES -- quantidade média de trabalho para o tempo actual (com base no histórico, uma vez que é pouco provável que se estime a tarefa em unidades de trabalho antes da sua conclusão)
VENDEDORES -- fornecimento actual. (ou com base na história)
É evidente que nesta forma parece grosseira, mas, imho, faz sentido.
Mais algumas conclusões para esta abordagem
-- O histórico de processamento de tarefas é necessário, não necessariamente por transacções, apenas por volume.
-- Se quiser obter fórmulas e cálculos recorrentes adaptativos, precisa de um histórico de cotações pelo menos durante algum período fixo.
-- as tarifas não devem ser alteradas mais do que uma vez por dia para reduzir a confusão.
Depois, obtemos aproximadamente o seguinte:
Rate[0] = (1 - alpha)*Rate[1] + alpha*(Rate[1]*(1 + sigm(1 - correction*BUYERS/SELLERS))) где, Rate -- условно -- текущая востребованность сервиса alpha -- максимальный разовый процент изменения рейта sigm -- сигмоидная функция с областью значений от -1 до 1 correction -- тот самый коэффициент в СМО, который выравнивает перекос в отношении спроса\предложения.E o preço total
TOTALPRICE = TIME * PR * PRICE * Rate[0]Então o PR pode ser um valor constante, um simples desempenho médio.
- www.mql5.com
E há a sensação de que dentro de um ano prevalecerá a terceira categoria de utilizadores, que utilizarão a função de programação para vender recursos em horários não utilizados.
Não estou a discutir, diz-me o senhor, mas
1 como um investimento não funcionará (comprar um computador apenas para o alugar).
2. temos um Klondike teórico sob a forma de uma enorme frota de máquinas de escritório, mas o gerente de escritório médio com 20-30 carros também não o compraria, devido a preocupações de segurança
um gestor de escritório médio com uma tributação da segurança e um rendimento insignificante em comparação com o esforço necessário para a gerar
3 um estudante avançado (não utilizadores comerciais) provavelmente optaria por ele
todos imho, é claro
Imho, o preço não pode ser alterado.
Bem, apenas dentro de alguns anos, tendo em conta a inflação e outras perturbações.
Imho o preço não pode ser alterado.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Todos os dias a MQL5 Cloud Network começa a respirar mais activamente. Estamos a corrigir os bugs, passo a passo, aproximando a libertação do sistema.
Para aqueles que não estão conscientes dos cálculos distribuídos, aqui estão algumas imagens de ecrãs de agentes típicos de computação em nuvem:
No terminal do cliente, a rede é mostrada da seguinte forma:
Durante os próximos meses, a MQL5 Cloud Network estará a funcionar no modo de teste público para permitir aos programadores encontrar e corrigir o máximo de bugs. Por agora, a rede está a funcionar no modo livre. Assim que estabilizarmos os processos de trabalho na rede e permitirmos a contabilização completa dos recursos consumidos, faremos a libertação.
Pede-se a todos que liguem activamente os seus agentes à rede, para que possam testar a nuvem sob carga séria. No final dos testes, todos os participantes que tenham fornecido os seus agentes receberão bónus (que podem ser retirados ou gastos)!
É tempo de levantar uma questão que interessa a todos os utilizadores - quanto custarão os recursos para comprar e vender?
Para iniciar a discussão sugere-se que se tomem alguns parâmetros (para cada agente individualmente):
TIME - затраченное время на расчет задачи(пакета задач) в миллисекундах
PR - индекс производительности агента (недостоверная величина, фальсифицируемая)
PRICE - автоматически высчитываемая цена за единицу работы (самое сложное)
PRJOB - единица работы в виде 1 единицы PR за 1 ms времени TIME
вспомогательные величины:
BUYERS - количество покупателей (количество работ в очереди)
SELLERS - количество продавцов (агентов)
Por exemplo, o preço total de venda dos recursos por agente pode parecer-se com este:
TOTALPRICE = TIME * PR * PRICE
A fórmula é muito simples e não há normalização de RP, que pode ser adulterada pelo agente. Vamos deixar a verificação, a normalização e a luta contra a batota para mais tarde. Também será retirada uma pequena comissão do preço a favor do organizador da rede de colonização para manter o serviço.
Para estimar o custo dos recursos, poderia experimentar a ideia "Eu compro um computador por $500 e quero recuperar o custo alugando-o à noite". Para simplificar, pode omitir os custos associados de electricidade, refrigeração e Internet e concentrar-se em três métricas:
Vamos tentar calcular o custo de 1 PR por 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 доллара
Para estimar o custo de venda de recursos durante 1 hora deste computador, vamos fazer um cálculo simples:
Миллисекунд = 60 минут * 60 секунд * 1000 миллисекунд = 3 600 000 миллисекунд
Стоимость 1 часа при 100 PR = 3 600 000 миллисекунд * 100 PR * 4,8225308641975308641975308641975e-10 доллара = 0,17361111111111111111111111111111 доллара
Acontece que uma hora de aluguer deste computador custa 17 cêntimos, e 8 horas de trabalho nocturno custariam 1,38 dólares.
Isto "não é muito" do lado do vendedor, mas também se deve olhar para o lado do comprador. A um determinado preço, pode não haver compradores.
A fim de encontrar um preço razoável, é necessário algum mecanismo para equilibrar automaticamente o preço por unidade de trabalho. E este mecanismo deve ser protegido de simples manipulação.
O número de compradores/vendedores no momento ou os seus valores médios diários e valores semelhantes podem ser utilizados como factores de ajustamento.
Ou talvez até calcular o preço inicial da unidade de recurso, e depois uma vez em 1-3 meses é corrigido manualmente com anúncio público dependendo da actividade do serviço (compradores e vendedores).
Até agora, todos os cálculos estão ao nível das propostas. Por favor, dê a sua opinião, corrija-a ou sugira a sua própria versão.