Discussione pubblica della formula per calcolare il costo delle risorse nella rete Cloud MQL5 - pagina 5

 
radioamator:
Non intendevo dire che si trattava di scambi. Un acquirente a tempo di CPU vuole comprarsi N ore di 100 unità PR. Deve in qualche modo informare il server che io, Ivan_Ivanov voglio comprare N ore e sono disposto a pagare M centesimi per questo. L'acquirente mette un ordine nel mio armadio personale per comprare, se il suo prezzo è superiore o uguale a qualche prezzo, base, equilibrio per 120 giorni o altro, allora l'acquirente compra il tempo del processore. Il punto è che le offerte di acquisto/vendita del tempo del processore messe in piedi attraverso il sito sono sia comandi al server per comprare/vendere che dati statistici per determinare il prezzo. E il grafico dei prezzi è solo questo, per informazione.

È troppo complicato - nessuno farà veramente delle offerte. L'uso dovrebbe essere semplice - clicca su "start" e il gioco è fatto. E l'acquirente dovrebbe sapere che ora il prezzo medio è X più meno il delta. Mostreremo il prezzo medio nella finestra dell'elenco degli agenti.

Abbiamo un altro problema - l'entrata di denaro (paypal, webmani e carte di credito), dove dovremo effettivamente fare transazioni manuali.

 

Renat:

Abbiamo un altro problema - l'entrata di denaro (paypal, webmani e carte di credito), dove bisogna effettivamente fare transazioni manuali.

Transazioni manuali o controllo manuale?

Con le carte e paypal continuo a capire, ma quali problemi ci possano essere con l'ingresso WM (piuttosto che il ritiro) è un mistero.

O è concepito il controllo "umano" di tutte le transazioni finanziarie?

 
joo:
0,01 centesimi per 100000PR all'ora.

Perché?

Si può mettere approssimativamente così. Il numero di partecipanti registrati su http://forum.mql4.com è qualcosa come 50.000. Hanno tutti un computer. Questo significa che in media ci sono 2 core per persona, quindi 50'000*2=100'000 core di processore. Inoltre, ci sono almeno 10 volte più utenti di MT in tutto il mondo. E questo è 100'000*10=1'000'000 di nuclei. Inoltre, c'è una categoria di utenti MT che hanno accesso alle reti locali da centinaia di computer, la percentuale di queste persone fortunate secondo i miei calcoli è circa l'1%:

50'000*10*0.1*100*2+50'000*10*2=11'000'000 ядер.

Per essere disposti a pagare per un tempo di ottimizzazione ridotto, avete bisogno di una velocità almeno 100 volte superiore a quella di un'ottimizzazione single-core. Il numero di utenti di MT che usano l'ottimizzazione in ogni momento non supera l'1%, cioè 50'000*10*0,1=50'000. Il numero di core cloud per persona:

11'000'000/50'000=220 ядер/чел. Si scopre che il numero di core disponibili è più del necessario di 220/100=2,2 volte. -questo è un bene. Questo è il carico di picco sulla rete, quando tutti sanno già della nuvola e la usano attivamente, all'inizio ci saranno molti più core disponibili per persona, penso 1000-10000 core/persona.

Ora, ci si potrebbe chiedere: "Quanto paghereste per 220 core extra sulla vostra CPU per ottimizzare 1 EA? - come scoprirlo?, puoi fare questa domanda nel profilo del membro in un modulo speciale, dove sono segnati i costi massimi e minimi possibili (per regolare i limiti nel tempo), il prezzo sarà in grado di mettere solo coloro che hanno agenti registrati nella rete (sia venditori che acquirenti). Così, potete visualizzare una volta al giorno il costo medio per unità di tempo PR (la cifra diventerà molto piccola, quindi meglio 1000PR per unità di tempo).


Ecco come stanno le cose.

HH non ha senso calcolare i calcoli del cloud sulla base dei costi di ammortamento del ferro, poiché il costo computazionale reale del ferro è 1000 volte inferiore (questo include il 90% di tempo inattivo, e come esempio le orde di appassionati di cloud computing scientifico che forniscono le loro risorse di computer "gratuitamente"). Non c'è modo che 50'000 persone possano permettersi i costi di ammortamento di computer con 11'000'000 di core di processore e un hardware che invecchia rapidamente.

