| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.