I dunno, you just mention something in an aside, then it all blows up in yer face... ;-)


No, it's not just BS; it certainly has its place - but whether this is it is, I agree, highly doubtful!


I dunno. But, rather than worry about it, you'd probably go for error-correcting schemes instead; eg, Reed-Solomon coding (as used on CDs).


You can never tell "right now" - It has to be based on statistics.


Very true - that's why I asked how he intended testing his implementation!


Again, it's down to statistics:
A small packet size means that the framing overhead is repeated more often so has a greater impact on the overall performance, but a smaller packet size means that retransmitting a single packet will have little impact;
bigger packets mean a higher chance of getting an error in a packet, and a bigger impact when the whole lot has to be retransmitted...


Which does tend to argue towards a smaller packet size - as there's less risk of multiple errors "cancelling-out"


It's a matter of balancing the likelihood of an error against the overhead of detecting it, and the overhead of recovering from it.
I'm sure you can do all sorts of statistical analysis - and, no doubt, the big telecom network carriers do. But probably more significant in an 8051 design is sizing things so that everything can be handled with 8-bit numbers!