Stai parlando della cartella condivisa C:\Users\User\AppData\Roaming\MetaQuotes\Tester\.
Lo stesso principio è necessario per il terminale in modalità normale e non con la specificazione forzata della cartella condivisa alle basi della storia per mezzo di collegamenti. Ora funziona bene, ma per favore implementate questa funzione normalmente specificando una cartella per le basi della cronologia nelle impostazioni del terminale.
:-)
Ho già fatto una richiesta, per distribuire la sandbox con i file di dati e i log sul sistema di dischi per la velocità.
Per esempio c'è un drive SSD, uno per il sistema, SSD per i log, SSD per i dati veloci.
Beh, sarebbe bene se i log su un SSD, i dati sull'altro - il terminale stesso dove può essere anche sul SSD
La velocità di accesso ai dati aumenterà, tenendo conto che ogni unità ha il proprio controller.
voi parlate di qualcos'altro - per l'accesso a un database comune - per raccogliere dati da un dilling per diversi terminali in una cartella - quante persone hanno una tale configurazione?
Ho appena comprato 12 terabyte di hard disk e ho dimenticato il problema - gli hard disk sono così grandi ora che non è rilevante.
Andrey Dik: No, quello che Andrew sta suggerendo è che gli sviluppatori rendano l'accesso pubblico alle cartelle una caratteristica regolare. Questo è esattamente quello che sta suggerendo, questo è un appello a voi, non a milioni di commercianti.
Viene data una spiegazione:
Nessuno farà un collo di bottiglia sotto forma di server (e un unico database significa un gestore di accesso. E questo gestore non può essere un file system con accesso bloccante - tutto rallenterebbe favolosamente)
nessuno farà un collo di bottiglia in scrittura nel sistema
nessuno farà passare decine di gigabyte di dati (e sono decine di gigabyte) attraverso un collo di bottiglia
il comportamento degli agenti tester è ragionevole - useranno un database sincronizzato di sola lettura
tutto sull'altare della velocità e della bassa latenza
L'architettura attuale è molto buona, veloce e sicura. Abbiamo scritto la quinta generazione di piattaforme di trading per una ragione - conosciamo il valore di ogni soluzione.
Nessuno farà un collo di bottiglia sotto forma di server (e una base unica significa un gestore di accesso. e questo gestore non può essere un file system con blocco di accesso - tutto sarà favolosamente lento)
Di conseguenza, i programmatori di applicazioni scrivono proprio quei file manager con blocchi di accesso e freni favolosi, perché non c'è altra soluzione in MQL. Ma i loro animi sono riscaldati dalla magica "latenza" e da altri mantra di prestazioni teoriche, che sono difficili da applicare nella pratica.
Vasiliy Sokolov: Giusto. Di conseguenza, i programmatori di applicazioni scrivono quei file manager con blocchi di accesso e freni da favola perché non c'è altra soluzione nel quadro di MQL. Ma i loro animi sono riscaldati dalla magica "latenza" e da altri mantra di prestazioni teoriche, che sono difficili da applicare nella pratica.
La funzione fornisce accesso atomico a una variabile globale, quindi può essere utilizzata per organizzare il mutex quando più EA lavorano simultaneamente nello stesso terminale client.
E se la sincronizzazione tra terminali è necessaria, ci sono molte opzioni. Anche su file, ma tramite DLL mutex ecc. Questo è il tuo lavoro ora, dato che sei fuori dalla sandbox della sicurezza.
Senza la nostra battaglia per la velocità avreste una classe di software completamente diversa. La roba buona non è visibile, sembra gratuita e autoevidente.
Vasiliy Sokolov: Sì... Di conseguenza, i programmatori di applicazioni scrivono proprio quei gestori di file con blocchi di accesso e freni enormi, perché non c'è altra soluzione in MQL.
Tutto ha un senso per me. Se volete capacità multiterminali, fatevele da soli, ma è un po' irrazionale farlo per due persone e mezzo.
Inoltre, nella stragrande maggioranza dei casi, questi problemi possono essere risolti in uno o due.
E se stiamo parlando di due persone e mezzo, più persone hanno bisogno della storia personalizzata.
Vi è stato detto che dovete creare un gestore di accesso ai dati da diversi terminali!
E qual è il problema dell'accesso di terminali diversi a dati diversi! Nessun problema, ma è comodo se tutti i file sono in un unico posto e non c'è bisogno di scaricare i dati ogni volta quando si trasferisce/reinstalla il terminale. Ma gli sviluppatori non vogliono fare neanche questo. Non c'è bisogno di un gestore di accessi per questo.
Parlavo di 2-3 terminali che accedono agli stessi dati. Non c'è nessun problema, basta che i terminali capiscano che qualcuno sta già scrivendo e non cerchino di scrivere. E quando si legge non dovrebbe esserci alcun problema.
Non hai nessuna voglia di leggere, capire o discutere. Non ho alcun desiderio di gettarci dietro delle perline. Conosco una soluzione stampella (dato che gli sviluppatori non vogliono fare funzioni regolari) - ne sono soddisfatto.
xxz: E il file 2016.hcc in teoria non dovrebbe mai essere aggiornato.
Renat Fatkhullin:
Viene data una spiegazione:
Nessuno costruirà un collo di bottiglia sotto forma di server(e una singola base significa un gestore di accesso. E quel gestore non può essere un file system bloccato - tutto rallenterebbe favolosamente)
nessuno farà un collo di bottiglia nel sistema per la registrazione
nessuno farà passare decine di gigabyte di dati (e sono decine di gigabyte) attraverso un collo di bottiglia
il comportamento degli agenti tester è ragionevole - useranno un database sincronizzato di sola lettura
tutto è sull'altare della velocità e della bassa latenza
L'architettura attuale è molto buona, veloce e sicura. Non abbiamo scritto la quinta generazione di piattaforme di trading per niente - conosciamo il costo di ogni soluzione.
Ne sono ben consapevole...
perché ho avuto il privilegio di sviluppare sistemi operativi e driver per loro.
Artyom Trishkin: Amici, basta con i battibecchi. Sto cancellando il diluvio.
No no, non cancellare le parole di Yuri. Egli sostiene che il terminale scrive sul file ad ogni tick! Questa è un'accusa di non professionalità da parte di MQ, voglio vedere cosa ne farà Renat, alle cui parole si riferisce Yuri. Non negarmi il piacere di godermi lo spettacolo che verrà.
Stai parlando della cartella condivisa C:\Users\User\AppData\Roaming\MetaQuotes\Tester\.
Lo stesso principio è necessario per il terminale in modalità normale e non con la specificazione forzata della cartella condivisa alle basi della storia per mezzo di collegamenti. Ora funziona bene, ma per favore implementate questa funzione normalmente specificando una cartella per le basi della cronologia nelle impostazioni del terminale.
:-)
Ho già fatto una richiesta, per distribuire la sandbox con i file di dati e i log sul sistema di dischi per la velocità.
Per esempio c'è un drive SSD, uno per il sistema, SSD per i log, SSD per i dati veloci.
Beh, sarebbe bene se i log su un SSD, i dati sull'altro - il terminale stesso dove può essere anche sul SSD
La velocità di accesso ai dati aumenterà, tenendo conto che ogni unità ha il proprio controller.
voi parlate di qualcos'altro - per l'accesso a un database comune - per raccogliere dati da un dilling per diversi terminali in una cartella - quante persone hanno una tale configurazione?
Ho appena comprato 12 terabyte di hard disk e ho dimenticato il problema - gli hard disk sono così grandi ora che non è rilevante.
No, quello che Andrew sta suggerendo è che gli sviluppatori rendano l'accesso pubblico alle cartelle una caratteristica regolare. Questo è esattamente quello che sta suggerendo, questo è un appello a voi, non a milioni di commercianti.
Viene data una spiegazione:
L'architettura attuale è molto buona, veloce e sicura. Abbiamo scritto la quinta generazione di piattaforme di trading per una ragione - conosciamo il valore di ogni soluzione.
Giusto. Di conseguenza, i programmatori di applicazioni scrivono quei file manager con blocchi di accesso e freni da favola perché non c'è altra soluzione nel quadro di MQL. Ma i loro animi sono riscaldati dalla magica "latenza" e da altri mantra di prestazioni teoriche, che sono difficili da applicare nella pratica.
Sì - https://www.mql5.com/ru/docs/globals/globalvariablesetoncondition
La funzione fornisce accesso atomico a una variabile globale, quindi può essere utilizzata per organizzare il mutex quando più EA lavorano simultaneamente nello stesso terminale client.
E se la sincronizzazione tra terminali è necessaria, ci sono molte opzioni. Anche su file, ma tramite DLL mutex ecc. Questo è il tuo lavoro ora, dato che sei fuori dalla sandbox della sicurezza.
Senza la nostra battaglia per la velocità avreste una classe di software completamente diversa. La roba buona non è visibile, sembra gratuita e autoevidente.
Sì... Di conseguenza, i programmatori di applicazioni scrivono proprio quei gestori di file con blocchi di accesso e freni enormi, perché non c'è altra soluzione in MQL.
Tutto ha un senso per me. Se volete capacità multiterminali, fatevele da soli, ma è un po' irrazionale farlo per due persone e mezzo.
Inoltre, nella stragrande maggioranza dei casi, questi problemi possono essere risolti in uno o due.
E se stiamo parlando di due persone e mezzo, più persone hanno bisogno della storia personalizzata.
È una sfida?
Solo una pistola sarà carica? :-)
Vi è stato detto che dovete creare un gestore di accesso ai dati da diversi terminali!
E qual è il problema dell'accesso di terminali diversi a dati diversi! Nessun problema, ma è comodo se tutti i file sono in un unico posto e non c'è bisogno di scaricare i dati ogni volta quando si trasferisce/reinstalla il terminale. Ma gli sviluppatori non vogliono fare neanche questo. Non c'è bisogno di un gestore di accessi per questo.
Parlavo di 2-3 terminali che accedono agli stessi dati. Non c'è nessun problema, basta che i terminali capiscano che qualcuno sta già scrivendo e non cerchino di scrivere. E quando si legge non dovrebbe esserci alcun problema.
Non hai nessuna voglia di leggere, capire o discutere. Non ho alcun desiderio di gettarci dietro delle perline. Conosco una soluzione stampella (dato che gli sviluppatori non vogliono fare funzioni regolari) - ne sono soddisfatto.
E il file 2016.hcc in teoria non dovrebbe mai essere aggiornato.
Viene data una spiegazione:
L'architettura attuale è molto buona, veloce e sicura. Non abbiamo scritto la quinta generazione di piattaforme di trading per niente - conosciamo il costo di ogni soluzione.
Ne sono ben consapevole...
perché ho avuto il privilegio di sviluppare sistemi operativi e driver per loro.
Non riesco proprio a capirti!
Perché ti stai trasformando in un pazzo!
È un compito semplice rendere i file come "2017.hcc" pubblicamente disponibili all'interno di un broker
che, come ho capito ora, sono aggiornati una volta ogni "cinque anni".
Qual è il problema qui?
Amici, basta con i battibecchi. Sto cancellando il diluvio.