RS> AND we have LOTS of duplicated session stats from people
RS> calling Pauls system with a variety of modems at his end,
RS> with no evidence of ANY real variability in the stats at
RS> all, which is a bit hard to reconcile with the story about
RS> 'dynamic line bandwidth sharing', particularly as his end in
RS> Sydney presumably qualifys as 'high traffic trunks and exchanges'

DH> Fair enough.  Then we take the "all" with the same size grain
DH> of salt as we do the other information packages ex Telstra.

RS> Or we can say that we dont have ANY evidence of it in
RS> measured sessions, and that now that the absolute vast
RS> bulk of the inter exchange links are fibre optic, with
RS> VAST surplus bandwidth, the proposition is hard to credit.

DH> Nope.  We had the information from the programmer,

I said evidence in measured sessions. The problem with anything
someone like that says is that the story may have got garbled.

DH> then we logged the interference on each trunk exactly
DH> when the information was leaked that it would be
DH> trialed. It's long past being able to deny.

Now try explaining why we cant see any evidence of it in measured sessions.
You certainly can see quite visible bandwidth variations on OS calls tho.

Or why it only affects ONE of your lines and why no one else is reporting
anything like the dramatic effect you are getting yourself. Doesnt hang
together logically that its a fundamental characteristic of the network.

DH> Vast surplus in a pig's eye.

Thats what there is on the fibre optic cables between
exchanges, particularly between say exchanges in Sydney.

DH> They know something we don't.

Sounds more like a conspiracy theory to me if we cant measure the effect.

RS> Maybe he actually meant that it can happen at times when for some reason
RS> the inter exchange link is temporarily not yet upgraded or something.

DH> This could well be.  If I were designing a link, and had the capability of
DH> putting in such emergency measures for negligible cost, I certainly would.

Sure, I would too. BUT you have been running the line for years that
they are deliberately crippling the bandwidth to shaft us on purpose
over the whole network, and have been trialing it and hoping we wont
notice. I havent seen any evidence for THAT happening, just evidence that
you may indeed see some temporary kludging in the process of upgrading.

RS> And a careful look at the Courier ATY11 line probe stats shows no
RS> sign of that claimed bandwidth limitation at all. What you can see
RS> with the worse lines like Bill Grimsleys home line and Poes is a
RS> rather pronounced slope of the entire bit of the curve which is
RS> horizontal with Daves, more loss at higher freqs, JUST what you would
RS> expect to see due to the physical cable run between the exchange and
RS> the modem itself when its rather long, rather elderly, and thinner wire.

DH> That doesn't wash - because the cable doesn't change between 2 AM and 2 PM.

I didnt say that was the problem with YOUR line, I said that there
is no evidence on OTHER lines of any real variation in bandwidth
that cant be explained by the cable itself. In other words no
evidence on THEIR lines of any 'dynamic line bandwidth sharing'.

DH> The error rate changes by three orders of magnitude
DH> in the same time - and it's locked into "event" bursts.

Yes, that line has some problem. You dont have the evidence that
its due to 'dynamic line bandwidth sharing' tho, particularly when
its just the error rate that changes. V34 is SUPPOSED to be able
to handle quite pronounced variations in bandwidth transparently.

It smells rather more like a fault than just bandwidth sharing.

DH> Doesn't explain my particular hobgoblins.

RS> Yes, but you have said it affects ONE line and not another, and that
RS> it has a very pronounced asymmetry too. Its MUCH more likely to be
RS> some fault condition and not routine dynamic bandwidth sharing at all.

DH> That's possible.  It's my Telstra engineering contact's white hope.

It aint just a white hope, its what all the available evidence points to.
Particularly when no one else thats making lots of V34 calls is seeing it.
Particularly the very pronounced asymmetry in the forward/backward stuff.

DH> But a fault that tracks load level?

There have always been faults that do that, any cross channel stuff does.

DH> OTOH, the "one line and not the other" is significant, and
doesn't fit the
DH> suspicion.  Especially since it's reputed to be on the same inbound rack.

Yeah, thats what I meant, very unlikely to not be significant.

Could even be a design fault in that stuff if its relatively new.

DH> I get sudden disconnects - classical effects that used to plague
DH> V.FC in the early days.  The line checks out wide band and low noise.

RS> If its wideband, it cant be 'dynamic bandwidth
RS> sharing 'pinching your bandwidth can it ?

DH> It isn't wide band when the fault's on.

I'm sure you said the measured bandwidth doesnt change.
The overall performance of the session turns obscene tho.

DH> When the full bore fault is present, it won't
DH> handle 4800  _but_ signal still gets through.

Yes, but thats not bandwidth measured with the ATY11 is it ?
If they really are just doing 'dynamic bandwidth sharing' in
times of a high volume of traffic, thats gunna be visible on
the ATY11 bandwidth measurement. And it AINT, so it cant be that.

RS> The other people who have problems have problems where, when you
RS> look at the ATY11 graph you are amazed they get what they do achieve.

RS> Bills got one for an overseas call which has an immense
RS> cliff where it is trundling along at 40db and then falls
RS> over the cliff to 93 db and stays there at 3150Hz and above.
RS> That clearly must be some brickwall filter on that call.

DH> Glad I don't have to cope with THAT one.

Interestingly it did manage a 16800 line speed tho. Pretty decent.
@EOT:

---