Discussione pubblica della formula per calcolare il costo delle risorse nella rete Cloud MQL5
Per stimare il costo delle risorse, si potrebbe provare l'idea "compro un computer per 500 dollari e voglio recuperare il costo affittandolo di notte". Per semplificare, si possono omettere i costi associati di elettricità, raffreddamento e internet e concentrarsi su tre metriche:
- costo del computer (ad esempio 500 dollari)
- Periodo di recupero (2 anni a 8 ore a notte, TEMPO)
- prestazioni del computer (ad esempio 100 unità PR)
Bisogna anche aggiungere il costo dell'elettricità consumata all'ora e il traffico Internet).
Non avete una stima approssimativa o molto approssimativa della domanda di questo servizio in termini di numero di clienti-consumatori per unità di tempo? Per esempio 1.000 clienti-consumatori originali al mese hanno mai usato il servizio?
Forse ha senso condurre un sondaggio durante il mese tra i visitatori del quarto e quinto forum, compresi quelli non russi, sul tema "Chi in linea di principio è pronto a fornire un computer per il servizio a pagamento, ma a condizione che l'importo del pagamento non sia ancora noto"?
Non avete una stima approssimativa o molto approssimativa della domanda di questo servizio in termini di numero di clienti-consumatori per unità di tempo? Per esempio 1.000 clienti-consumatori originali al mese hanno mai usato il servizio?
Forse ha senso condurre un sondaggio nel corso di un mese tra i visitatori del quarto e quinto forum, compresi i non russi, sul tema "Chi in linea di principio è pronto a fornire un computer per il servizio a pagamento, ma a condizione che l'importo del pagamento non è ancora noto?
C'è interesse per l'idea, e non c'è nemmeno bisogno di condurre un sondaggio, dato che l'idea è maturata e discussa da tempo.
Ci concentriamo sulle seguenti categorie di utenti:
- coloro che hanno bisogno di fare calcoli il più rapidamente possibile
- coloro che sono disposti ad accumulare risorse quando non vengono utilizzate, in modo da poter utilizzare rapidamente ciò che hanno accumulato in seguito
- coloro che sono disposti a vendere le loro risorse (o quelle disponibili) in cambio di denaro, per poi ritirarle (utenti non commerciali)
E c'è la sensazione che tra un anno predominerà la terza categoria di utenti che userà la funzione di pianificazione per vendere risorse in tempo non utilizzato.
C'è interesse per l'idea, e non è nemmeno necessario condurre un sondaggio, dato che l'idea è stata maturata e discussa per molto tempo.
Ci rivolgiamo alle seguenti categorie di utenti:
- coloro che hanno bisogno di fare calcoli il più rapidamente possibile
- coloro che sono disposti ad accumulare risorse quando non sono in uso, in modo da poter utilizzare rapidamente ciò che hanno accumulato in seguito
- coloro che sono disposti a vendere le loro risorse (o quelle disponibili) in cambio di denaro, per poi ritirarle (utenti non commerciali)
E c'è la sensazione che tra un anno predominerà la terza categoria di utenti che userà la funzione di pianificazione per vendere risorse in tempo non utilizzato.
Tu stabilisci un prezzo e poi qualcosa cambia e tu lo cambi e tutti ti urlano contro per essere così cattivo e ingiusto nei confronti di chi ha comprato al vecchio prezzo. è così.... guardando al futuro.
L'ideale sarebbe avere uno scambio, e come al solito in un mercato, il prezzo medio si fermerebbe al livello tra acquirenti e venditori e non si dovrebbe fare nulla.
È il momento di sollevare la questione che interessa tutti gli utenti: quanto costerà comprare e vendere le risorse?
La cosa più logica da fare sarebbe rendere la formula adattabile alla domanda/offerta :) .
Seguono alcune conclusioni e suggerimenti.
Spero che capiate che sono possibili dei veri e propri bloopers, quindi criticate, vagliate, moderate.
1. Penso che la cosa più logica sia mantenere un agente PR sul server, e raccogliere informazioni rilevanti, ad esempio diversi bot client falsi. Se rendiamo anonimo il cliente, dovrebbe praticamente garantire l'assenza di imbrogli con le PR. Un modo alternativo è quello di introdurre un centro di attestazione degli agenti.
2. Per quanto riguarda l'adattabilità. Questo è esattamente il caso in cui l'offerta dovrebbe superare la domanda. Ovviamente, per ottenere il giusto rapporto, è necessario modellare o calcolare il modello appropriato.
Il criterio è semplice: la probabilità che una richiesta rimanga in coda non deve superare una data soglia. La soglia, imho, non dovrebbe essere più di qualche punto percentuale.
Le attuali definizioni di COMPRATORI e VENDITORI non corrispondono a questa definizione.
Si potrebbe fare così:
ACQUISTI -- quantità media di lavoro per il tempo corrente (basato sulla storia, poiché è improbabile stimare il compito in unità di lavoro prima che sia completato)
VENDITORI - offerta attuale. (o in base alla storia)
È chiaro che in questa forma sembra rozzo, ma, imho, ha senso.
Alcune altre conclusioni per questo approccio
-- La storia dell'elaborazione dei compiti è necessaria, non necessariamente per transazioni, solo per volume.
-- Se volete ottenere una formula e dei calcoli adattivi ricorrenti, avete bisogno della storia delle quotazioni almeno per un certo periodo fisso.
-- I tassi dovrebbero essere cambiati non più di una volta al giorno per ridurre la confusione.
Allora otteniamo all'incirca quanto segue:
Rate[0] = (1 - alpha)*Rate[1] + alpha*(Rate[1]*(1 + sigm(1 - correction*BUYERS/SELLERS))) где, Rate -- условно -- текущая востребованность сервиса alpha -- максимальный разовый процент изменения рейта sigm -- сигмоидная функция с областью значений от -1 до 1 correction -- тот самый коэффициент в СМО, который выравнивает перекос в отношении спроса\предложения.E il prezzo totale
TOTALPRICE = TIME * PR * PRICE * Rate[0]Allora PR può essere un valore costante, una semplice prestazione media.
- www.mql5.com
E c'è la sensazione che tra un anno prevarrà la terza categoria di utenti, che utilizzerà la funzione di pianificazione per vendere risorse in orari non utilizzati.
Non sto discutendo, ditemi voi, ma
1 come investimento non funzionerebbe (comprare un computer solo per affittarlo).
2. abbiamo un Klondike teorico sotto forma di un'enorme flotta di macchine da ufficio, ma il capoufficio medio con 20-30 macchine non lo comprerebbe nemmeno a causa dei problemi di sicurezza
un capoufficio medio con una fissazione per la sicurezza e un reddito trascurabile rispetto allo sforzo richiesto per generarlo
3 uno studente avanzato (non utilizzatore di trading) probabilmente ci andrebbe
tutto imho naturalmente
Imho, il prezzo non può essere cambiato.
Beh, solo tra un paio d'anni, tenendo conto dell'inflazione e di altre perturbazioni.
Imho il prezzo non può essere cambiato.
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Ogni giorno la rete MQL5 Cloud Network inizia a respirare più attivamente. Stiamo correggendo i bug, passo dopo passo, avvicinando il rilascio del sistema.
Per coloro che non sono a conoscenza dei calcoli distribuiti, ecco un paio di screenshot di tipici agenti di cloud computing:
Nel terminale client, la rete è mostrata come segue:
Per i prossimi due mesi, l'MQL5 Cloud Network funzionerà in modalità di prova pubblica per consentire agli sviluppatori di trovare e correggere i massimi bug. Per ora la rete funziona in modalità libera. Non appena stabilizzeremo i processi di lavoro nella rete e abiliteremo la contabilità completa delle risorse consumate, faremo il rilascio.
A tutti viene chiesto di collegare attivamente i loro agenti alla rete, in modo da poter testare il cloud sotto un carico serio. Alla fine del test, tutti i partecipanti che hanno fornito i loro agenti riceveranno dei bonus (che possono essere ritirati o spesi)!
È il momento di sollevare una questione che interessa tutti gli utenti: quanto costerà comprare e vendere le risorse?
Per iniziare la discussione si suggerisce di prendere alcuni parametri (per ogni agente individualmente):
TIME - затраченное время на расчет задачи(пакета задач) в миллисекундах
PR - индекс производительности агента (недостоверная величина, фальсифицируемая)
PRICE - автоматически высчитываемая цена за единицу работы (самое сложное)
PRJOB - единица работы в виде 1 единицы PR за 1 ms времени TIME
вспомогательные величины:
BUYERS - количество покупателей (количество работ в очереди)
SELLERS - количество продавцов (агентов)
Per esempio, il prezzo totale di vendita delle risorse per agente potrebbe essere così:
TOTALPRICE = TIME * PR * PRICE
La formula è molto semplice e non c'è nessuna normalizzazione di PR, che può essere manomessa dall'agente. Lasciamo il controllo, la normalizzazione e la lotta agli imbrogli per dopo. Anche una piccola commissione sarà presa dal prezzo a favore dell'organizzatore della rete di liquidazione per mantenere il servizio.
Per stimare il costo delle risorse, si potrebbe provare l'idea "compro un computer per 500 dollari e voglio recuperare il costo affittandolo di notte". Per semplificare, si possono omettere i costi associati di elettricità, raffreddamento e internet e concentrarsi su tre metriche:
Proviamo a calcolare il costo di 1 PR per 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 доллара
Per stimare il costo di vendita delle risorse per 1 ora di questo computer, facciamo un semplice calcolo:
Миллисекунд = 60 минут * 60 секунд * 1000 миллисекунд = 3 600 000 миллисекунд
Стоимость 1 часа при 100 PR = 3 600 000 миллисекунд * 100 PR * 4,8225308641975308641975308641975e-10 доллара = 0,17361111111111111111111111111111 доллара
Si scopre che un'ora di noleggio di questo computer costa 17 centesimi, e 8 ore di lavoro notturno costerebbero 1,38 dollari.
Questo è "poco" dal lato del venditore, ma bisogna anche guardare il lato dell'acquirente. Ad un certo prezzo, potrebbero non esserci acquirenti.
Per trovare un prezzo ragionevole, è necessario qualche meccanismo che bilanci automaticamente il prezzo per unità di lavoro. E questo meccanismo deve essere protetto dalla semplice manipolazione.
Il numero di acquirenti/venditori al momento o i loro valori medi giornalieri e valori simili possono essere usati come fattori di regolazione.
O forse anche calcolare il prezzo di partenza per unità di risorsa, e poi una volta in 1-3 mesi viene corretto manualmente con annuncio pubblico a seconda dell'attività del servizio (acquirenti e venditori).
Finora tutti i calcoli a livello di proposte. Per favore, date la vostra opinione, correggetela o suggerite la vostra versione.