Discussion publique sur la formule de calcul du coût des ressources du réseau en nuage de MQL5
Pour estimer le coût des ressources, vous pouvez essayer l'idée suivante : "J'achète un ordinateur pour 500 dollars et je veux en récupérer le coût en le louant la nuit". Pour simplifier, vous pouvez omettre les coûts associés à l'électricité, au refroidissement et à l'internet et vous concentrer sur trois paramètres :
- le coût de l'ordinateur (par exemple, 500 $)
- Période de récupération (2 ans à 8 heures par nuit, TEMPS)
- performances informatiques (par exemple, 100 unités PR)
Il faut également ajouter le coût de l'électricité consommée par heure et le trafic Internet).
N'avez-vous pas une estimation approximative ou très approximative de la demande de ce service en termes de nombre de clients-consommateurs par unité de temps ? Par exemple, 1 000 clients-consommateurs originaux par mois ont déjà utilisé le service ?
Peut-être serait-il judicieux de mener une enquête au cours du mois auprès des visiteurs des quatrième et cinquième forums, y compris les non-russes, sur le thème "Qui est en principe prêt à fournir un ordinateur pour le service contre de l'argent, mais à condition que le montant du paiement ne soit pas encore connu" ?
N'avez-vous pas une estimation approximative ou très approximative de la demande de ce service en termes de nombre de clients-consommateurs par unité de temps ? Par exemple, 1 000 clients-consommateurs originaux par mois ont déjà utilisé le service ?
Peut-être serait-il judicieux de mener une enquête pendant un mois auprès des visiteurs des quatrième et cinquième forums, y compris les non-russes, sur le thème "Qui est en principe prêt à fournir un ordinateur pour le service contre de l'argent, mais à condition que le montant du paiement ne soit pas encore connu ?
L'idée suscite de l'intérêt, et il n'y a même pas eu de sondage, car l'idée a mûri et a été discutée depuis longtemps.
Nous nous concentrons sur les catégories d'utilisateurs suivantes :
- ceux qui ont besoin de faire des calculs le plus rapidement possible
- ceux qui sont prêts à accumuler des ressources lorsqu'elles ne sont pas utilisées, afin de pouvoir utiliser rapidement ce qu'ils ont accumulé par la suite.
- ceux qui sont prêts à vendre leurs ressources (ou les ressources disponibles) contre de l'argent, puis à les retirer (utilisateurs non-commerçants)
Et l'on a le sentiment que d'ici un an, la troisième catégorie d'utilisateurs qui utiliseront la fonction de planification pour vendre des ressources en temps non utilisé prédominera.
L'idée suscite de l'intérêt, et il n'est même pas nécessaire de mener une enquête, car l'idée a été mûrie et discutée depuis longtemps.
Nous ciblons les catégories d'utilisateurs suivantes :
- ceux qui ont besoin de faire des calculs le plus rapidement possible
- ceux qui sont prêts à accumuler des ressources lorsqu'elles ne sont pas utilisées, afin de pouvoir utiliser rapidement ce qu'ils ont accumulé par la suite.
- ceux qui sont prêts à vendre leurs ressources (ou les ressources disponibles) contre de l'argent, puis à les retirer (utilisateurs non-commerçants)
Et l'on a le sentiment que d'ici un an, la troisième catégorie d'utilisateurs qui utiliseront la fonction de planification pour vendre des ressources en temps non utilisé prédominera.
Vous fixez un prix et puis quelque chose change et vous le changez et tout le monde vous crie dessus pour avoir été si mauvais et injuste envers ceux qui ont acheté à l'ancien prix. c'est comme ça..... en regardant vers l'avenir.
L'idéal serait d'avoir un échange, et comme d'habitude dans un marché, le prix moyen s'arrêterait au niveau entre les acheteurs et les vendeurs et vous n'auriez rien à y faire.
Il est temps de poser la question qui intéresse tous les utilisateurs : combien coûteront les ressources à l'achat et à la vente?
La chose la plus logique à faire serait de rendre la formule adaptable à la demande/offre :) .
Voici quelques conclusions et suggestions.
J'espère que vous comprenez que des ratés sont possibles, alors critiquez, passez au crible, modérez.
1. Je pense que la chose la plus logique est de garder un agent PR sur le serveur, et de collecter les informations pertinentes, par exemple plusieurs faux bots clients. Si on anonymise le client, cela devrait pratiquement garantir l'absence de tricherie avec les RP. Une autre solution consiste à mettre en place un centre d'attestation des agents.
2. Concernant l'adaptabilité. C'est exactement le cas où l'offre devrait dépasser la demande. Évidemment, pour obtenir le bon ratio, vous devez modéliser ou calculer le modèle approprié de WMS.
Le critère est simple : la probabilité qu'une demande reste dans la file d'attente ne doit pas dépasser un seuil donné. Le seuil, à mon avis, ne devrait pas être supérieur à quelques pour cent.
Les définitions actuelles des ACHETEURS et des VENDEURS ne correspondent pas à cette définition.
Vous pourriez le faire comme ça :
ACHETEURS -- montant moyen du travail pour le moment (basé sur l'historique, puisqu'il est peu probable d'estimer la tâche en unités de travail avant qu'elle ne soit terminée)
VENDEURS -- offre actuelle. (ou basé sur l'histoire)
Il est clair que sous cette forme, elle semble grossière, mais, à mon avis, elle a du sens.
Quelques conclusions supplémentaires pour cette approche
-- L'historique du traitement des tâches est nécessaire, pas nécessairement par transactions, seulement par volume.
-- Si vous voulez obtenir des formules et des calculs adaptatifs récurrents, vous devez disposer d'un historique des devis, au moins pour une période déterminée.
-- les taux ne devraient pas être modifiés plus d'une fois par jour afin de réduire la confusion.
On obtient alors à peu près ce qui suit :
Rate[0] = (1 - alpha)*Rate[1] + alpha*(Rate[1]*(1 + sigm(1 - correction*BUYERS/SELLERS))) где, Rate -- условно -- текущая востребованность сервиса alpha -- максимальный разовый процент изменения рейта sigm -- сигмоидная функция с областью значений от -1 до 1 correction -- тот самый коэффициент в СМО, который выравнивает перекос в отношении спроса\предложения.Et le prix total
TOTALPRICE = TIME * PR * PRICE * Rate[0]Le PR peut alors être une valeur constante, une simple performance moyenne.
- www.mql5.com
Et l'on a le sentiment que dans un an, la troisième catégorie d'utilisateurs l'emportera, qui utilisera la fonction de planification pour vendre des ressources à des moments non utilisés.
Je ne discute pas, vous me dites, mais...
1 En tant qu'investissement, cela ne fonctionnerait pas (acheter un ordinateur juste pour le louer).
2. nous disposons d'un Klondike théorique sous la forme d'un énorme parc de machines de bureau, mais le chef de bureau moyen possédant 20 à 30 voitures ne l'achèterait pas non plus pour des raisons de sécurité
un gestionnaire de bureau moyen avec une fixation sur la sécurité et un revenu négligeable par rapport à l'effort nécessaire pour le générer
3 un étudiant avancé (non utilisateur de trading) se lancerait probablement dans l'aventure.
tout cela est bien sûr subjectif
Je pense que le prix ne peut être modifié.
Eh bien, seulement dans quelques années, en tenant compte de l'inflation et d'autres perturbations.
Je pense que le prix ne peut être modifié.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Chaque jour, le MQL5 Cloud Network commence à respirer plus activement. Nous corrigeons les bogues, étape par étape, ce qui nous rapproche de la sortie du système.
Pour ceux qui ne connaissent pas les calculs distribués, voici quelques captures d'écran d'agents de cloud computing typiques :
Dans le terminal client, le réseau est représenté comme suit :
Au cours des deux prochains mois, le MQL5 Cloud Network fonctionnera en mode de test public afin de permettre aux développeurs de trouver et de corriger un maximum de bogues. Pour l'instant, le réseau fonctionne en mode gratuit. Dès que nous aurons stabilisé les processus de travail dans le réseau et permis une comptabilité complète des ressources consommées, nous procéderons à la libération.
Il est demandé à chacun de connecter activement ses agents au réseau, afin de pouvoir tester le nuage sous une charge importante. À la fin du test, tous les participants qui ont fourni leurs agents recevront des bonus (qui peuvent être retirés ou dépensés) !
Il est temps d'évoquer une question qui intéresse tous les utilisateurs : combien coûteront les ressources à l'achat et à la vente?
Pour commencer la discussion, il est suggéré de prendre quelques paramètres (pour chaque agent individuellement) :
TIME - затраченное время на расчет задачи(пакета задач) в миллисекундах
PR - индекс производительности агента (недостоверная величина, фальсифицируемая)
PRICE - автоматически высчитываемая цена за единицу работы (самое сложное)
PRJOB - единица работы в виде 1 единицы PR за 1 ms времени TIME
вспомогательные величины:
BUYERS - количество покупателей (количество работ в очереди)
SELLERS - количество продавцов (агентов)
Par exemple, le prix de vente total des ressources par agent pourrait ressembler à ceci :
TOTALPRICE = TIME * PR * PRICE
La formule est très simple et il n'y a pas de normalisation des RP, qui peut être altérée par l'agent. Laissons le contrôle, la normalisation et la lutte contre la tricherie pour plus tard. Une petite commission sera également prélevée sur le prix en faveur de l'organisateur du réseau d'établissement afin de maintenir le service.
Pour estimer le coût des ressources, vous pouvez essayer l'idée suivante : "J'achète un ordinateur pour 500 dollars et je veux en récupérer le coût en le louant la nuit". Pour simplifier, vous pouvez omettre les coûts associés à l'électricité, au refroidissement et à l'Internet et vous concentrer sur trois paramètres :
Essayons de calculer le coût d'un RP pour 1 ms :
Всего часов = 360 дней * 8 часов = 2 880
Всего миллисекунд = 2 880 часов * 60 минут * 60 секунд * 1000 миллисекунд = 10 368 000 000 ms
Стоимость 1PR за 1 ms = 500 долларов / 10 368 000 000 ms / 100 PR = 4,8225308641975308641975308641975e-10 доллара
Pour estimer le coût de la vente des ressources pour 1 heure de cet ordinateur, faisons un calcul simple :
Миллисекунд = 60 минут * 60 секунд * 1000 миллисекунд = 3 600 000 миллисекунд
Стоимость 1 часа при 100 PR = 3 600 000 миллисекунд * 100 PR * 4,8225308641975308641975308641975e-10 доллара = 0,17361111111111111111111111111111 доллара
Il s'avère qu'une heure de location de cet ordinateur coûte 17 cents, et que 8 heures de travail de nuit coûteraient 1,38 $.
Ce n'est pas grand-chose du côté du vendeur, mais il faut aussi regarder du côté de l'acheteur. À un certain prix, il peut ne pas y avoir d'acheteurs.
Afin de trouver un prix raisonnable, un mécanisme est nécessaire pour équilibrer automatiquement le prix par unité de travail. Et ce mécanisme doit être protégé de la simple manipulation.
Le nombre d'acheteurs/vendeurs du moment ou leurs valeurs quotidiennes moyennes et autres valeurs similaires peuvent être utilisés comme facteurs d'ajustement.
Ou peut-être même calculer le prix de départ pour l'unité de ressource, et ensuite une fois tous les 1-3 mois, il est corrigé manuellement avec une annonce publique en fonction de l'activité du service (acheteurs et vendeurs).
Jusqu'à présent, tous les calculs ont été effectués au niveau des propositions. Donnez votre avis, corrigez-la ou proposez votre propre version.