Discussão pública da fórmula de cálculo do custo dos recursos na MQL5 Cloud Network - página 5

 
radioamator:
Não me referia realmente ao comércio. Um comprador de tempo de CPU quer comprar ele próprio N horas de 100 unidades PR. Tem de informar de alguma forma o servidor que eu, Ivan_Ivanov quero comprar N horas e estou disposto a pagar M cêntimos por isso. O comprador coloca uma encomenda no meu armário pessoal para comprar, se o seu preço for superior ou igual a algum preço, base, equilíbrio durante 120 dias ou o que quer que seja, então o comprador compra tempo de CPU. A questão é que as ofertas de compra/venda do tempo de processamento colocado através do site são ambos comandos ao servidor para comprar/vender e dados estatísticos para determinar o preço. E a tabela de preços é apenas isso, para informação.

É demasiado complicado - ninguém vai realmente fazer ofertas. A utilização deve ser simples - clique em "iniciar" e já está. E o comprador deve saber que agora o preço médio é X mais menos o delta. Mostraremos o preço médio na janela da lista de agentes.

Temos outro problema - entrada de dinheiro (paypal, webmani e cartões de crédito), onde teremos realmente de fazer transacções manuais.

 

Renat:

Temos outro problema - entrada de dinheiro (paypal, webmani e cartões de crédito), onde de facto tem de fazer transacções manuais.

Transacções manuais ou controlo manual?

Com cartões e paypal ainda compreendo, mas que problemas pode haver com a entrada de WM (em vez de retirada) é um mistério.

Ou é concebido um controlo "humano" de todas as transacções financeiras?

 
joo:
0,01 cêntimos por 100000PR por hora.

Porquê?

Pode dizer-se, grosso modo, assim. O número de participantes registados em http://forum.mql4.com é algo como 50.000. Todos eles têm um computador. Isto significa que em média há 2 núcleos por pessoa, portanto 50'000*2=100'000 núcleos processadores. Além disso, há pelo menos 10 vezes mais utilizadores de MT em todo o mundo. E isto é 100'000*10=1'000'000 núcleos. Além disso, existe uma categoria de utilizadores de MT que têm acesso a redes locais a partir de centenas de computadores, a percentagem destes sortudos é de cerca de 1% de acordo com os meus cálculos:

50'000*10*0.1*100*2+50'000*10*2=11'000'000 ядер.

Para estar disposto a pagar por um tempo de optimização reduzido, precisa de uma velocidade pelo menos 100 vezes superior à de uma optimização de um só núcleo. O número de utilizadores de MT que utilizam optimização em cada momento não é superior a 1%, ou seja, 50'000*10*0,1=50'000. O número de núcleos de nuvens por pessoa:

11'000'000/50'000=220 ядер/чел. Acontece que o número de núcleos disponíveis é mais do que o exigido em 220/100=2,2 vezes. - isso é bom. Esta é a carga máxima na rede, quando todos já conhecem a nuvem e a utilizam activamente, no início haverá muito mais núcleos disponíveis por pessoa, penso que 1000-10000 núcleos/pessoa.

Agora, poder-se-á perguntar: "Quanto pagaria por mais 220 núcleos no seu CPU para optimizar 1 EA? - como descobrir?, pode fazer esta pergunta no perfil do membro de uma forma especial, onde os custos máximos e mínimos possíveis são marcados (para ajustar os limites ao longo do tempo), o preço poderá colocar apenas aqueles que têm agentes registados na rede (tanto vendedores como compradores). Assim, pode exibir uma vez por dia o custo médio por unidade de tempo PR (o valor será muito pequeno, portanto melhor 1000PR por unidade de tempo).


É assim que é.

HH não faz sentido calcular cálculos de nuvens baseados nos custos de depreciação do ferro, uma vez que o custo computacional real do ferro é 1000x mais baixo (isto inclui 90% de tempo ocioso, e como exemplo, hordas de entusiastas da computação científica das nuvens fornecem os seus recursos informáticos "para nada"). É impossível que 50'000 pessoas possam suportar os custos de depreciação de computadores com 11'000'000 núcleos de processador e hardware de rápido envelhecimento.

