-=> Quoting Craig Ford to Richard Town <=-

 RT> USR chooses the 3200 symbol rate when answering a call from a modem
 RT> that doesn't support the 2743 symbol rate and that indicates the
 RT> same maximum projected data rate for both the 3200 and 3429 symbol
 RT> rates.  This does not match what other V.34 implementations do.  By
 RT> choosing the 3200 symbol rate instead of the 3429 symbol rate USRs
 RT> are giving up about 2dB of SNR.  On a lot of lines that is the same
 RT> as giving up one data rate. 
 CF> Before you quote Dan, you need to find out what he's been up to
 CF> lately.

Yes, neat kludge.  Whether that'll stand the test of time post 31k2/33k6
annexe into V34 in October is another matter.  Betcha a pound to a penny
we'll see another .sdl from USR, and another -19 from Supra soon after.
Followed on by another 31k2/33k6 capable ROM update from Zoom in addition
to their recently introduced 33k6 capable product...

 CF> 1. Why do you project a data rate for a symbol rate you don't support?
 CF> 2. Why do you weight the 3200 and 3429 symbol rates equally, if 3429
 CF> is what you deire to run at?   
 CF> 3. Whose V.34 implementation are you refering to, that doesn't do
 CF> this. 4. Why was't there any interop testing done _before_ you released
 CF> this?

I will pass on your questions to those who did do the development work.
Meantime please note that incoming 3429 symbol rate calls to Zooms with
ver1.309 ROM and up are fine

 CF> RT> 'Cept that it don't work, coz your favourite modem is deficient 
 
 CF> It isn't part of any ITU recommendation.
 CF> that doesn't is? Take your blinders off Richard.

There's no good reason to support the 2743 symbol rate
 
 RT> Neither is HST nor V32terbo.  In thruput terms, given that on good
 RT> links MNP/V42bis outperformed pre-SREJ LAP-M, this was yet another
 RT> method to deliberately strike a performance difference between
 RT> budget modems and USRs by design.
 CF> There is _no_ difference between LAP-M and MNP4
     with equivalent data frame sizes.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Now you're getting sad.  At the time under discussion, the frame sizes
were not equivalent.  Hence 256byte MNP4 was faster than 128byte LAP-M
in apparent effective thruput terms.  But still today, a mixture of
uncompressed and fully compressed files cannot be requested by a budget
modem from a USR without loss of thruput.  Everyone else is MNPn/V42bis
capable, but not a USR.  Why not?

 CF> Try again when you actually _know_ what you're talking
 CF> about.

Wake up.  You're being conned.  Only own pride is stopping you from
admitting it

 RT> It's called Modem Apartheid.  ie USRs are deliberately configured
 RT> to recognise the colour of callers' money spent on modem in
 RT> deciding what performance to achieve.

 CF> It is called _fully_ participating in the design and development of
 CF> internationally agreed upon procedures instead of pursuing
 CF> alternatives with the intent of confusing the unknowing.

Who wrote that for you?

 CF> There is a concept know as "accepted practice", when it comes to
 CF> implementing ITU-T protocols. Everything isn't spelled out in black and
 CF> white, and it takes a bit of testing with other implementors to arrive
 CF> at common implementation strategies.

Appreciate that.  But how can you perform inter-operability testing when
the required symbol rate, as well as protocol combination is missing --
by design?

 CF> all about. Perhaps you might convince the manufactuer of the datapump
 CF> you use to do so before it embarases you further.

Even Rockwell can't devine the commercially inspired design peversions
USR have employed.  Especially censorship of otherwise freely available
.sdls :-))

rgdZ
Richard





--- FMail/386 1.02