This is a Purely Academic QuestionContext:I am working with some algorithms which are meant to arrive at a consensus in distributed systems. I intended to tackle Byzantine faults with these algorithms. For this I have implemented several algorithms published in IEEE papers and need a platform to test these algorithms. I wanted to test the merit of existing algorithms. For this I implemented thousands of Linux Containers on my system and now i want to do message passing between them, or say simulate my distributed system. But the question is the data that is flowing must have faults. This is the genesis of this question. Why I need something more sophisticated than RNG's is that I will need to attach some real credibility to my work. I want it to tackle some real world application generating faults rather than just fix the faults I myself generated in an algorithm. So, I need to simulate the factors that result in Byzantine faults. OR, to quote FrustatedWithFormsDesigner: I need to develop a testing strategy that will have a deliberate number of faults to test fault-handlingTo Summarize:Say I am running a program in a distributed environment, then what are the factors that might end up generating Byzantine faults and is it possible for me to inculcate these factors in my simulation and how?So, what I need is: A program that will make a small no. of mistakes every now and then, and I should not know what mistakes it has made and when. I do not need it to make multiple mistakes in one set(run of the algorithm), but rather I plan on making (say) 10,000 runs of the program, and I need it to make mistakes 2000 times ..Very importantly, I must be sanguine that there are no more than (1/5)n mistakes, where n is the total no. of results generated using the program. The results that I am talking about here can be anything that is quantifiable and verifiable, like eg. an array of values. Doing something like this: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;using a RNG in step 2 to hide where the fault is present is too simplistic, trivial and not real enough. I thought I could use some algorithm built around some mathematical function that is bound to fail 1/5th of the times, But I could not think of any. P.S. Please tell me if you need more data to understand the problem.
Simulating/developing_a_testing_strategy for factors that might cause the same algorithm to produce different results in Distributed Systems
algorithms
There are a few different kinds of faults that can occur in a distributed system:Sensor noiseDropped messagesDuplicate messagesCorrupted messagesAll of these can occur in isolation, or as a run of several failures of the same type in a row.The best way to simulate sensor noise is with a gaussian distribution, which you get by feeding a uniformly distributed RNG into a Box-Muller transform.  This will produce values that look more real, by usually being only off by a little bit, but every once in a while off by a lot.For the others, you just use a regular RNG to cause the fault with a certain probability.  The trick is figuring out the individual probability so you aren't likely to exceed 20% faults at the same time.  This is where my math gets rusty, but you could probably solve it monte carlo style.  Set the probability of one fault to a certain value, then run your simulation 10,000 times to see if you ever get more than 20% at once, then adjust your individual probability accordingly.  You aren't going to be able to guarantee it without flat out disallowing more faults than that, but you can make the probability sufficiently small.  It depends if you want a realistic simulation or a thorough test of boundary conditions, because in real life you can't guarantee less than 20% either.