MQL4: automated trading forum
  • www.mql5.com
MQL4: automated trading forum
 
Renat:
Qual dos preços faz mais sentido do ponto de vista do vendedor e do comprador, do ponto de vista de um compromisso conjunto?
  • 0,5 cêntimos por hora
  • 1,0 cêntimos por hora
  • 1,5 cêntimos por hora
  • 2,0 cêntimos por hora
Por favor, fale mais alto.
Imho, não deve haver preço mais barato do que o custo de alimentação de um PC, 1 PC de consumo dentro de 250W --> 1kW x 4 horas --> 6kW x dia. Custos de electricidade em média 8~10 cêntimos kW
 
Interesting:

Com cartões e paypal ainda compreendo, mas que problemas pode haver com a entrada de WM (em vez de retirada) é um mistério.

O problema é que os utilizadores têm de se forçar a registar uma conta na MQL5.com e depositar dinheiro.

Este é o próprio passo que pode diminuir o número de utilizadores dispostos a utilizar o serviço dezenas de vezes. A psicologia deve ser tida em conta.

Se o consumidor for sobrecarregado com parâmetros desconhecidos para a selecção dos preços, definição dos pedidos, etc., o número de utilizadores será cerca de zero.

O serviço deve ser muito simples e razoável. Esta é a única forma de atrair compradores e vendedores.

 
IgorM:
Imho, não deve haver mais barato do que o custo da energia do PC, 1 PC de consumo está dentro de 250W --> 1kW x 4 horas --> 6kW x dia. O custo da electricidade é, em média, 8~10 cêntimos de kW

Sim, essa não é uma má maneira de calcular o custo.

Acontece que o comprador pagará tanto pelo cálculo na nuvem como paga pela electricidade no seu PC, mas o cálculo será n-preço, onde n-número de agentes na nuvem.

E os vendedores serão capazes de compensar os seus custos de electricidade.

O resultado será o seguinte: os vendedores ganharão (poupança em electricidade, e o dinheiro poupado é lucro), e os compradores beneficiarão na velocidade de liquidação (pagarão o mesmo que pagaram antes pela electricidade).

 

Outra questão com agentes livres, que os proprietários correrão sem estarem ligados a logins.

Tais agentes livres serão automática e aleatoriamente atribuídos a postos de trabalho. Mas estarão disponíveis para os clientes que tenham um saldo positivo na conta MQL5.

Assim, se utilizar uma rede paga, recebe alguns agentes gratuitos como bónus.
 

Renat:

Se sobrecarregar o consumidor com parâmetros desconhecidos para a escolha de preços, definição de ofertas, etc., o número de pessoas que utilizam o serviço será cerca de zero.

O serviço deve ser muito simples e inteligente. Esta é a única forma de atrair compradores e vendedores.

Quanto ao tema da simplicidade, concordo que quanto menos confusão, mais eficiente é.
 
Renat:

Outra questão com agentes livres, que os proprietários lançarão sem estarem vinculados a logins.

Isto é, se eu gerir um agente, ele vai para a rede de nuvens de qualquer maneira? Isto pode ser gerido?
 
joo:

Sim, essa é uma forma muito boa de calcular o custo.

Isso é estranho, pensei que ia dizer isso outra vez ;)

bem, então vou expandir no meu posto anterior:

se 1 PC custa ~$0,6 por dia no consumo de electricidade, deve atribuir correctamente o custo ($0,6) da electricidade durante o dia, porque de 8 a 17 horas os PCs dos utilizadores são desligados por muitos, de 17 a 23 horas a maioria liga-se os PCs, de 24 a 8 da manhã os PCs são desligados novamente. Acontece que o tempo de 0 a 17 horas deve ser o mais pago, e de 17 a 24 horas um pouco mais barato - penso que o custo de vender recursos durante este tempo deve corresponder ao custo de comprar recursos semelhantes. Compreender perfeitamente que mesmo o runet está distribuído por muitos fusos horários, talvez não haja necessidade de dividir em faixas horárias - haverá procura, haverá oferta