V.92 -- Is it worth it ?

Anyone with experience with the new dial-up V.92 modems ... and whose
ISP support such modems ?

Apart from being able to talk on the phone while connected to your ISP,
is it worth it ?

noone <(E-Mail Removed)> wrote:

> Anyone with experience with the new dial-up V.92 modems ... and whose
> ISP support such modems ?

I have no significant experience with V.92 but am also debating whether
it's worth buying one. In my opinion it's a personal judgment call.

If my wife's new Windows box (it would not be possible to convince her
to switch) is to be believed then she gets 53.2 kb/s down connections
every time. Actually that's an outright lie. I asked our ISP support
staff and it doesn't support V.92. Moreover, they said

Most server-side vendors have delayed the release of V.92 code that
supports PCM upstream. 3Com's CommWorks released V.92/V.44 code recently
becoming the first server-side vendor to offer PCM upstream - with a
maximum rate less than V.34, and a longer handshake.

PCM = Phase Code Modulation, new in V.92.

I've since googled enough to believe that there *is* a serious problem
with PCM upstream implementation, or the PCM upstream theory. An example:

As of late April 2003, the V.92 feature that provides for higher
upstream rates is still basically non-functional: Cisco, Lucent, and
Nortel server modems do not support PCM upstream at all. Patton and
Commworks do, but the maximum PCM upstream rate you might achieve is
36kbps - 25% lower than the standard's 48k maximum

The best my SupraExpress V.90 has done, using the same ISP, is a hair
above 50 kb/s and usually it's 48 or 49 kb/s down with 28.8 kb/s up -
figures that I know are correct.

> Apart from being able to talk on the phone while connected to your ISP,
> is it worth it ?

From what I've read these _should be_ the significant things:

1) With a good landline for the connection a V.92 modem can get the
~53 kb/s mandated by FCC regulations with 33.6 kb/s down. It can also
be set to permit simultaneous 48 kb/s up and down data rates (PCM).

2) One source claims that any application that requires active
acknowledgments will run faster. That means to me that large
downloads of compressed, or otherwise nearly uniformly random files,
should be faster. If true, this is particularly appealing to me.

3) The V.92 compression algorithm is significantly better, so web
browsing would be faster.

4) The modem connections are faster since the modem "remembers
connection conditions" and tests succeeding calls for a match (as
opposed to re-negotiating them).

5) The ability to talk over the phone is handled more gracefully
(I read that as "work more reliably") than V.90.

In view of the PCM problems I'm now not in any rush to go to V.92.
Thanks for the post, it provided the motivation to find the truth!

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* "PPPoE has many advantages for DSL service providers, and
practically none for DSL consumers."
- David F. Skoll */

Clifford Kite wrote:
>
> I've since googled enough to believe that there *is* a serious problem
> with PCM upstream implementation, or the PCM upstream theory. An example:
>
> As of late April 2003, the V.92 feature that provides for higher
> upstream rates is still basically non-functional: Cisco, Lucent, and
> Nortel server modems do not support PCM upstream at all. Patton and
> Commworks do, but the maximum PCM upstream rate you might achieve is
> 36kbps - 25% lower than the standard's 48k maximum

Where did you get this info? Care to provide a link ?

>
> From what I've read these _should be_ the significant things:
>
> 1) With a good landline for the connection a V.92 modem can get the
> ~53 kb/s mandated by FCC regulations with 33.6 kb/s down.

I am confused with your statement above since you have mixed 53 kb/s
with 33.6 kb/s on the same sentence referring to the same V.92 modem ...
and same direction ( download ) ?

> 3) The V.92 compression algorithm is significantly better, so web
> browsing would be faster.

I have one question here ... some webservers compress the webpages and
the user agents decompress them ( e.g.: mod_deflate in Apache ).
Wouldn't the modem compressing them again making things slower, by
making the file / stream actually bigger ? I am assuming that since the
file being served is already compressed, further compression will
actually increase the size.

Come to think of it, wouldn't this be true for __any__ internet
connection that has compression built-in explicitly or implicitly ?
( e.g.: HTTP Download of a tar.gz file, etc )

