| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | M11F and USR V.34+ |
DH> Since then, some careful politicking has turned up an admission from a DH> senior Telstra manager that there _is_ dynamic line bandwidth sharing DH> (read limiting) hardware now fitted on high traffic trunks and exchanges. DH> FNQ is a low enough traffic area that the equipment hasn't been fitted..:-( RS> Cant be that, coz Dave Drummonds line is JUST as immaculate. One common RS> feature of BOTH that FNQ line and Daves is that they are both within RS> spitting distance of the exchange itself. Bet thats not a coincidence. 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. Or we can say that we dont have ANY evidence of it in measured sessions, and that now that the absolute vast bulk of the inter exchange links are fibre optic, with VAST surplus bandwidth, the proposition is hard to credit. Maybe he actually meant that it can happen at times when for some reason the inter exchange link is temporarily not yet upgraded or something. 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. DH> Doesn't explain my particular hobgoblins. Yes, but you have said it affect ONE line and not another, and that it has a very pronounced asymmetry too. Its MUCH more likely to be some fault condition and not routine dynamic bandwidth sharing at all. 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. If its wideband, it cant be 'dynamic bandwidth sharing 'pinching your bandwidth can it ? 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. Thats a separate issue to whether the overseas calls have always 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. Yeah, it sure smells like some fault rather than being a normal network thing, most obviously because no one else but you is reporting anything remotely like it and its on just one of your lines. Particularly with the extremely pronounced asymmetry in the fault condition. The other people who have problems have problems where, when you look at the ATY11 graph you are amazed they get what they do achieve. Bills got one for an overseas call which has an immense cliff where it is trundling along at 40db and then falls over the cliff to 93 db and stays there at 3150Hz and above. That clearly must be some brickwall filter on that call. DH> Mind you - management doesn't know beans about digital sync - DH> but line capacity planning they -do- know at least a bit about. 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...) Oh sure, he likely believes it. @EOT: ---* Origin: afswlw rjfilepwq (3:711/934.2) SEEN-BY: 711/809 934 @PATH: 711/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™.