Discusión pública de la fórmula de cálculo del coste de los recursos en la Red de Nube MQL5 - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
No me refería realmente al comercio. Un comprador de tiempo de CPU quiere comprarse N horas de 100 unidades de PR. Tiene que informar de alguna manera al servidor de que yo, Ivan_Ivanov quiero comprar N horas y estoy dispuesto a pagar M céntimos por ello. El comprador pone una orden en mi gabinete personal para comprar, si su precio es mayor o igual a algún precio, base, de equilibrio durante 120 días o lo que sea, entonces el comprador compra tiempo de CPU. La cuestión es que las ofertas de compra/venta de tiempo de procesador puestas a través del sitio son tanto órdenes al servidor para comprar/vender como datos estadísticos para determinar el precio. Y el gráfico de precios es sólo eso, a título informativo.
Es demasiado complicado: nadie va a hacer ofertas. El uso debería ser sencillo: haz clic en "empezar" y ya está. Y el comprador debe saber que ahora el precio medio es X más menos el delta. Mostraremos el precio medio en la ventana de la lista de agentes.
Tenemos otro problema: la entrada de dinero (paypal, webmani y tarjetas de crédito), en la que tendremos que hacer transacciones manuales.
Renat:
Tenemos otro problema: la entrada de dinero (paypal, webmani y tarjetas de crédito), en la que hay que hacer transacciones manuales.
¿Transacciones manuales o control manual?
Con las tarjetas y paypal aún lo entiendo, pero qué problemas puede haber con la entrada de WM (en lugar de la retirada) es un misterio.
¿O se concibe el control "humano" de todas las transacciones financieras?
0,01 céntimos por 100000PR por hora.
¿Por qué?
A grandes rasgos, se puede decir lo siguiente. El número de participantes inscritos en http://forum.mql4.com es de unos 50.000. Todos tienen un ordenador. Esto significa que hay una media de 2 núcleos por persona, por lo que 50'000*2=100'000 núcleos de procesamiento. Además, hay al menos 10 veces más usuarios de MT en todo el mundo. Y esto es 100'000*10=1'000'000 de núcleos. Además, hay una categoría de usuarios de MT que tienen acceso a las redes locales desde cientos de ordenadores, el porcentaje de estos afortunados es de alrededor del 1% según mis estimaciones:
50'000*10*0.1*100*2+50'000*10*2=11'000'000 ядер.
Para estar dispuesto a pagar por la reducción del tiempo de optimización, se necesita una velocidad al menos 100 veces superior a la de una optimización de un solo núcleo. El número de usuarios de MT que utilizan la optimización en cada momento no es superior al 1%, es decir, 50'000*10*0,1=50'000. El número de núcleos de la nube por persona:
11'000'000/50'000=220 ядер/чел. Resulta que el número de núcleos disponibles es superior al necesario en 220/100=2,2 veces. -Eso es bueno. Este es el pico de carga en la red, cuando todo el mundo ya conoce la nube y la utiliza activamente, al principio habrá muchos más núcleos disponibles por persona, creo que 1000-10000 núcleos/persona.
Ahora bien, cabe preguntarse: "¿Cuánto pagarías por 220 núcleos más en tu CPU para optimizar 1 EA?". - ¿cómo averiguarlo?, puedes hacer esta pregunta en el perfil del miembro en un formulario especial, donde se marcan los costes máximos y mínimos posibles (para ajustar los límites en el tiempo), el precio lo podrán poner sólo aquellos que tengan agentes registrados en la red (tanto vendedores como compradores). Así, puede mostrar una vez al día el coste medio por unidad de tiempo de RP (la cifra será muy pequeña, así que mejor 1000PR por unidad de tiempo).
Así es.
HH no tiene sentido calcular los cálculos en la nube basándose en los costes de depreciación del hierro, ya que el coste computacional real del hierro es 1000 veces menor (esto incluye el 90% del tiempo de inactividad, y como ejemplo las hordas de entusiastas de la computación científica en la nube que proporcionan sus recursos informáticos "a cambio de nada"). Esimposible que 50.000 personas puedan permitirse los costes de amortización de ordenadores con 11.000.000 de núcleos de procesador y un hardware que envejece rápidamente.
¿Cuál de los precios tiene más sentido desde el punto de vista del compromiso conjunto de vendedor y comprador?
- 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, habla.Con las tarjetas y paypal aún lo entiendo, pero qué problemas puede haber con la entrada de WM (en lugar de la retirada) es un misterio.
El problema es que los usuarios tienen que obligarse a registrar una cuenta en MQL5.com y depositar dinero.
Este es el paso que puede disminuir el número de usuarios dispuestos a utilizar el servicio docenas de veces. Hay que tener en cuenta la psicología.
Si se carga al consumidor con parámetros desconocidos para la selección de precios, la fijación de solicitudes, etc., el número de usuarios será aproximadamente cero.
El servicio debe ser muy sencillo y razonable. Sólo así podrá atraer a compradores y vendedores.
Imho, no debería ser más barato que el costo de la energía de la PC, el consumo de 1 PC está dentro de 250W --> 1kW x 4 horas --> 6kW x día. El coste de la electricidad es de una media de 8~10 céntimos de kW
Sí, no es una mala manera de calcular el coste.
Resulta que el comprador pagará por el cálculo en la nube lo mismo que paga por la electricidad en su PC, pero el cálculo será n veces más rápido, siendo n el número de agentes en la nube.
Y los vendedores podrán compensar sus costes de electricidad.
El resultado será el siguiente: los vendedores ganarán (ahorro de electricidad, y el dinero ahorrado es beneficio), y los compradores se beneficiarán en la rapidez de la liquidación (pagarán lo mismo que antes por la electricidad).
Otra cuestión es la de los agentes libres, que los propietarios ejecutarán sin estar atados a los registros.
Dichos agentes libres serán asignados a los puestos de trabajo de forma automática y aleatoria. Pero estarán disponibles para los clientes que tengan un saldo positivo en la cuenta MQL5.
Por lo tanto, si utilizas una red de pago, obtienes algunos agentes gratuitos como bonificación.Renat:
Si se carga al consumidor con parámetros desconocidos para elegir los precios, fijar las ofertas, etc., el número de personas que utilizan el servicio será aproximadamente cero.
El servicio debe ser muy sencillo e inteligente. Esta es la única manera de atraer a los compradores y vendedores.
Otra cuestión es la de los agentes libres, que los propietarios lanzarán sin estar atados a los inicios de sesión.
Sí, es una muy buena forma de calcular el coste.
Qué raro, pensé que iba a decir eso de nuevo ;)
Bueno, entonces voy a ampliar mi post anterior:
si 1 PC cuesta ~0,6 dólares al día en consumo de electricidad, debería asignar el coste (0,6 dólares) de la electricidad correctamente durante el día, porque de 8 a 17 horas los PC de los usuarios se apagan por muchos, de 17 a 23 horas la mayoría enciende los PC, de 24 a 8 de la mañana los PC se vuelven a apagar. Resulta que el tiempo de 0 a 17 horas debería ser el más pagado, y de 17 a 24 horas un poco más barato - creo que el coste de vender recursos durante este tiempo debería coincidir con el coste de comprar recursos similares. Entendiendo perfectamente que incluso la runeta se distribuye en muchos husos horarios, quizás no sea necesario dividir en franjas horarias: habrá demanda, habrá oferta