Discussione pubblica della formula per calcolare il costo delle risorse nella rete Cloud MQL5 - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ci concentriamo sulle seguenti categorie di utenti:
E c'è la sensazione che tra un anno prevarrà una terza categoria di utenti che utilizzerà la funzione di pianificazione per vendere risorse in tempo non utilizzato.
4. quelli che sono 3 e 2 fino a quando non hanno bisogno di 1 - e come 1 lo useranno molto meno spesso (commercianti che padroneggiano MQL5 per se stessi).
% è difficile da esprimere, naturalmente.
//////////////////////////////
deve essere necessariamente presente nei calcoli.
Esempio: sto pompando 24 ore al giorno, perché non raccolgo soldi gratis a ore?
Domanda: "lento" (per esempio, per ritardo (ping)) sarà in qualche modo tagliato?
//////////////////////////////
D'altra parte, la maggior parte degli utenti non ha la capacità dei server degli sviluppatori, che saranno la parte del leone dei calcoli in primo luogo.
Cosa resterà ai venditori dei loro nuclei?
//////////////////////////////
Francamente, non vedo cifre adeguate, in base a cosa contare.
Da un lato dobbiamo almeno conoscere il costo del cloud e partire dalla redditività dell'azienda per MetaQuotes (il prezzo più basso possibile). Supponiamo che io, come potenziale venditore e/o acquirente, sia soddisfatto di 1$/giorno per nucleo. Gli sviluppatori saranno soddisfatti con 10 centesimi?
Dal lato dell'utente che procede dal costo del computer... Beh, non so. Anche in questo thread sono stati citati 500 e 2.000 dollari. È una diffusione piuttosto ampia.
Immagino che dobbiamo ancora iniziare con quanto l'acquirente è disposto a pagare e quanti saranno questi acquirenti.
Forse in generale prendere il prezzo medio dell'Expert Advisor (a seconda della complessità), i programmatori che lavorano su richiesta, possono stimare? e poi regolare i coefficienti. Sul carico totale della nuvola, come opzione.
Propongo di citare il costo di un'ora di 100 unità PR in un grafico, che sarà disponibile sul sito web MQL5. Gli acquirenti e i venditori di tempo di CPU attraverso il sito web piazzano le loro offerte per comprare e vendere un'ora di 100 unità PR. Tutte le loro offerte per un certo periodo, per esempio negli ultimi 120 giorni (quasi un trimestre), vengono accumulate e viene calcolato il prezzo di equilibrio PRice120. Questo prezzo di equilibrio sarà il prezzo dell'ora 100 unità PR. Se il prezzo dell'offerta del venditore è inferiore al prezzo PRice120, allora il suo tempo di lavorazione viene venduto, se superiore, non viene venduto. Con gli acquirenti è vero il contrario.
Il periodo di tempo durante il quale le offerte sono accumulate è scelto da ogni compratore e venditore individualmente tra diverse opzioni: 30 giorni, 60 giorni, ecc. La deviazione del suo prezzo dal prezzo di equilibrio al momento dell'attivazione è anche scelta da ogni compratore e venditore individualmente.
Troppo complicato secondo me. Il prezzo dovrebbe essere fissato a livello centrale sulla base di statistiche e informazioni aggiuntive. Le statistiche generali sono viste solo dagli sviluppatori, sono loro che hanno le carte in mano.
E periodicamente regolare il prezzo (diciamo, una volta al trimestre) può essere basato sulla domanda e l'offerta. Supponiamo che si imposta un prezzo di 1 centesimo, e disposti a lavorare con la nuvola sarà molto più di quanto richiesto - è necessario aumentare il prezzo per aumentare la volontà di fornire le loro capacità.
Se il prezzo è troppo alto, gli acquirenti se ne andranno (per reti private o altrove) e allora il prezzo dovrà essere ridotto.
L'unica questione è su quale prezzo basarsi.
Avete clienti aziendali che hanno acquistato TeamWox. Probabilmente qualcuno della vostra azienda mantiene relazioni con loro. Forse dovreste provare a proporre loro "l'idea di aumentare il riciclaggio/carico dell'80-90% della potenza inattiva del computer". Hanno già fiducia nella vostra azienda e la questione del prezzo può essere determinata rapidamente - potrebbe essere vicino all'equo e ottimale.
Un'altra idea è che cercheremo di coinvolgere enormi comunità di appassionati che sono stati coinvolti per decenni (quasi sempre gratuitamente) in vari progetti di calcolo distribuito (SETI@home e quelli simili sulla piattaforma BOINC).
Abbiamo un buon incentivo per pagare le risorse.
Renat:
Eseguiremo diversi strumenti sintetici sul server MetaQuotes-Demo, dove il numero di venditori, acquirenti e prezzo può essere monitorato. La formula per calcolare/adeguare il prezzo sarà disponibile pubblicamente in modo che tutto sia trasparente.
Se dobbiamo cambiare esplicitamente il prezzo base o aggiustare la formula di calcolo, possiamo farlo con una discussione pubblica.
Un'altra idea è che cercheremo di coinvolgere enormi comunità di appassionati che hanno partecipato (quasi sempre gratuitamente) a vari progetti di calcolo distribuito(SETI@home e altri simili sulla piattaforma BOINC) per decenni.
Domanda: quelli "lenti" (per esempio per latenza (ping)) saranno in qualche modo tagliati fuori, o entreranno per priorità/prestazioni?
Vengono identificati sul server cloud e "prestazioni e tempo" vengono regolati di conseguenza. Principalmente questo è per combattere gli imbrogli.
Cosa resterà ai venditori dei loro nuclei?
Non abbiamo intenzione di vendere le nostre risorse; il nostro obiettivo è quello di costruire un'enorme rete di distribuzione in tutto il mondo.
Naturalmente, alcune delle nostre risorse saranno distribuite gratuitamente, almeno nella fase iniziale.
Siamo solo operatori di una rete distribuita, l'obiettivo è quello di creare una nuvola per decine e centinaia di migliaia di agenti di calcolo.
Guardate l'elenco geograficamente distribuito dei server cloud - ce ne saranno altri quando il carico aumenterà.
Una semplice variante di 1 Prezzo unitario = Prezzo base * Func( Venditori, acquirenti, tempo)
Di conseguenza, il prezzo sarà automaticamente regolato ogni ora a seconda della domanda e dell'offerta.
E si potrebbe prendere come base il costo medio ospedaliero di base dei servizi cloud già esistenti.
Sì, anche questo era un pensiero. Ma lì il prezzo include l'intero computer con dischi, memoria e CPU e il resto dell'infrastruttura di sicurezza e backup.
È uno schema troppo complicato, dato che nessuno è disposto ad alzare un dito (e c'è tutto un processo di offerte manuali) per somme misere. Il sistema deve funzionare in modo quasi automatico.