| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | failed calls |
Rod, at 11:30 on May 17 1996, you wrote to Bill Grimsley... RS> True, the bulldogs results calling Pauls Netcomm was RS> interesting, and Petes even more so since its between Couriers. BG> Yeah, Dave's result more or less eliminates the line BG> quality from the equation, but Peter's was just a BG> one-off, and could have been caused by anything at all. RS> True, but it all adds up to yet more evidence that the USR has a problem. RS> PARTICULARLY when seen between a pair of Couriers when there cant be any RS> possibility of the modem at the other end being a non USR at fault. You'll have seen Pete's retraction by now, where he clearly states that he connected with LAPM, but not V.42bis. I've never even heard of failure to negotiate compression before, so I'd hazard a guess that the remote may have actually had it disabled for some reason. RS> Yes, clearly much rarer between a pair of USRs, BUT RS> this is crucial because ONLY USR code is involved. Irrelevant now that we know the story. RS> Thats another area you never really have grasped, that RS> RATES dont say anything useful about where the fault lies. RS> More legalistically I should have said where *A* fault lies. True. That ordinarily wouldn't have mattered, but as this discussion is about one specific problem, it does change the context considerably. BG> Dunno, if I connect without EC to an M34F at a BG> 50% rate, but to a Viper with only 10% failures, RS> ALL that shows in a proof sense is that it VARYS in rate. RS> We already know that the rate varys with the LINE too, you RS> dud line being heaps worse with a USR V32bis modem calling RS> a Spirit than anyone elses with the SAME pair of modems. BG> it suggests to me that either the USR's code is completely to blame BG> AND the M34F is incapable of overcoming the problem half the time, RS> Or that the USR code is defective, both the M34F and Viper are NOT doing RS> anything out of spec at all in the V42 protocol negotiation phase, and RS> that there are slight differences between them, WHICH ARE PERFECTLY LEGAL What LEGAL differences in the ITU recommendations do you mean? Apart from the various optional bits, ALL modems should be created equal when it comes to the mandatory stuff. Obviously though, they're not. RS> and the defect in the USR code gives a different failure rate between them. You'd just LOVE the USR code to be proved defective, wouldn't you? :) RS> Until you actually determine that the M34F and the Viper are actually RS> doing something that V42 says they should not do, you have no basis RS> whatever for proclaiming that the Netcom is at fault at all on that. I'm claiming nothing, and have even acknowledged that there may well be a problem in the Courier code, just as there may well be a problem with the Rockwell code too. Neither of us are in a position to prove a damn thing though. RS> All you KNOW is that its makes the /NONE connects much more common RS> when called by a USR. But that heaps of other modems call the Netcom RS> without getting any /NONE connects at all, ever. By the same token, I have also mentioned several times before (and had said comments either ignored or deleted completely) that apart from Paul's board (regardless of the modem he uses), I have NEVER had a non-EC connect with ANY other modem anywhere, in either Australia or the US. Not once, not ever. BG> or that both the USR AND the M34F have less than perfect BG> V.42 code, and/or that the Viper's is slightly better. RS> Thats possible, but well down the list of possibilitys, particularly RS> when some modems can call both without EVER seeing a /NONE connect. Or that I can call others with the same perfect result (Paul aside)... RS> And you CANT just change things, like say what does V42 in a modem. No, but you can certainly disable things like the V.42 detect phase, which just happens to solve the problem with Paul anyway (28800/ARQ today). RS> Its these more complex fault situations that really RS> sorts out those who can do it from those who cant. BG> It helps to have the right diagnostic tools too. Most (and I) don't. RS> Yes, but its also possible carefully analyse the evidence and RS> reach useful conclusions even when you dont have the diagnostic tools. In some cases, sure. Not in others though. RS> And that is indeed part of why these are much harder than RS> VCRs where you would normally have had the diagnostic tools or RS> can readily just change bits to see if thats where the problem is. Oi, I've NEVER been a "board-changer"! Sure, some tend to take the easy way out, particularly these days, but I've always repaired everything (apart from PCs of course) to component level, and can't even remember having changed a part unless I knew for a fact that it was actually fucked. You forget that I work on my own, and am not in the financial position of being to buy a $60 IC simply on spec, not when I can't take it back if that wasn't the problem. BG> It may also be relevant that these 28800/NONEs BG> have only happened with Rockwells, RS> I doubt it, more likely that its just that they are much more common, RS> particularly when it has been seen between a pair of Couriers too. It hasn't, so the original comment is still valid. BG> but I'm not prepared to suggest that there's an inherent problem BG> with their chipset, when it could just as easily be USR's problem. RS> If fact HAS to be if seen between a pair of Couriers, Pity it wasn't (bet that hurts too). :) RS> and clearly can be fixed with a Sportster rom change. To Rockwells, sure. BG> Dunno, but consider this. Is it not possible that BG> because the USR uses generic DSP technology, they are BG> in a far better position to adhere to the ITU specs to BG> the letter, and that Rockwell may have strayed a touch? RS> Nope. It's definitely not possible, eh? Yours is a completely silly comment with no basis in fact, and speaks volumes for your attitude towards USR. RS> Makes no difference if you use a masked rom for the code except RS> in the sense that its easier to change and fix a wart with a soft modem. Of course it makes a difference. If you buy a Rockwell with a buggy chipset (and those who bought any of the first 19 revisions most certainly did), tough shit, there's fuck all you can do about it. Not so with the Courier series, where ALL of the code can be replaced in around 60 seconds. BG> It wouldn't be the first time, you know. Look at the BG> V.FC debacle, where Rockwell wrote the specs, USR followed BG> them to the letter, yet Rockwell kept changing them! RS> Well, that was the story from USR. USR has a HELL of a capacity RS> for blaming EVERYTHING on someone else. Oh crap. Somebody in Oz_modems once actually posted a message from the Rockwell Corporation themselves, which specifically stated that there were several updates to the V.FC code in their earlier revision chipsets. RS> I havent EVER seen them actually come out and say 'sorry, we fucked that up RS> pretty badly, this SDL fixes that fuckup', they ALWAYS blame it on someone RS> else if they can possibly find someone else to blame. Says nothing useful about Rockwell's diabolical V.FC fuckups though, does it? BG> I'm not suggesting that's true, but it IS a possibility. RS> Not when its seen between a pair of USRs Bill, there is NO ONE RS> that you can claim is following the ITU specs worse than you are. I wish you'd learn to speak correct English, as I have no idea what that is supposed to mean, but suffice it to say that the problem has NOT been seen between 2 Couriers after all, so your claim is crap. RS> AND *YOU* yourself saw HEAPS of those with the Sportster with the RS> less than the best rom calling Pauls Courier. The aint no one who can RS> possibly have fucked up the ITU specs but USR in that case is there ? In THAT case, there was a definite improvement when calling others with dodgy lines, but you can't absolutely claim that USR didn't simply upgrade their code to cope with inherent problems with the Rockwell code. In the absence of any definitive evidence, you'd be mad if you did. BG> If it was Rockwell, I'd say we were fucked, but at least I feel that BG> with USR, we at least have a chance that something will be done about it. RS> We'll see. 6 new SDLs in 18 months proves to me that they ARE doing something positive. How many FREE chipset upgrades have Rockwell offered during the same time? Regards, Bill --- Msgedsq/2 3.20* Origin: Logan City, SEQ +61 7 3200 8606 MO (3:640/305.9) SEEN-BY: 640/305 711/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™.