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
| Impostazione | Predefinito | Che cosa cambia |
|---|---|---|
| Periodo | 1 mese (30 giorni) | Giorni richiesti: 7, 30, 90, 180, 365, 730 o 1.825 |
| Granularità | 15 minuti | Timeframe delle barre in cache lette per il backtest: 1m, 5m, 15m, 1h |
| Finestra del drenaggio footprint | 28 giorni | Dimensione di ogni richiesta rithmic_history_ensure |
| Stima footprint | 107 s per sessione mancante | Durata mostrata nel pulsante principale |
| Blocco di barre del server | 9.000 barre | Dimensione di ogni finestra di storico; stima 150 s per blocco |
| Flag di troncamento | < 90 % dei giorni richiesti | coveredSpan 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.
Pagine correlate
- Cache delle barre e pipeline dello storico
- Schermata di preparazione del Replay
- Guida al backtest sui futures
- Glossario: tick replay
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.