MQL4: automated trading forum
  • www.mql5.com
MQL4: automated trading forum
 
Renat:
Quale dei prezzi ha più senso dal punto di vista del compromesso congiunto di venditore e compratore?
  • 0,5 centesimi all'ora
  • 1,0 centesimi all'ora
  • 1,5 centesimi all'ora
  • 2,0 centesimi all'ora
Per favore, parlate.
Imho, non ci dovrebbe essere un prezzo più economico del costo di alimentazione di un PC, 1 consumo del PC entro 250W --> 1kW x 4 ore --> 6kW x giorno. L'elettricità costa in media 8~10 centesimi di kW
 
Interesting:

Con le carte e paypal continuo a capire, ma quali problemi ci possano essere con l'ingresso WM (piuttosto che il ritiro) è un mistero.

Il problema è che gli utenti devono costringersi a registrare un account su MQL5.com e depositare denaro.

Questo è proprio il passo che può diminuire il numero di utenti disposti a utilizzare il servizio decine di volte. La psicologia deve essere presa in considerazione.

Se il consumatore è gravato da parametri sconosciuti per la selezione dei prezzi, l'impostazione delle richieste, ecc.

Il servizio dovrebbe essere molto semplice e ragionevole. Questo è l'unico modo per attirare acquirenti e venditori.

 
IgorM:
Imho, non ci dovrebbe essere più economico del costo della potenza del PC, 1 consumo del PC è entro 250W --> 1kW x 4 ore --> 6kW x giorno. Il costo dell'elettricità è in media di 8~10 centesimi di kW

Sì, non è un brutto modo di calcolare il costo.

Si scopre che l'acquirente pagherà per il calcolo nel cloud tanto quanto paga per l'elettricità sul suo PC, ma il calcolo sarà n volte più veloce, dove n-numero di agenti nel cloud.

E i venditori saranno in grado di compensare i loro costi di elettricità.

Il risultato sarà il seguente: i venditori guadagneranno (risparmio sull'elettricità, e il denaro risparmiato è il profitto), e gli acquirenti beneficeranno nella velocità di liquidazione (pagheranno lo stesso di prima per l'elettricità).

 

Un altro problema con gli agenti liberi, che i proprietari gestiranno senza essere legati ai login.

Tali agenti liberi saranno automaticamente e casualmente assegnati ai lavori. Ma saranno disponibili per i clienti che hanno un saldo positivo del conto MQL5.

Quindi, se si utilizza una rete a pagamento, si ottengono alcuni agenti gratuiti come bonus.
 

Renat:

Se si appesantisce il consumatore con parametri sconosciuti per la scelta dei prezzi, l'impostazione delle offerte, ecc, il numero di persone che usano il servizio sarà circa zero.

Il servizio deve essere molto semplice e intelligente. Questo è l'unico modo per attirare acquirenti e venditori.

Sul tema della semplicità sono d'accordo, meno casino c'è più è efficiente.
 
Renat:

Un altro problema con gli agenti liberi, che i proprietari lanceranno senza essere legati ai login.

Cioè, se eseguo un agente, va comunque nella rete cloud? Questo può essere gestito?
 
joo:

Sì, questo è un ottimo modo di calcolare il costo.

Che strano, pensavo che l'avrei detto di nuovo ;)

Bene, allora amplierò il mio post precedente:

se 1 PC costa ~$0.6 al giorno in consumo di elettricità, si dovrebbe allocare il costo ($0.6) di elettricità correttamente durante il giorno, perché dalle 8 alle 17 ore i PC degli utenti sono spenti da molti, dalle 17 alle 23 ore la maggior parte accende i PC, dalle 24 alle 8 del mattino i PC sono spenti di nuovo. Risulta che il tempo da 0 a 17 ore dovrebbe essere il più pagato, e da 17 a 24 ore un po' più economico - penso che il costo di vendita delle risorse durante questo periodo dovrebbe corrispondere al costo di acquisto di risorse simili. Capire perfettamente che anche runet è distribuito su molti fusi orari, forse non ci sarà bisogno di dividere in fasce orarie - ci sarà la domanda, ci sarà l'offerta