Sounds like it really has no excuse not to be reliable then, at or near 100%. I'll have to sort out the upload side of things too, possibly. Mind you, most users don't have a Firebrick with its upstream rate limiting abilities, and it somehow manages to work for them, presumably. So in fact they would count as "100%" scenario cases then, wouldn't they?
The system I have with the Firebrick's upstream traffic management is very random. As discussed in an earlier thread, I have to guess what the upstream link capacity of each modem is, which changes every time it resyncs, and annoyingly I _have_ to (iirc [?]) put _some_ figure into the Firebrick's config (times three, per each modem) for an upstream rate. And just using defaults (even if possible) wouldn't be a good option for me as the lines don't have anything like equal upstream sync rates ( >500 kbps vs ~ 400 Kbps for example), so I would not get a correct split. Anyway, if I push it too hard, and get my guesswork wrong, then I presume that will make a mess of the outgoing VoIP. I'm not really sure what is supposed to happen in this case, but I just have to hope that it doesn't ever drop the small packets or VoIP-prioritised packets, even in the case where they are at the head of the queue. (Perhaps I need to start using the Firebrick's back-to-back VoIP relay feature for this reason, as opposed to just letting VoIP traffic go straight through as I have it configured now.)