IS> Hmmm, that doesn't get around the problem exhibited by some
 IS> modems (notably
IS> around here a large rack of Netcomm M34s) in timing out too fast in V.42
IS> negotiation (thus obtaining non-EC connects, which I seem to remember was
IS> Michael's problem, no?) because they accept a higher bit error rate as
IS> worthy of granting (say) a 28800 connect than the calling modem does.

 BG> It was my problem too, when calling Paul Edwards' M34F, and
 BG> to a slightly lesser extent, his Viper (both
 BG> Rockwell-based), although in both cases, the remedy was
 BG> extremely simple; disabling the Courier's V.42 detect phase
 BG> (i.e. forcing a non-negotiated LAPM connect).  One of the
 BG> fellows who writes the Courier's code for USR (Lewin's
 BG> mate, Joe Frankiewicz :)) has indicated that it's actually
 BG> a Rockwell problem, but as it's easily rectified, who cares?

Yes, and it's true that it's a pretty safe setting for calling most modern
modems, unless they're setup for MNP.

IS> The solution for both my DPX596 and the Motorolas was to set them so that
IS> they'd go for a lower speed (say one or two 2400bps steps)
 IS> for a given line
IS> quality, thus quickly negotiating a lower speed, but getting error
IS> correction with these modems.  Apart from the link
 IS> reliability, the overall
IS> throughput is higher at say 26400, probably even 24000, with EC than at
IS> 28800 without.

 BG> Are your modems incapable of "forcing" non-negotiated LAPM
 BG> connects, then?

Mine can, and I expect the Motorola can, too.  However, with some modems
that didn't seem to help (notably an older Maestro 144FM on (then) really
crappy lines, whereas demanding better sig. qual. (or if you like, lower
BER) per speed did.  Of course it can be said that the default BER policy
on our modems was set too low, but at least it's adjustable :)

I may be misremembering, but I believe disabling V.42 detect phase was one
of the first thinngs my friend tried on the Motorola Lifestyle.  It was a
fair old struggle till we tried playing with the BER setting, which worked
straight away, and I've heard no complaints since.  It's probably a poor
default for the Motorola, really, as a few people have run into this.  I
also note the default for my DPX596 changed re this, one firmware upgrade
along the way.

IS> It's possible that the Netcomms have a setting that will either be less
IS> aggressive about it, or (more likely, being Rockwells)
 IS> perhaps allow longer
IS> for EC negotiation - but I've not been able to find out if that's so, as
IS> yet.

The more I think about the way this works, and on skimming through V.42
(which is pretty coy about recommending any EC negotiation timeouts, though
750 mSec seems to be the minimum) the more I feel it's a timeout that's too
aggressive with these.  Going soon for the lower rate at a given BER just
gets in inside that timeout, whereas another round of negotiation may be
considered outside the timing limits of the M34s etc (still following my
nose on this ..)

 BG> The only thing which comes to mind is the Tx level, which I
 BG> understand can be physically adjusted to a specific
 BG> (higher) level, and I wouldn't be at all happy using that
 BG> as a fix for that particular fault anyway.

No, I doubt that would help, unless it overcame some particular mismatch
with one's particular exchange line card.  Reducing it might be likely to
do as well, in that case, but I'm not sure the settings that appear to
modify Tx levels are really applicable to data (as opposed to Fax) anyway,
given that Austel compliance supposedly means this isn't adjustable for
data (well, not to any higher than -10dBm, anyway).

BG> There isn't one.  All you can do is try disabling the higher symbol rates
BG> (say 3429 and 3200, for example) for a lower connect speed.

Actually, that's a pretty fair solution, as you mentioned to Michael,
unless of course you can specify both minimum AND maximum rates, as it
seems you can on the V.34 Rockwells (and as V.34 certainly caters for).

You were asking about maximum data rates at different symbol rates .. this
is gleaned from V.34 (1994).  Not sure how V.34 (1996) will change this
picture for 31200 and 33600 bps:

Symbol rate (/sec):   2400!   2743    2800    3000!   3200!   3429
Maximum rate (bps):  21600   24000   24000   26400   28800*  28800*
                    (21800) (24200) (24200) (26600) (29000) (29000)*

