Simula / sviluppa_a_testing_strategy per fattori che potrebbero causare lo stesso algoritmo di produrre risultati diversi nei sistemi distribuiti

4

Questa è una domanda puramente accademica

Contesto:

Sto lavorando con alcuni algoritmi che hanno lo scopo di arrivare a un consenso nei sistemi distribuiti. Intendevo affrontare gli errori bizantini con questi algoritmi. Per questo ho implementato diversi algoritmi pubblicati nei documenti IEEE e ho bisogno di una piattaforma per testare questi algoritmi. Volevo testare il merito degli algoritmi esistenti. Per questo ho implementato migliaia di Contenitori Linux sul mio sistema e ora voglio passare il messaggio tra di loro o dire simula il mio sistema distribuito. Ma la domanda è che i dati che stanno scorrendo devono avere errori . Questa è la genesi di questa domanda. Perché ho bisogno di qualcosa di più sofisticato di RNG è che dovrò attribuire una certa credibilità al mio lavoro. Voglio che affronta alcuni errori di generazione di applicazioni nel mondo reale piuttosto che correggere i guasti che io stesso ho generato in un algoritmo.

Quindi, ho bisogno di simulare i fattori che provocano errori bizantini.

OR, per citare FrustatedWithFormsDesigner: I need to develop a testing strategy that will have a deliberate number of faults to test fault-handling

Per riepilogare:

Supponiamo che io stia eseguendo un programma in un ambiente distribuito, quali sono i fattori che potrebbero finire per generare errori bizantini ed è possibile per me inculcare questi fattori nella mia simulazione e in che modo?

Quindi, quello di cui ho bisogno è:

Un programma che farà un piccolo no. di errori ogni tanto, e non dovrei sapere quali errori ha commesso e quando.

