Think about how `check_fragment_sizes` should work

[eflumerf]

Right now, check_fragment_sizes works by taking a minimum and maximum value for the Fragment size and making sure that the actual Fragment size is between those two values. It may make more sense to define it in terms of "expected_fragment_size", "chunk_size", and "chunk_tolerance", where the tolerance would default to one or two chunk(s) to account for trigger edge effects.

[eflumerf]

Alternatively, the "expected_fragment_size" could be added to the existing min/max check, and the module could warn/error if there is a large fraction of the Fragments with an unexpected size.

[bieryAtFnal]

Yes, the concept of allowing a little bit of looseness in some checks sounds like something that would be good to think about. An initial feeling is that any less-strict checking should be a separate function or a separate option, though. I'd be uncomfortable if all of the existing fragment size checks suddenly became less strict without thinking through which ones we really do want to be strict.

[eflumerf]

An additional thought: Should we centrally define "standard" Fragment configurations? Many of the integration tests have a copy-pasted block near the beginning to define the expected Fragment sizes, but very few tests actually vary these from one another...