Discussão pública da fórmula de cálculo do custo dos recursos na MQL5 Cloud Network - página 4
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Concentramo-nos nas seguintes categorias de utilizadores:
E há a sensação de que dentro de um ano, uma terceira categoria de utilizadores irá prevalecer, que irão utilizar a função de programação para vender recursos em tempo não utilizado.
4. aqueles que são 3 e 2 até precisarem de 1 - e como 1 irão utilizá-lo muito menos frequentemente (comerciantes que dominam MQL5 para si próprios).
% é difícil de exprimir, claro.
//////////////////////////////
deve estar necessariamente presente nos cálculos.
Exemplo: estou a bombear 24 horas por dia, porque não recolho dinheiro grátis à hora?
Pergunta: será "lento" (por exemplo, por atraso (ping)) de alguma forma cortado?
//////////////////////////////
Por outro lado, a maioria dos utilizadores não tem a capacidade dos servidores de desenvolvimento, que serão a parte de leão dos cálculos em primeiro lugar.
O que será deixado para os vendedores dos seus núcleos?
//////////////////////////////
Francamente falando, não vejo quaisquer números adequados, com base no que contar.
Por um lado, devemos pelo menos conhecer o custo da nuvem e partir da rentabilidade da empresa para a MetaQuotes (a etiqueta de preço mais baixo possível). Suponhamos que eu, como potencial vendedor e/ou comprador, ficaria satisfeito com 1$/dia por núcleo. Será que os criadores ficarão satisfeitos com 10 cêntimos?
Do lado do utilizador, a partir do custo do computador. bem, não sei. Mesmo nesta linha, foram cotados $500 e $2.000. Esta é uma grande amplitude.
Acho que ainda precisamos de começar com o quanto o comprador está disposto a pagar e quantos desses compradores serão.
Talvez, em geral, tomar o preço médio do Expert Advisor (dependendo da complexidade), os programadores que trabalham a pedido, podem estimar? e depois ajustar os coeficientes. Sobre a carga total na nuvem, como opção.
Proponho citar o custo de uma hora de 100 unidades PR num gráfico, que estará disponível no website da MQL5. Compradores e vendedores de tempo de CPU através do website colocam as suas ofertas para comprar e vender uma hora de 100 unidades PR. Todas as suas ofertas durante algum período, por exemplo nos últimos 120 dias (quase um trimestre), são acumuladas e o preço de equilíbrio PRice120 é calculado. Este preço de equilíbrio será o preço da hora 100 unidades de PR. Se o preço da oferta do vendedor for inferior ao preço do PRice120, então o seu tempo de processamento é vendido, se superior, ele não é vendido. Com os compradores é o contrário que acontece.
O período de tempo durante o qual as ofertas são acumuladas é escolhido por cada comprador e vendedor individualmente entre várias opções: 30 dias, 60 dias, etc. O desvio do seu preço em relação ao preço de equilíbrio no acionamento é também escolhido por cada comprador e vendedor individualmente.
Demasiado complicado, na minha opinião. O preço deve ser fixado de forma centralizada com base em estatísticas e informações adicionais. As estatísticas gerais são vistas apenas pelos criadores, são eles que detêm os cartões.
E ajustar periodicamente o preço (digamos, uma vez por trimestre) pode ser baseado na oferta e na procura. Suponha que estabelece um preço de 1 cêntimo, mas querer trabalhar com a nuvem será muito mais do que o necessário - terá de aumentar o preço para aumentar a vontade de fornecer as suas capacidades.
Se o preço for demasiado elevado, os compradores sairão (para redes privadas ou outros locais) e então o preço terá de ser reduzido.
A única questão é qual o preço em que se deve basear.
Tem clientes empresariais que compraram a TeamWox. Provavelmente alguém da sua empresa mantém-se em contacto com eles. Talvez devesse tentar oferecer-lhes "a ideia de aumentar a reciclagem/carga de 80-90% da energia ociosa do computador". Eles já têm confiança na sua empresa e a questão do preço pode ser rapidamente determinada - pode estar perto de ser justa e óptima.
Outra ideia é que vamos tentar envolver enormes comunidades de entusiastas que estão envolvidos há décadas (quase sempre gratuitamente) em vários projectos de computação distribuída (SETI@home e semelhantes na plataforma BOINC).
Temos um bom incentivo para pagar pelos recursos.
Renat:
Executaremos várias ferramentas sintéticas no servidor MetaQuotes-Demo, onde o número de vendedores, compradores e preço pode ser monitorizado. A fórmula para calcular/ajustar o preço estará publicamente disponível para que tudo seja transparente.
Se precisarmos de alterar explicitamente o preço base ou ajustar a fórmula de cálculo, podemos fazê-lo com uma discussão pública.
Outra ideia é que vamos tentar envolver enormes comunidades de entusiastas que têm participado (quase sempre gratuitamente) em vários projectos de computação distribuída(SETI@home e semelhantes na plataforma BOINC) durante décadas.
Pergunta: os "lentos" (por exemplo, por latência (ping)) serão de alguma forma cortados, ou serão colocados em fila/performance baseados?
São identificados no servidor da nuvem e o "desempenho e tempo" são ajustados em conformidade. Principalmente para combater a batota.
O que será deixado para os vendedores dos seus núcleos?
Não planeamos vender os nossos recursos; o nosso objectivo é construir uma enorme rede de distribuição em todo o mundo.
É claro que alguns dos nossos recursos serão distribuídos gratuitamente, pelo menos na fase inicial.
Somos apenas operadores de uma rede distribuída, o objectivo é criar uma nuvem para dezenas e centenas de milhares de agentes de cálculo.
Veja-se a lista geograficamente distribuída de servidores de nuvens - haverá mais quando a carga aumentar.
Uma variante simples de 1 Preço Unitário = Preço Base * Func( Vendedores, Compradores, Tempo)
Como resultado, o preço será automaticamente ajustado a cada hora dependendo da oferta/demanda.
E poder-se-ia tomar como base o custo básico "médio hospitalar" dos serviços de nuvem já existentes.
Sim, isso também foi um pensamento. Mas aí o preço inclui todo o computador com discos, memória e CPU e o resto da infra-estrutura de segurança e backup.
É um esquema demasiado complicado, pois ninguém está sequer disposto a levantar um dedo (e há todo um processo de licitação manual) para somas insignificantes. O sistema tem de funcionar em modo quase automático.