! = V.34 mandatory symbol rates - others are optional.
* = wonder if only 3429 will get to 31200 as well as 33600 in V.34 (1996)?
(figures in brackets indicate use of the auxilliary 200bps channel as well,
which is not implemented, as far as I've heard(?), on most V.34 modems)

Just for interest, amidst the ongoing baud/bps confusion saga, there are
also two _carrier_ frequencies used at each symbol rate (except, here,
3429), shown rounded to the nearest integer:

Symbol rate (/sec):   2400    2743    2800    3000    3200    3429
Low Carrier (Hz):     1600    1646    1680    1800    1829    1959
High Carrier (Hz):    1800    1829    1867    2000    1920    1959

IS> That surprises me, on a modem of that supposed quality.  Ok,
 IS> the Rockwells
IS> don't appear to have any user-accessible BER adjustments
 IS> either, but still

 BG> Jeeze, Ian, we live in a modern technological society,
 BG> where everything these days is done automatically, yet you
 BG> appear to want to return to the bad old days of manually
 BG> setting things?  Bloody hell, is nothing sacred?  :)

:)  Well, setting V.42 detect phase off might seem intuitive to you, but it
confuses the hell out of some people, particularly as it sounds a bit like
"turning off V.42" which is about the opposite of what it does. 
I've recently had to advise someone with a Banksia MX-6 to set &Q5S48=0
to accomplish that, or \N4, which (maybe) does the same.  It defaulted to
&Q9, rather unusually.

 BG> Realistically though, isn't that the whole point of the
 BG> newer fancy protocols, such as V.34, where automation is
 BG> reaching dizzying new heights (or would have done, had the
 BG> Dynalink's BTLZ worked properly) ?

Getting the initial V.34 connect is part of the problem - then making sure
to get an error-corrected link (so it will actually WORK) is something
else.  I wouldn't believe too readily that 'plug in and forget' modeming is
here yet :)

IS> .. it's my theory (totally by smell) that Netcomm and maybe some other
IS> modem chip packagers are not testing their modems nearly
 IS> adequately on the
IS> less than perfect lines that many of us enjoy, due to distance from
IS> exchanges, water in the works, bad line connections, etc,
 IS> with enough other
IS> makes of modem, thus are setting their BER / line rate selection policy
IS> toward only better lines.

 BG> I suspect the above to be much closer to fact than a theory, too.

I know the original Maestro V.32s were very well tested in that department,
as the Maestro HQ, then at Kincumber suffered from poor to dreadful lines. 
Nothing short of widespread field testing will really work, in-house line
impairment test rigs notwithstanding.

IS> If true, this is counter-productive.

 BG> So what else is new, Ian?  Now that V.34 modems can be
 BG> purchased brand new in the United States for not much more
 BG> than US$100 (and around A$150 here), the manufacturing cost
 BG> per unit is now so low that it's probably cheaper for them
 BG> to ignore production line QA altogether.

We were talking about a problem more exhibited by (supposedly) higher-end
jobs like Netcomm M34s though.  [down, Dave, down, good boy! .. :]

IS> Going sooner to a lower rate will achieve higher connectivity with more
IS> modems on poor lines, without in the least sacrificing
 IS> connect rates on the
IS> best lines.  Again, 24000/Arq is a hell of a lot better than 28800/None,
IS> let alone dropped connects.

 BG> Quite so, although it's interesting to recall that when the
 BG> early V.FC modems were a bit aggressive during negotiation,
 BG> everybody complained about their dropped carriers, yet now
 BG> that most V.34 modems have gone the other way (like the
 BG> USRs), they're all bitching about their lowly 24000 or
 BG> 26400 connects.  There's just no pleasing some people, is there?

No indeed.  Personally I'd rather be able to bitch about 'why can't I
always get top speed?' than 'why does my modem often drop carrier?' ..

IS> 

 BG> Feel better now?  No, I thought not...

Actually, yes.  Gradually getting a bit of a handle on this one, maybe ..

Cheers, Ian

--- MaltEd 1.0.b5