Discussion publique sur la formule de calcul du coût des ressources du réseau en nuage de MQL5 - page 4
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Nous nous concentrons sur les catégories d'utilisateurs suivantes :
Et l'on a le sentiment que d'ici un an, une troisième catégorie d'utilisateurs s'imposera, qui utilisera la fonction de planification pour vendre des ressources en temps non utilisé.
4. ceux qui sont 3 et 2 jusqu'à ce qu'ils aient besoin du 1 - et en tant que 1 ils l'utiliseront beaucoup moins souvent (les traders qui maîtrisent MQL5 pour eux-mêmes).
% est difficile à exprimer, bien sûr.
//////////////////////////////
doivent être nécessairement présents dans les calculs.
Exemple : je pompe 24 heures sur 24, pourquoi ne pas collecter de l'argent gratuit à l'heure ?
Question : la "lenteur" (par exemple, par le délai (ping)) sera-t-elle en quelque sorte coupée ?
//////////////////////////////
D'autre part, la plupart des utilisateurs n'ont pas la capacité des serveurs des développeurs, qui se taillent la part du lion dans les calculs.
Que restera-t-il pour les vendeurs de leurs noyaux ?
//////////////////////////////
Franchement, je ne vois pas de chiffres adéquats, sur la base de quoi compter.
D'une part, nous devons au moins connaître le coût du cloud et partir de la rentabilité de l'entreprise pour MetaQuotes (le prix le plus bas possible). Supposons que, en tant que vendeur et/ou acheteur potentiel, je sois satisfait avec 1$/jour par noyau. Les promoteurs se contenteront-ils de 10 centimes ?
Du côté de l'utilisateur, en procédant au coût de l'ordinateur... Eh bien, je ne sais pas. Même dans ce fil de discussion, 500 et 2 000 dollars ont été cités. C'est un écart assez large.
Je suppose que nous devons encore commencer par savoir combien l'acheteur est prêt à payer et combien de ces acheteurs seront.
Peut-être prendre généralement le prix moyen de l'Expert Advisor (selon la complexité), les programmeurs travaillant à la demande, peuvent estimer ? et ensuite ajuster les coefficients. Sur la charge totale sur le nuage, en option.
Je propose de chiffrer le coût d'une heure de 100 unités PR dans un tableau, qui sera disponible sur le site web du MQL5. Les acheteurs et les vendeurs de temps CPU par le biais du site Web placent leurs offres pour acheter et vendre une heure de 100 unités PR. Toutes leurs offres sur une certaine période, par exemple sur les 120 derniers jours (presque un trimestre), sont accumulées et le prix d'équilibre PRice120 est calculé. Ce prix d'équilibre sera le prix de l'heure 100 unités PR. Si le prix de l'offre du vendeur est inférieur au prix PRice120, alors son temps de traitement est vendu, s'il est supérieur, il n'est pas vendu. Avec les acheteurs, c'est le contraire qui se produit.
La période de temps pendant laquelle les offres sont accumulées est choisie par chaque acheteur et vendeur individuellement parmi plusieurs options : 30 jours, 60 jours, etc. L'écart de son prix par rapport au prix d'équilibre au moment du déclenchement est également choisi par chaque acheteur et vendeur individuellement.
Trop compliqué à mon avis. Le prix doit être fixé de manière centralisée sur la base de statistiques et d'informations complémentaires. Les statistiques générales ne sont vues que par les développeurs, ce sont eux qui ont les cartes en main.
Et l'ajustement périodique du prix (disons, une fois par trimestre) peut être basé sur l'offre et la demande. Supposons que vous fixiez un prix de 1 cent, et que les personnes disposées à travailler avec le nuage seront beaucoup plus nombreuses que nécessaire - vous devez augmenter le prix pour accroître la volonté de fournir leurs capacités.
Si le prix est trop élevé, les acheteurs partiront (vers des réseaux privés ou ailleurs) et il faudra alors réduire le prix.
La seule question est de savoir sur quel prix se baser.
Vous avez des entreprises clientes qui ont acheté TeamWox. Il est probable que quelqu'un de votre entreprise reste en contact avec eux. Vous devriez peut-être essayer de leur proposer "l'idée d'augmenter le recyclage/chargement de 80-90% de la puissance informatique inactive". Ils ont déjà confiance en votre entreprise et le problème du prix peut être rapidement déterminé - il pourrait être proche du juste et de l'optimal.
Une autre idée est que nous essaierons d'impliquer d'énormes communautés de passionnés qui participent depuis des décennies (presque toujours gratuitement) à divers projets de calcul distribué (SETI@home et autres projets similaires sur la plateforme BOINC).
Nous avons une bonne incitation à payer pour les ressources.
Renat:
Nous ferons tourner plusieurs outils synthétiques sur le serveur MetaQuotes-Demo, où le nombre de vendeurs, d'acheteurs et le prix peuvent être surveillés. La formule de calcul/ajustement du prix sera accessible au public afin que tout soit transparent.
Si nous devons explicitement modifier le prix de base ou ajuster la formule de calcul, nous pouvons le faire dans le cadre d'un débat public.
Une autre idée est que nous essaierons d'impliquer d'énormes communautés de passionnés qui participent (presque toujours gratuitement) à divers projets de calcul distribué(SETI@home et autres projets similaires sur la plateforme BOINC) depuis des décennies.
Question : est-ce que les "lents" (par exemple en fonction de la latence (ping)) seront coupés d'une manière ou d'une autre, ou bien entreront-ils par priorité/performance ?
Ils sont identifiés sur le serveur en nuage et les "performances et le temps" sont ajustés en conséquence. Il s'agit principalement de lutter contre la tricherie.
Que restera-t-il pour les vendeurs de leurs noyaux ?
Nous n'avons pas l'intention de vendre nos ressources ; notre objectif est de construire un énorme réseau de distribution dans le monde entier.
Bien entendu, certaines de nos ressources seront distribuées gratuitement, du moins au stade initial.
Nous ne sommes que les opérateurs d'un réseau distribué, l'objectif est de créer un nuage pour des dizaines et des centaines de milliers d'agents de calcul.
Regardez la liste des serveurs en nuage répartis géographiquement - il y en aura d'autres lorsque la charge augmentera.
Une variante simple de 1 Prix unitaire = Prix de base * Func( Vendeurs, Acheteurs, Temps)
Par conséquent, le prix sera automatiquement ajusté toutes les heures en fonction de l'offre et de la demande.
Et l'on pourrait prendre comme base le coût de base "moyen hospitalier" des services en nuage déjà existants.
Oui, j'y ai pensé aussi. Mais là, le prix comprend l'ordinateur complet avec les disques, la mémoire et le processeur, ainsi que le reste de l'infrastructure de sécurité et de sauvegarde.
C'est un système trop compliqué, car personne n'est prêt à lever le petit doigt (et il y a tout un processus d'enchères manuelles) pour des sommes dérisoires. Le système doit fonctionner en mode quasi-automatique.