Discussion publique sur la formule de calcul du coût des ressources du réseau en nuage de MQL5 - page 5
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
Je ne voulais pas vraiment parler de commerce. Un acheteur de temps CPU veut s'acheter N heures de 100 unités PR. Il doit d'une manière ou d'une autre informer le serveur que moi, Ivan_Ivanov, je veux acheter N heures et suis prêt à payer M cents pour cela. L'acheteur passe un ordre d'achat dans mon cabinet personnel, si son prix est supérieur ou égal à un certain prix, de base, d'équilibre pour 120 jours ou autre, alors l'acheteur achète le temps du processeur. Le fait est que les offres d'achat/vente de temps processeur proposées par le site sont à la fois des commandes au serveur pour acheter/vendre et des données statistiques pour déterminer le prix. Et le tableau des prix n'est que cela, à titre d'information.
C'est trop compliqué - personne ne fera d'offres. L'utilisation devrait être simple - cliquez sur "démarrer" et vous avez terminé. Et l'acheteur doit savoir que maintenant le prix moyen est X plus moins le delta. Nous afficherons le prix moyen dans la fenêtre de la liste des agents.
Nous avons un autre problème - l'entrée d'argent (paypal, webmani et cartes de crédit), où nous devrons effectivement effectuer des transactions manuelles.
Renat:
Nous avons un autre problème - l'entrée d'argent (paypal, webmani et cartes de crédit), où vous devez réellement effectuer des transactions manuelles.
Transactions manuelles ou contrôle manuel ?
Avec les cartes et le système Paypal, je comprends toujours, mais les problèmes qu'il pourrait y avoir avec les entrées (plutôt que les retraits) de WM sont un mystère.
Ou bien le contrôle "humain" de toutes les transactions financières est-il conçu ?
0,01 centime par 100000PR par heure.
Pourquoi ça ?
On peut dire ça comme ça. Le nombre de participants inscrits sur http://forum.mql4.com est de l'ordre de 50 000. Ils ont tous un ordinateur. Cela signifie qu'il y a en moyenne 2 cœurs par personne, donc 50'000*2=100'000 cœurs de processeur. En outre, il y a au moins 10 fois plus d'utilisateurs de MT dans le monde. Et cela représente 100'000*10=1'000'000 de noyaux. En outre, il existe une catégorie d'utilisateurs de MT qui ont accès aux réseaux locaux à partir de centaines d'ordinateurs, le pourcentage de ces personnes chanceuses selon mes calculs est d'environ 1% :
50'000*10*0.1*100*2+50'000*10*2=11'000'000 ядер.
Pour être prêt à payer pour un temps d'optimisation réduit, il faut une vitesse au moins 100 fois supérieure à celle d'une optimisation sur un seul cœur. Le nombre d'utilisateurs de la TA qui utilisent l'optimisation à chaque instant n'est pas supérieur à 1%, soit 50'000*10*0.1=50'000. Le nombre de cœurs de nuage par personne :
11'000'000/50'000=220 ядер/чел. Il s'avère que le nombre de cœurs disponibles est supérieur au nombre requis de 220/100=2,2 fois. -C'est bien. Il s'agit de la charge maximale sur le réseau, lorsque tout le monde connaît déjà le nuage et l'utilise activement. Au début, il y aura beaucoup plus de cœurs disponibles par personne, je pense à 1000-10000 cœurs/personne.
On pourrait se demander combien on paierait pour avoir 220 cœurs supplémentaires sur son CPU afin d'optimiser une seule EA. - comment le savoir ?, vous pouvez poser cette question dans le profil du membre dans un formulaire spécial, où les coûts max et min possibles sont marqués (pour ajuster les limites au fil du temps), le prix ne pourra être mis en place que ceux qui ont des agents enregistrés dans le réseau (à la fois les vendeurs et les acheteurs). Ainsi, vous pouvez afficher une fois par jour le coût moyen par unité de temps PR (le chiffre va devenir très petit, donc mieux vaut 1000PR par unité de temps).
C'est comme ça.
HH il n'y a aucun intérêt à calculer les calculs en nuage sur la base des coûts d'amortissement du fer, puisque le coût réel de calcul du fer est 1000x inférieur (cela inclut 90% de temps d'inactivité, et à titre d'exemple les hordes d'enthousiastes du calcul scientifique en nuage fournissant leurs ressources informatiques "pour rien"). Il estimpossible que 50 000 personnes puissent se permettre les coûts d'amortissement d'ordinateurs dotés de 11 000 000 de cœurs de processeurs et d'un matériel vieillissant rapidement.
Lequel de ces prix est le plus logique du point de vue du compromis entre le vendeur et l'acheteur ?
- 0,5 centime par heure
- 1,0 centime par heure
- 1,5 cents par heure
- 2,0 cents par heure
Veuillez vous exprimer.Avec les cartes et Paypal, je comprends toujours, mais les problèmes qu'il pourrait y avoir avec l'entrée WM (plutôt qu'avec le retrait) sont un mystère.
Le problème est que les utilisateurs doivent se forcer à ouvrir un compte sur MQL5.com et à déposer de l'argent.
C'est cette étape même qui peut diminuer le nombre d'utilisateurs prêts à utiliser le service des dizaines de fois. La psychologie doit être prise en compte.
Si le consommateur est accablé par des paramètres inconnus pour la sélection des prix, la fixation des demandes, etc., le nombre d'utilisateurs sera à peu près nul.
Le service doit être très simple et raisonnable. C'est la seule façon d'attirer les acheteurs et les vendeurs.
Je pense qu'il ne devrait pas y avoir de prix plus bas que le coût de l'alimentation des PC, la consommation d'un PC étant de 250W --> 1kW x 4 heures --> 6kW x jour. Le coût de l'électricité est en moyenne de 8 à 10 cents par kW.
Oui, ce n'est pas une mauvaise façon de calculer le coût.
Il s'avère que l'acheteur paiera autant pour le calcul dans le nuage que pour l'électricité sur son PC, mais le calcul sera n fois plus rapide, où n-nombre d'agents dans le nuage.
Et les vendeurs pourront compenser leurs coûts d'électricité.
Le résultat sera le suivant : les vendeurs gagneront (économies sur l'électricité, et l'argent économisé est un bénéfice), et les acheteurs bénéficieront de la rapidité du règlement (ils paieront le même prix qu'avant pour l'électricité).
Un autre problème concerne les agents libres, que les propriétaires feront fonctionner sans être liés à des logins.
Ces agents libres seront automatiquement et aléatoirement affectés à des emplois. Mais ils seront disponibles pour les clients qui ont un solde positif sur leur compte MQL5.
Ainsi, si vous utilisez un réseau payant, vous obtenez en prime des agents gratuits.Renat:
Si vous imposez au consommateur des paramètres inconnus pour choisir les prix, fixer les enchères, etc., le nombre de personnes qui utiliseront le service sera proche de zéro.
Le service doit être très simple et intelligent. C'est le seul moyen d'attirer les acheteurs et les vendeurs.
Un autre problème concerne les agents libres, que les propriétaires lanceront sans être liés à des logins.
Oui, c'est une très bonne façon de calculer le coût.
C'est bizarre, je pensais que j'allais le redire ;)
Dans ce cas, je vais développer mon message précédent :
si 1 PC coûte ~0,6 $ par jour en consommation d'électricité, il faut répartir correctement le coût (0,6 $) de l'électricité au cours de la journée, car de 8 à 17 heures les PC des utilisateurs sont éteints par beaucoup, de 17 à 23 heures la plupart allument les PC, de 24 à 8 heures les PC sont à nouveau éteints. Il s'avère que la période de 0 à 17 heures devrait être la plus payante, et de 17 à 24 heures un peu moins chère - je pense que le coût de la vente de ressources pendant cette période devrait correspondre au coût d'achat de ressources similaires. Comprenez parfaitement que même si runet est réparti sur de nombreux fuseaux horaires, il ne sera peut-être pas nécessaire de le diviser en tranches horaires - il y aura de la demande, il y aura de l'offre