MT5 e la velocità in azione - pagina 69
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
come lo immaginate, un'elaborazione parallela in un singolo thread?
Un ciclo di eventi.
E in generale è un problema dello sviluppatore perché tutto viene eseguito in un thread.
Si scopre che la panoramica del mercato viene elaborata in modo asincrono, e i gestori nei programmi utente, in modo sincrono.
È semplicemente chicardoso, non ci sono parole.
Grazie per il feedback sulle statistiche! I ritardi di OnTick/OnBook sembrano essere presenti per tutti. Sleep(1) è 1 ms o 15 ms. Non è chiaro perché dipenda.
Tutti sembrano avere lag OnTick/OnBook.
Penso che sappiate che OnTimer() non può essere chiamato più spesso di 10-16 millisecondi. È logico supporre che anche altre funzioni OnXXX non siano chiamate più spesso. Forse è per questo che si verificano i tuoi ritardi?
Penso che sappiate che OnTimer() non può essere chiamato più spesso di 10-16 millisecondi. È logico supporre che anche altre funzioni OnXXX non siano chiamate più spesso. Forse è questa la ragione dei vostri ritardi?
Non logicamente, i gestori non sono legati alla frequenza/risoluzione del timer GetTickCount. Gli eventi si attivano istantaneamente nel momento in cui accadono.
Anche OnTimer non è legato all'errore di 16ms. È facile ottenere un timer di 1ms nella stragrande maggioranza dei casi, a meno che il computer non sia morto e caricato al 100%.
Il problema con quasi tutti i test di fxsaber è che cerca di misurare gli outlier delle singole chiamate invece di fare la media dell'insieme e non vuole capire la realtà del thread dispatcher.
Lo ha fatto:
Metodi di lotta per avvicinarsi al tempo di riposo:
Di conseguenza, su un normale VPS i terminali (così come qualsiasi altro programma) soffriranno sempre di ritardi imprevisti. Più VPS economici/sovravenduti, più problemi.
Chiedetevi sul vostro VPS, SR-IOV è abilitato e ci sono dei driver di rete speciali più recenti (installati solo manualmente) per esso? Nel 99% dei casi, no, perché rompe la migrazione delle virtualizzazioni attraverso lo zoo dell'hardware. E senza di esso sono garantiti ulteriori ritardi semplicemente a causa della doppia trasmissione/elaborazione dei pacchetti di rete (su host e virtuale) e dell'aumento del numero di interrupt.
Il nostro servizio VPS è molto meno soggetto a questo, sia in termini di architettura che di terminali leggeri senza GUI.
Non logico, i gestori non sono legati alla frequenza/risoluzione del timer GetTickCount. Gli eventi sono attivati istantaneamente nel momento in cui si verificano.
Anche OnTimer non è legato all'errore di 16ms. È facile ottenere un timer di 1ms nella stragrande maggioranza dei casi, a meno che il computer non sia morto e caricato al 100%.
Il problema con quasi tutti i test di fxsaber è che cerca di misurare gli outlier delle singole chiamate invece di fare la media dell'insieme e non vuole capire la realtà del thread dispatcher.
Lo ha fatto:
Metodi di lotta per avvicinarsi al tempo di riposo:
Di conseguenza, su un normale VPS i terminali (così come qualsiasi altro programma) soffriranno sempre di ritardi imprevisti. Più VPS economici/sovravenduti, più problemi.
Chiedetevi sul vostro VPS, SR-IOV è abilitato e ci sono dei driver di rete speciali più recenti (installati solo manualmente) per esso? Nel 99% dei casi, no, perché rompe la migrazione delle virtualizzazioni attraverso lo zoo dell'hardware. E senza di esso sono garantiti ulteriori ritardi semplicemente a causa della doppia trasmissione/elaborazione dei pacchetti di rete (su host e virtuale) e dell'aumento del numero di interrupt.
Il nostro servizio VPS è soggetto ad esso per ordini di grandezza inferiori, sia in termini di architettura che di terminali leggeri senza GUI.
E ora immaginate quante volte più lente sarebbero le prestazioni dei programmi utente su una macchina così ottimizzata, se i gestori nei programmi fossero eseguiti in modo asincrono.
Non capisco il senso del super aggiornamento e della super ottimizzazione dell'hardware della macchina, se i gestori nel programma dell'utente vengono eseguiti a priori in modo sincrono.
Per il terminale stesso e il suo funzionamento interno, forse, l'ottimizzazione descritta sopra è utile. Per i programmi di lotta dell'utente, ne dubito.
Perché l'esecuzione consecutiva dei gestori nel programma utente riduce tutto quel potenziale di qualsiasi macchina super-ottimizzata.
Il problema non è nell'hardware, ma nell'architettura del lavoro interno del terminale.
E ora immaginate quante volte più veloce sarà l'esecuzione dei programmi dell'utente su una macchina così ottimizzata, se i gestori nei programmi saranno eseguiti in modo asincrono.
Non capisco il significato del super aggiornamento e della super ottimizzazione dell'hardware della macchina, se i gestori nel programma dell'utente vengono eseguiti a priori in modo sincrono.
Per il terminale stesso e il suo funzionamento interno, forse, l'ottimizzazione descritta sopra è utile. Per i programmi di lotta dell'utente, ne dubito.
Perché l'esecuzione consecutiva dei gestori nel programma utente riduce tutto quel potenziale di qualsiasi macchina super-ottimizzata.
Il problema non è nell'hardware, ma nell'architettura del funzionamento interno del terminale.
Non ci sarà alcuna accelerazione. Presentate i vostri calcoli, almeno in cifre approssimative, dimostrando un'accelerazione multipla.
Una corsa alle risorse? Creazione incontrollata di nuovi thread? Conflitti per nulla?
Volete dei rallentamenti inspiegabili?
Nel modello basato sugli eventi, tutti gli eventi sono sempre andati in formazione, uno alla volta. Chewed up - masticato.
Il nostro servizio VPS è molto meno incline a questo, sia in termini di architettura che di terminali leggeri senza interfaccia grafica.
Se ci sono dei lag sul vostro servizio VPS, lo prenderete sul serio?
Chi usa il VPS di MQ, per favore condivida i risultati dei seguenti programmi.
Se ci sono dei lag sul vostro servizio VPS - lo prenderete sul serio?
Mi chiedo quante volte devo dirvi che con così tanti (migliaia) thread per un numero limitato di core è assurdo parlare di stabilità dell'allocazione dei quanti di tempo per thread?
È sempre garantito che avrete dei fallimenti su singoli campioni casuali di qualsiasi istruzione, comprese quelle più semplici dell'assemblatore come inc eax. Questo è architettonicamente e a causa delle limitazioni fisiche di "assegnare onestamente i quanti di tempo di migliaia di thread a un piccolo numero di core".
Smettete di essere stupidi e continuate a catturare singoli scoppi per milione di richieste.
Smettete di essere stupidi e continuate a catturare singoli outlier per milione di query.
Ho capito cosa succede con i picchi singoli, grazie per la spiegazione dettagliata. Al momento non stiamo discutendo di SymbolInfoTick, ma di ritardi di un altro tipo, che si verifica su quasi ogni tick.