Non ho bisogno di fare più errori in un set (esecuzione dell'algoritmo), ma piuttosto di fare (diciamo) 10.000 esecuzioni del programma, e ne ho bisogno per commettere errori 2000 volte. .

Molto importante, devo essere ottimista che non ci siano più di (1/5) n errori, dove n è il no totale. dei risultati generati utilizzando il programma.

I risultati di cui sto parlando possono essere qualsiasi cosa che sia quantificabile e verificabile, come ad es. una serie di valori.

Fai qualcosa del genere:

1for(int i=0; i<10000; i++)
2   //one fifth of the times put garbage in the array using random function!!
3   for (int j=0; j<5; j++)
4      array[j]=j;

l'utilizzo di un RNG nel passaggio 2 in nascondi dove l'errore è presente è troppo semplicistico, banale e non reale sufficiente.

Pensavo di poter usare un algoritmo costruito attorno a una funzione matematica che è destinata a fallire 1/5 delle volte, ma non riuscivo a pensare a nessuna.

P.S. Per favore, dimmi se hai bisogno di più dati per capire il problema.

    
posta Chani 10.01.2012 - 14:50
fonte

4 risposte

4

Ci sono alcuni diversi tipi di errori che possono verificarsi in un sistema distribuito:

  1. Sensore di rumore
  2. Messaggi eliminati
  3. Messaggi duplicati
  4. Messaggi danneggiati

Tutti questi possono verificarsi in isolamento o come "esecuzione" di diversi errori dello stesso tipo in una riga.

Il modo migliore per simulare il rumore del sensore è con una distribuzione gaussiana, che ottieni alimentando un RNG distribuito uniformemente in un Trasformazione di Box-Muller . Questo produrrà valori che sembrano più "reali", di solito solo un po 'spenti, ma ogni tanto un po' di tempo.

Per gli altri, basta usare un normale RNG per causare l'errore con una certa probabilità. Il trucco sta nel calcolare la probabilità individuale, quindi non è probabile che tu superi il 20% di errori allo stesso tempo. È qui che la mia matematica si arrugginisce, ma probabilmente potresti risolverlo in stile monte carlo. Imposta la probabilità di un guasto su un determinato valore, quindi esegui la simulazione 10.000 volte per vedere se ottieni mai più del 20% in una volta, quindi aggiusta la tua probabilità individuale di conseguenza. Non si sarà in grado di garantire senza escludere più errori di quello, ma è possibile rendere sufficientemente piccola la probabilità. Dipende se vuoi una simulazione realistica o un test approfondito delle condizioni al contorno, perché nella vita reale non puoi garantire neanche meno del 20%.

    
risposta data 10.01.2012 - 16:39
fonte
2

Ci sono due approcci:

  • non casuale: usa un contatore e ogni 5a corsa dice al software di fare un errore. Funzionerà perfettamente, ma sarà prevedibile.
  • Casuale: usa il metodo / comando / funzione a caso nella tua lingua preferita per scegliere un numero compreso tra 1 e 5 inclusi. Se è 1, allora comunichi al software di fare un errore. Per un numero basso di esecuzioni, potresti avere troppe o troppe rotte con errori. Per un numero elevato di corse ti avvicinerai al numero previsto. Non sarai in grado di anticipare quali piste avranno errori.
risposta data 10.01.2012 - 15:44
fonte
2

Il problema è che vuoi che i guasti si verifichino in modo casuale e con qualcosa come una distribuzione uniforme, ma vuoi un hard cap?

Se vuoi che k eventi di n tentativi, casualmente, crea un evento con una probabilità di k / n. Ora, fai di nuovo questo: vuoi k o k-1 eventi di n-1 tentativi, a seconda che tu abbia o meno ottenuto l'evento. Continua fino a quando il denominatore (cioè il numero di tentativi rimanenti) raggiunge zero. Una volta che hai k eventi, il numeratore sarà bloccato a 0, quindi non ne ottieni più. La distribuzione sarà (IIRC) uniforme.

    
risposta data 10.01.2012 - 21:21
fonte
1

Qui non offri molte informazioni e sembri contraddirti più volte. Per ripeterti la tua domanda - quindi se mi dirigo nella direzione sbagliata, almeno saprai quale direzione sbagliata ho guidato - vuoi eseguire un breve programma di 10.000 volte e fargli dare una risposta sbagliata in 200 sessioni. Questo dà un tasso di errore del 2%, e anche nei guasti solo uno (forse su 10.000 numeri di output) è sbagliato.

Un generatore di numeri casuali farà questo per te. Decidi all'inizio di una corsa se deve essere buono o cattivo. Quindi selezionare un numero di uscita a caso e dargli un valore negativo. (Non vuoi controllare ogni numero o potresti avere meno di o più di un numero cattivo nella corsa.)

Ora il vero trucco è che un generatore di numeri casuali inizia con un seme, che di solito proviene dall'ora del sistema. Se arriva l'ora del sistema, diciamo centesimi di secondo anziché microsecondi, e il tuo programma funziona molto velocemente, la maggior parte delle tue esecuzioni avrà numeri casuali identici. In breve, i tuoi numeri non sono casuali. Avrete bisogno di salvare il seme da una corsa e inserirlo nella successiva, presumibilmente con un file su disco. (O distanzia le tue corse in qualche modo.)

Non ho idea del motivo per cui vuoi farlo, ma potresti decidere di fare in modo che i tuoi fallimenti arrivino a ondate. Potresti dividere le tue esecuzioni in gruppi di 1000, la metà dei quali non avrebbe fallimenti e l'altra metà avrebbe mediamente 40 fallimenti ciascuno. Questo potrebbe attirare i tester in un falso senso di sicurezza, o farli diventare così annoiati da non guardare quando iniziano le riprese. Ovviamente, se questo è ciò che stai stai cercando di fare, dovresti inventarti schemi molto più diabolici.

    
risposta data 10.01.2012 - 16:35
fonte

Leggi altre domande sui tag