No, I haven't asked about the upstream thing. I just thought that I was asking too much out of it. But recently I realised how many odd things there are. Firstly that two channels work well, and the third doesn't, unless that is just a bad pipe and I should test that next.
Secondly, downstream works superbly well, so it is not that AA's routers are no good, as I'm assuming it is the exact same software just in a 6000-series Firebrick employed in the downstream direction.
Third thing is that if there is some kind of ordering phenomenon - then only with three links, not two - then the effects would presumably depend on the design of the tester or its TCP stack if it is using TCP. Goals for a tester could either be : firstly, realism - be like normal life, so use TCP and perhaps no cheating by using multiple TCP streams to check if a bit more oomph can be squeezed out of the pipe. Or secondly : measure the link, not the software design at the tester, so try and remove all software-design-dependant aspects, so do not use TCP, just keep firing more and more packets down the link until you can't push any more through. Anyway, in this latter case, you might expect different figures depending on TCP vs non-TCP, single vs multiple connections or good stacks that tolerate out-of-order arrival well vs stacks that perform badly.
I thought that networks were supposed to handle out of order packets, but maybe the only do it they don't dig it. Perhaps no-one reacts well, I don't know. Anyway, accusing the FB 2x00 schedulers of causing problems doesn't make sense given that downstream does well, unless it is something to do with having some server o/s as a sulky receiver for upstream tests and in my case Apple iOS or the iOS tester app as a happy receiver for the downstream tests.
All very confusing.