Ian, at 07:55 on Apr 25 1996, you wrote to Bill Grimsley...

BG> True, it's most unsatisfactory, especially as V.34 is
BG> supposed to analyse line conditions transparently, and
BG> connect accordingly, no user intervention required at all.
BG> This is not happening with an M34F on one end of the link.

IS> I don't think it's a V.34 problem, as such. 

Neither do I, just quietly.  With my somewhat limited exposure to NetComm's
28k8bps modems, it's hard to point the finger with any accuracy, but the
M34F does appear to be a little deficient in certain areas, and some
side-by-side comparisons with a V.34+ Courier (as well as my own V.34+
Sportster) showed that at the same symbol rate, the USRs gave far superior
connect speeds, and even more importantly, was able to maintain them with
great consistency.

IS> The physical protocol connects are solid enough, no dropouts reported on 
IS> multi-hour connects, etc.

This is on reasonably good lines, presumably?  I've found that with poorer
quality lines (such as mine, with it's somewhat restricted bandwidth), the
NetComms negotiate initial link rates as much as 4800bps lower than the
USR.

IS> I think it's a timing problem above that level, where the controller code, 
IS> having been returned a (say) 28800 connect by V.34, which is connected and 
IS> pumping, has to use that underlying V.34 layer to then negotiate error 
IS> correction - or not.

Dunno, I tend to think it could just as easily be a combination of limited
bandwidth, and a poor S/N ratio to go with it.  Or both.  :)

IS> Where some modems might take a little longer, and recognise and acknowledge 
IS> the requests incoming for (say) a LAPM session, the Netcomm's decided it's 
IS> too late, and in its haste has declared EC off.  That's my take on it, 
IS> anyway.

I seem to recall that you were able to verify that to some degree, by
adjusting the NetComm's LAPM negotiation time, were you not?  Or perhaps
that was Paul Edwards, I forget now?  

IS> Following on .. when the other end is being more fussy about line quality 
IS> (BER for a given connect speed), the extra speed negotiation time synchs 
IS> the EC negotiation better, and EC is thus readily achieved. 

A good point, and now that you mention it, I do recall occasions where EC
failed to negotiate (both V.32bis to a Spirit II, and V.34 to an M34F), yet
the modems only cycled once through the negotiation tones, perhaps
indicating that a slightly longer detect time may have solved that problem.
 Hard to say.

IS> (Just gut feeling .. but there are various older Rockwell-chip gadgets, 
IS> including Maestro 144FMs, that seem to share this tendency, though only on 
IS> poorer lines.)

Yep, and the poor line quality seems to be the constant here as well.

BG> The Tx level can be forced as low as -9dBm I believe, but
BG> nothing will make them receive any better.  Even when Paul
BG> was playing around with different Tx levels, the CONNECT
BG> 28800/NONE problem still occurred from here.

IS> I don't think it's got much to do with levels at all, that's something else 
IS> that V.34 is supposed to be able to test, adjust and negotiate to suit.  

Quite right too, and in practice, it does appears to work quite well.

IS> That people were reporting up to 33600/33600 connects, with what might 
IS> appear to be lowish Tx levels reported, may support that.

I think those figures also need to be viewed in conjunction with the symbol
rate, carrier frequency, and (especially) the S/N ratio for these calls. 
Although I nearly always initially connect with Dave's Courier at
33600/31200, my line quality is such that my modem appears to speed-shift
quite frequently (just as well it's virtually instantaneous) and the
aftercall stats will often indicate a final link rate of say 31200/28800
(or occasionally even less).  And needless to say, these multiple
speed-shifts manifest themselves as wildly varying cps rates in the logs.

IS> The timing problem (per my hunch) might or might not appear on especially 
IS> excellent lines / connects, I'm not certain, but this problem occurs on 
IS> lines that _should_ be excellent .. 

I wouldn't mind betting that where this problem still occurs, even on those
lines where the available bandwidth is quite exceptional, the S/N ratio
could well be quite poor.  Indeed, Russell Brooks had the same problem in
FNQ.

IS> but I've as yet no facility to test them myself.

The judicious purchase of a USR would, of course, solve that problem.  :)

BG> Funny thing is, it ALWAYS receives at 33600, regardless.  I'm not 
BG> complaining though, as my frequency chart shows that I'm lucky to be
BG> connecting at speeds higher than 26400 (and that's on a good day!).  :)

IS> Ah, I can still to look forward to some good on-line stats.  I've just 
IS> acquired a board that can, among other things, acquire a single analogue 
IS> channel, at 12 bits, at upto around 90kHz DMA.  I'm thinking it might be 
IS> interesting to peek at some line signals at that sort of rate .. :)

Absolutely!  If nothing else, you'll have the USR zealots green with envy.

IS> All the above may be referring to (as John Cleese might say) an ex-parrot.  
IS> I'll suggest that firmware revision number to the uni bods, thanks.

Last I heard, NetComm's in-warranty firmware upgrades were FOC, but I'd be
checking with them first.  And whatever you do, don't mention the war...

Regards, Bill

--- Msgedsq/2 3.20