>
> 4) The modem connections are faster since the modem "remembers
> connection conditions" and tests succeeding calls for a match (as
> opposed to re-negotiating them).
>
> 5) The ability to talk over the phone is handled more gracefully
> (I read that as "work more reliably") than V.90.

Did that actually work in V.90 ? I was not aware of that.
I thought you can only do that if you go broadband / ADSL.

noone <(E-Mail Removed)> wrote:
> Clifford Kite wrote:
>>
>> I've since googled enough to believe that there *is* a serious problem
>> with PCM upstream implementation, or the PCM upstream theory. An example:
>>
>> As of late April 2003, the V.92 feature that provides for higher
>> upstream rates is still basically non-functional: Cisco, Lucent, and
>> Nortel server modems do not support PCM upstream at all. Patton and
>> Commworks do, but the maximum PCM upstream rate you might achieve is
>> 36kbps - 25% lower than the standard's 48k maximum

> Where did you get this info? Care to provide a link ?

http://www.modemsite.com/56k/v92interop.asp

>> From what I've read these _should be_ the significant things:
>>
>> 1) With a good landline for the connection a V.92 modem can get the
>> ~53 kb/s mandated by FCC regulations with 33.6 kb/s down.

> I am confused with your statement above since you have mixed 53 kb/s
> with 33.6 kb/s on the same sentence referring to the same V.92 modem ...
> and same direction ( download ) ?

Oops. You have every right to be confused. It should read ~53 kb/s
down with 33.6 kb/s up.

>> 3) The V.92 compression algorithm is significantly better, so web
>> browsing would be faster.

> I have one question here ... some webservers compress the webpages and
> the user agents decompress them ( e.g.: mod_deflate in Apache ).

I'd never heard of HTML page compression implemented in a web server or
decompression of the pages in a browser until I saw another post here
this morning about it! Is it a recent innovation?

> Wouldn't the modem compressing them again making things slower, by
> making the file / stream actually bigger ? I am assuming that since the
> file being served is already compressed, further compression will
> actually increase the size.

Different compression algorithms compress differently, so I think the
answer, in general, has to be "no." There are software compression
algorithms that don't check to see whether compression might not be
appropriate, and for some of those the size may increase slightly.

Offhand I'd say the HTML page compression must be aimed at connections
via a physical layer other than modem/landline since modem compression
is virtually universal these days.

Software compression can actually compress somewhat more for certain
types of data even when combined with modem compression. PPP itself
has a provision for negotiating software compression.

> Come to think of it, wouldn't this be true for __any__ internet
> connection that has compression built-in explicitly or implicitly ?
> ( e.g.: HTTP Download of a tar.gz file, etc )

You can't compress a file with uniformly distributed data. Period.
So any further compression of compressed files, which are much more
nearly uniformly distributed than those not compressed, doesn't help
much.

>> 4) The modem connections are faster since the modem "remembers
>> connection conditions" and tests succeeding calls for a match (as
>> opposed to re-negotiating them).
>>
>> 5) The ability to talk over the phone is handled more gracefully
>> (I read that as "work more reliably") than V.90.

> Did that actually work in V.90 ? I was not aware of that.
> I thought you can only do that if you go broadband / ADSL.

