DD>> What's wrong with it?
PE> Same problem I have, David B's modem is failing to connect
PE> to USR's at 28800, whilst connecting to other Netcomms at
PE> 28800.
DD> Shitty phone line?
On who's end? David B connects fine to others at 28800, which
one would imagine absolves his phone line. Considering the
marked worsening changing from 1995-07-18 to 1995-07-05, I'd
say a lot of this is under code control.
DD>>> # 28 Jan 14:57:50 BINK Connect 14400/Arq/V32/Lapm/V42Bis
DD>>> * 28 Jan 14:57:53 BINK Rod Speed (3:711/934.2{at}fidonet)
DD>>> * 28 Jan 14:58:33 BINK Lost Carrier
PE>> And another.
DD>> Problem is at other end
PE> How would you know?
DD> His modem refuses retrains.
So? Even if it was true, are you saying that USRs are designed
to hang up on retrain refusal at V32bis?
PE> No, I expect that David Begley would have managed to get at
PE> least one 28800 connect though, instead of locked it at
PE> 26400 first time every time.
DD> Perhaps the Netcomm rendition of V.34 isn't that compatible with the USR
DD> version (at the higher speed). Netcomm to Netcomm gets 28,800 (so you
DD> say), and USR to USR gets 28,800 (or faster). I remember when the Rockwell
DD> V.FC didn't play well with the USR's version too.
I think this is just as likely as bad phone lines. Given that
there's an incompatibility, who's going to do the line test to
find out what's going wrong, and then get the problem worked
around from BOTH ends? My guess - neither. BFN. Paul.
@EOT:
---
* Origin: X (3:711/934.9)
|