PE> 1. We get a 28800 connect on a noisy line.
PE> 2. We get a lot of noise on the line, so the modems decide to
PE> retrain immediately
PE> 3. It takes more than 0.75 seconds for the retrain to happen
PE> 4. By then, the time has expired for a V42 connection.

IS> That's entirely possible.  If you're seeing this happen much, you (and/or

 PE> We are.  Still collecting stats, but it's something like 40%
 PE> failed calls (28800, no EC).

Hmmm.  What are the lines like - for both ends - as far as other calls go?

IS> the other person) will likely do better by adjusting the
 IS> modem to demand a
IS> higher quality signal (lower bit error rate) for a given
 IS> negotiated speed.

 PE> Suggestions for the USR Sportster V.34 or Netcomm M34F?

Don't know either's command set - as I think I mentioned, I was involved in
finding the solution to virtually exactly the same problem from a Motorola
Lifestyle to a rack of M34Fs at the uni here, but you need (at least)
manuals.

IS> As long as fallforward isn't disabled, the modems may shift back up later
IS> anyway, if line conditions are mutually deemed to have improved.

 PE> Sounds fair.

Well, we got the same sort of thing happening to my DPX596 from an oldish
Maestro 144FM, on a (then) very poor line.  Greg wound up setting some
obscure thing (%M?  %G?  can't remember) and running %E1.  Even with %E1,
the Maestro (any Rockwell, presumably) will shift back up _if asked to by
the other end_, it just won't initiate fallforward itself.  Not sure that's
relevant, but it meant we could connect reliably, often at 9600 or 12000,
sometimes 7200, always with EC, and get up to 14400 if the lines panned out
for that call.

IS> I may have said it before, but 24000/Lap-M is likely a better, more
IS> productive (and as fast) a link as 28800/none.  26400/Lap-M
 IS> certainly is.
IS> Some people round here achieved just such results on a
 IS> Motorola lifestyle,
IS> by that method.

Oh, I did mention that :)

 PE> Two points:

 PE> 1. Why isn't 28800 just as productive, assuming fallback is enabled?

28800/none has a maximum file xfer throughput of something like 97% of 2880
cps, say 2790.  26400/LapM should give you say 115% of 2640, say 3036 cps -
without the noise, CRC errors etc likely with /none - particularly if the
line is less than perfect, which appears likely.  2400 * 115% is still
2760, no?

Could be the Netcomm has different parameters for initial trainup, cf f/back?

 PE> 2. The problem is more fundamental than that.  Even if the lines are
 PE> noisy at 28800, EC should still be negotiated.  EC was not something
 PE> designed to be used purely on good lines, after all!

Yeah, but 'should' assumes things, which often prove unrealistic in
practice; this is why you need to be able to get at the tunable parameters
.. the idea of pulling modems out of the box, like toasters, and having
them make perfect 'toast' first time is simply unrealistic, unless you're
blessed with wonderful lines and just the right amount of local loop ..

 PE> And if the
 PE> lines are so lousy that you can't get any of the EC characters
 PE> through,

That's one possible reason why EC isn't happening, maybe ..

 PE> the modems with their default settings have no right to be
 PE> connecting at 28800.  That is lying and cheating.  They should be
 PE> connecting at 19200, or whatever the lines REALLY allow.

Yeah, well.  'Should' depends on many manufacturer assumptions, like
exchange type/s, local loop losses, all sorts of things.  It's not a
perfect network yet, and these things are stretching the limits of voice
telephony.  They're optimised, in default configuration, for a particular
set of conditions, and according to the skill of each manufacturer - a
known variable.

As I said, you _should_ be able to tune its 'aggressiveness' of trying for
a particular speed, with a given set of conditions - which are complex: tx
and rx signal levels, delays, near and far echo levels, signal to noise,
all that.

Lewin would know a lot more about this, from the perspective of the maker
tuning those characteristics via the DSP, and about what's available to the
manufacturer who uses the DSP pretty well raw, like Netcomm, Dataplex and a
few others, and those who just bolt in the pre-coded 'solution' best-guess
stuff.  Then, how much access the USER has to play with it, by published or
possibly unpublished commands.

I'd be surprised if both the Netcomm and the Sportster didn't have a way to
select the bit error rate (BER) at which fallforward and fallback occur,
and this setting should determine 'agressiveness' of initial training, too.
 The details of 'how' I don't know for either of those .. I bet it's
something that turns out looking simple, though :)

Ian

--- MaltEd 1.0.b5