TIP: Click on subject to list as thread! ANSI
echo: aust_modem
to: Rod Speed
from: Dave Hatch
date: 1996-04-23 18:06:28
subject: M11F and USR V.34+

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 measured sessions,
RS> and that now that the absolute vast bulk of the inter exchange links are
RS> fibre optic, with VAST surplus bandwidth, the proposition is hard to 
RS> credit.

Nope.  We had the information from the programmer, then we logged the
interference on each trunk exactly when the information was leaked that it
would be trialed.   It's long past being able to deny.

Vast surplus in a pig's eye.  They know something we don't.

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.

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

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 rather
RS>> pronounced slope of the entire bit of the curve which is horizontal
RS>> with Daves, more loss at higher freqs, JUST what you would expect
RS>> to see due to the physical cable run between the exchange and the
RS>> modem itself when its rather long, rather elderly, and thinner wire.

That doesn't wash - because the cable doesn't change between 2 AM and 2 PM.
The error rate changes by three orders of magnitude in the same time - and
it's locked into "event" bursts.

DH>> Doesn't explain my particular hobgoblins.

RS> Yes, but you have said it affect 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.

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

But a fault that tracks load level?

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

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 ?

It isn't wide band when the fault's on.  When the full bore fault is
present, it won't handle 4800  _but_ signal still gets through.

RS>> You can however clearly see a completely different effect
RS>> on the calls to the US, which do appear to be more likely
RS>> to be due to that sort of thing on bandwidth.

DH>> Word currently is that they've "fixed" the fax processors.

RS> Thats a separate issue to whether the overseas calls have always
RS> been measurably different to the ones within Australia tho.

DH>> I've been deluging Frank Nitzche with logs, complete with bandwidth
DH>> measurement sets.  The "fault present" condition is a
horror.  We'll see.

DH>> Could well be some digital sync problem.

RS> Yeah, it sure smells like some fault rather than being a normal network
RS> thing, most obviously because no one else but you is reporting anything
RS> remotely like it and its on just one of your lines. Particularly with
RS> the extremely pronounced asymmetry in the fault condition.

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 cliff where it is
RS> trundling along at 40db and then falls over the cliff to 93 db and stays 
RS> there
RS> at 3150Hz and above. That clearly must be some brickwall filter on that 
RS> call.

Glad I don't have to cope with THAT one.   Bad enough into 8:8/0 in Chicago.

DH>> Mind you - management doesn't know beans about digital sync -
DH>> but line capacity planning they -do- know at least a bit about.

RS> Yeah, it can apparently be a problem convincing them its the problem.

DH>> I tend to believe that the report was at least
DH>> believed by the source. (Credibility level??? well...)

RS> Oh sure, he likely believes it.

That's true enough.  Gives one the feeling of peering through a fog,
looking for a black cat in a coal cellar at midnight, and not a candle to
use...

 Dave Hatch

--- Msgedsq 3.20
* Origin: DealBlue Support BBS (3:711/808)
SEEN-BY: 50/99 78/0 620/243 623/630 624/300 711/401 409 410 413 430 808 809
SEEN-BY: 711/899 932 934 712/515 713/888 714/906 800/1 7877/2809
@PATH: 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.