You may be right about that. That the "more gracefully" came from
a white paper at the USR web site (I have the original file but
don't have a link for it) and it looks like I may have incorrectly
interpreted that part. I don't *know* whether it was, or even
could be, implemented in a V.90 modem. It's not something I would
use anyway.

There's a usenet group for modems that you could try. I don't recall
the name but it shouldn't be hard to find.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* I gave up on politics when no matter who I voted for, I regretted it.
* -- Pepper...and Salt, WSJ */

Clifford Kite wrote:
> noone <(E-Mail Removed)> wrote:
>
>
>>I have one question here ... some webservers compress the webpages and
>>the user agents decompress them ( e.g.: mod_deflate in Apache ).
>
>
> I'd never heard of HTML page compression implemented in a web server or
> decompression of the pages in a browser until I saw another post here
> this morning about it! Is it a recent innovation?
>
>

No. It is part of HTTP/1.1. See Section 3.5:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html

It can be either gzip, compress, or deflate.

noone wrote:
>
> No. It is part of HTTP/1.1. See Section 3.5:

Sorry. I meant 3.5 and 3.6

>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
>
> It can be either gzip, compress, or deflate.
>

noone <(E-Mail Removed)> wrote:
> noone wrote:
>>
>> No. It is part of HTTP/1.1. See Section 3.5:

> Sorry. I meant 3.5 and 3.6

>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
>>
>> It can be either gzip, compress, or deflate.

I don't pretend to know how these sections SHOULD be interpreted, but
to me they seem to apply to non-ascii encoded documents to insure the
'"safe transport" of them through the network' (see first sentence in
3.6), not HTML pages.

I know that .gz, .zip, .doc, .pdf, ect. file types can be displayed
but I've *never* seen an HTML coded page that was compressed by gz or
zip compression.

BTW, I stumbled onto some old SupraExpress documentation in my file case
and at least some V.90 models had voice capability. I don't know (and
don't care) whether mine can do voice.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* I gave up on politics when no matter who I voted for, I regretted it.
* -- Pepper...and Salt, WSJ */

Clifford Kite wrote:
>
> I know that .gz, .zip, .doc, .pdf, ect. file types can be displayed
> but I've *never* seen an HTML coded page that was compressed by gz or
> zip compression.

Sure there are. /. is just one example:

Do a tcpdump or ethereal when you go to http://slashdot.org
( www.slashdot.org will redirect you to slashdot.org )

Below is what I get ( HTTP response body skipped since they are all
binary ). Notice the Content-Encoding header on the HTTP response.


GET / HTTP/1.1
Host: slashdot.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 200 OK
Date: Mon, 10 Nov 2003 22:51:04 GMT
Server: Apache/1.3.28 (Unix) mod_gzip/1.3.26.1a mod_perl/1.28
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.003000
X-Bender: Bite my shiny, metal ass!
Vary: Accept-Encoding
Cache-Control: private
Pragma: private
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Encoding: gzip
Content-Length: 15099


>
> BTW, I stumbled onto some old SupraExpress documentation in my file case
> and at least some V.90 models had voice capability. I don't know (and
> don't care) whether mine can do voice.
>

The prices of these new V.92 modems are not cheap at the moment anwyay.
I'll just probably wait until prices go down and my ISP supports them.

noone <(E-Mail Removed)> wrote:
> Clifford Kite wrote:
>>
>> I know that .gz, .zip, .doc, .pdf, ect. file types can be displayed
>> but I've *never* seen an HTML coded page that was compressed by gz or
>> zip compression.

> Sure there are. /. is just one example:

> Do a tcpdump or ethereal when you go to http://slashdot.org
> ( www.slashdot.org will redirect you to slashdot.org )

Okay, tcpdump verifies that and I've learned something else now. Thanks!

It makes sense to have compressed HTML pages at the server and uncompress
them with the browser since it reduces Internet traffic. It's transparent
to the browser user so I never noticed it - and know next to nothing
about HTTP.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

Clifford Kite wrote:
> noone <(E-Mail Removed)> wrote:
>
>>Clifford Kite wrote:
>>
>>>I know that .gz, .zip, .doc, .pdf, ect. file types can be displayed
>>>but I've *never* seen an HTML coded page that was compressed by gz or
>>>zip compression.
>
>
>>Sure there are. /. is just one example:
>
>
>>Do a tcpdump or ethereal when you go to http://slashdot.org
>>( www.slashdot.org will redirect you to slashdot.org )
>
>
> Okay, tcpdump verifies that and I've learned something else now. Thanks!
>
> It makes sense to have compressed HTML pages at the server and uncompress
> them with the browser since it reduces Internet traffic. It's transparent
> to the browser user so I never noticed it - and know next to nothing
> about HTTP.
>

It should be supported at both ends ... Thus, when Mozilla sends an HTTP
request, it sent the following:

Accept-Encoding: gzip,deflate

The webserver then knows that it can send an HTTP response with a
"Content-Encoding: gzip" or "Content-Encoding: deflate" HTTP header and
therefore instead of just serving the static / dynamic HTML file, the
webserver compresses it.

Now I just wonder if all that extra compression takes up a lot of CPU
cycles on the webserver vs. just simply reading the file and writing it
to the socket. Maybe there are PCI compression cards out there that
allows you to off-load gzip and deflate compression onto the chip on the
card ?