Riempire uno storico lungo per i backtest: drenaggio footprint o barre del server

Il pannello del backtest automatico legge la copertura della cache per il contratto, la granularità e il periodo scelti, poi propone due scaricamenti per le sessioni mancanti: il drenaggio footprint (ogni scambio con il suo lato aggressore, ricostruito in bid × ask) oppure le barre del server, più rapide ma senza livelli. La copertura è contata in sessioni di trading, a cinque ogni sette giorni.

Senzoukria · Documentazione · Aggiornato a settembre 2026


Dove trovarlo

Dove
Replay → Backtest automatico → scheda di copertura sotto Periodo e Granularità
Periodi
1 settimana, 1 mese (predefinito), 3 mesi, 6 mesi, 1 anno, 2 anni, 5 anni; granularità 1 minuto, 5 minuti, 15 minuti (predefinito), 1 ora
Due pulsanti
«Scarica lo storico footprint ({dur})» (principale) e «Scarica lo storico mancante ({dur})» (secondario, barre del server)
Testo di copertura
«{n} sessioni in cache su {n} richieste — ne mancano {n}. Il backtest può partire subito su ciò che esiste, ma il risultato coprirà solo quella finestra.»

Che cosa fa

Cambiare contratto, granularità o periodo rilegge la cache (cache_coverage) senza alcuna chiamata al broker. I giorni richiesti sono convertiti in sessioni a 5/7, i nanosecondi coperti diventano sessioni coperte e la differenza è il numero mancante. Quando non c'è nulla in cache la scheda dice «Nulla in cache per {symbol} a {tf}. Apri questo contratto nel grafico a quella granularità: lo storico si riempie da solo e resta disponibile in seguito.»

Il drenaggio footprint chiama rithmic_history_ensure su finestre di 28 giorni, con la finestra più vecchia per ultima, passando il tick size del contratto. La sua stima è di 107 secondi per sessione mancante, mostrata nel pulsante. Ogni finestra riporta le barre recuperate, gli intervalli saltati come negati e quelli falliti; un backend occupato fa saltare la finestra senza contarla come fallita. Questo percorso porta il bid × ask per prezzo ed è quello di cui ha bisogno una strategia che legge gli squilibri livello per livello.

Il percorso delle barre del server chiama rithmic_fetch_history_batch con blocchi pianificati a 9.000 barre ciascuno (23 ore per sessione, 5/7 sessioni al giorno), inviati 8 finestre per lotto e 2 lotti in volo. È più rapido, ma le barre portano solo OHLC, volume e delta: «Le barre del server portano OHLC, volume e delta, ma nessun livello footprint.»

Impostazioni e stime

Parametri che modellano la scheda di copertura e i due scaricamenti
ImpostazionePredefinitoChe cosa cambia
Periodo1 mese (30 giorni)Giorni richiesti: 7, 30, 90, 180, 365, 730 o 1.825
Granularità15 minutiTimeframe delle barre in cache lette per il backtest: 1m, 5m, 15m, 1h
Finestra del drenaggio footprint28 giorniDimensione di ogni richiesta rithmic_history_ensure
Stima footprint107 s per sessione mancanteDurata mostrata nel pulsante principale
Blocco di barre del server9.000 barreDimensione di ogni finestra di storico; stima 150 s per blocco
Flag di troncamento< 90 % dei giorni richiesticoveredSpan marca il risultato come troncato quando le barre coprono meno del 90 % del periodo

Come usarlo

  • Scegli contratto, granularità e periodo, poi leggi la riga di copertura prima di lanciare: un backtest può girare su ciò che esiste, ma il suo risultato copre solo quella finestra.
  • Preferisci il drenaggio footprint quando la strategia legge squilibri o volume livello per livello; metti in conto le ore che annuncia.
  • Usa Annulla per fermare uno dei due scaricamenti; quanto è già arrivato viene conservato, e rilanciandolo si riempie il resto.
  • Osserva la riga di stato: «Drenaggio tick per tick — finestra {done} di {total}, {bars} barre finora» oppure «Scaricamento — blocco {done} di {total}, {bars} barre finora».

Verdetti e trappole

  • denied: il broker ha risposto rp_code 13 («permission denied»). Le barre storiche sono un'autorizzazione del broker, non un'impostazione dell'applicazione; i tick storici possono comunque funzionare, ed è ciò che usa il replay manuale.
  • silent: login accettato, nulla inviato su ogni finestra. O l'archivio non arriva così indietro, oppure il plant dello storico è giù; riprova a mercato aperto.
  • empty: il broker ha risposto ma non ha servito barre per questa finestra; il suo archivio potrebbe non risalire così indietro per questo contratto.
  • Drenaggio tick con codici: «Il broker non ha restituito tick e ha risposto: {codes}. Il replay dei tick storici potrebbe non essere abilitato su questo conto.»
  • I dati storici sono serviti e fatturati dal tuo broker o fornitore dati secondo il tuo conto; l'applicazione non può estendere un'autorizzazione.

Questa pagina in altre lingue

Domande frequenti

Perché vengono proposti due scaricamenti, e quale scegliere?
Non portano gli stessi dati. Il drenaggio footprint ricostruisce il bid × ask per prezzo da ogni scambio ed è necessario per le strategie che leggono i livelli; le barre del server sono più rapide ma non hanno livelli. Per questo il drenaggio footprint è l'azione principale.
Perché la stima parla di ore?
Sono 107 secondi per sessione mancante, e di proposito: annunciare un tempo troppo breve spingeva a interrompere scaricamenti che stavano per finire.
Lo scaricamento è finito ma la copertura non è cambiata?
La copertura viene riletta dopo ogni esecuzione. Se non si è mossa, leggi il messaggio sotto i pulsanti: blocchi parziali, un codice di rifiuto o un archivio vuoto lo spiegano.