A really basic couple of questions, part recap for me:
1. How often do we lose a packet do to corruption?
And to me that has two meanings: we have an uncorrectable error, where FEC algorithms etc cannot reconstruct the data and it comes out as corrupted with a bad CRC showing usually, and
(A) that’s it, the bad data is passed up the stack and and in the end the badness of the data is detected by the bad CRC and it gets thrown in the bin, or
(B) corrupted data means a corrupted DTU, if you have some L2 ReTX protocol, G.INP or PhyR (assuming that is roughly the same thing). So then L2 ReTX retransmits that DTU and either (i) all is well, or (ii) it isn’t. The latter means, I don’t know what, a count of n retransmissions or timeout is exceeded, but anyway, the link is just temporarily way way to bad during a longer period of time and the DTU never gets through at all in the end so the L3 packet is bad as it has at least one or more missing or corrupted DTUs in it.
Anyway, with Bi and Bii we have delay due to successful L2 retransmissions or different way of looking at corrupt packets respectively. The DTU size is tricky, needs to be small so it has a good probability of not getting corrupted, keeping the delay down and minimising the amount of resent data, that balanced against not wanting a large number of DTUs per L3 PDU as that number increases the probability of an L3 PDU containing one or more bad DTUs, so equalling a corrupt L3 PDU.
Sound reasonable ?
I’ll have to look again at Kitz’ article about stats for the definitions of some of the counters.
But my question 1 is, what actual numbers of lost-corrupted packets do our Kitizens see in practice?
It varies with the IP packet size and with the noise margin and what’s going in in your world, of course, so the answers for one person will vary according to time and usage.
2) any tips for checking up on this?
Apologies if I have mentioned this before, memory fails me, but if one is running things with noise margins that are quite low, pushing modems a bit too hard, or worse you also have noise that varies cyclically over the course of the day or just have random bursts from nowhere, then that could mean trouble. But I wonder how often this could simply get missed? TCP covers this up, but then there is the performance impact, hurting TCP badly. And there’s also the traffic that is not TCP, stuff without an L4 or L7 retx protocol and that then is really stuffed. And how often would we notice that?
3) have people seen cases where they have seen real data loss which either is or is not compensated for by TCP, so perhaps a total loss, due to corrupted data? Difficult because the modem might resync and DLM might keep this away.
Author
Topic: Really basic question - packet corruption rates (Read 937 times)