v.44 Implementation Seems Poor
Jon Wells
chipset) running on WinXP. I created a 1gb file in MS Write composed of
nothing but the letter 'a' in plain text (in other words the most
compressible file you can make). Uploaded it to my ftp site on toast.net,
along with a 300kb jpeg file. Then I downloaded both using with CuteFTP
using three different connections on the same comptuer:
1. toast.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation verified
in modem log)
3. meer.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation verified
in modem log)
2. mindspring.com connecting @ 49.6k (v.90/v.42, with v.42 negotiation
verified in modem log)
I monitored throughput using Net-Medic and Turtle Speed-O-Meter. Here are
the results which were taken well into the download:
toast connection-jpeg = 48 kbs
toast connection-text = 200 kbs
meer connection-jpeg = 46 kbs
meer connection-text = 180 kbs
mindspring connection-jpeg = 48 kbs
mindspring connection-text = 380 kbs
- Above tests were done one after another on different days and times and
the results are represenative.
- To eliminate the ftp server variable, I uploaded/downloaded onto the meer
and mindspring ftp sites as well and the results are consistent.
- The jpeg (uncompressible) throughputs are substantially the same,
indicating similar connectivity.
Why would mindspring's v.42 throughput on highly compressible text be almost
twice that of v.44 on two different sites? Seems to me that v.44 is a bunch
of bunk.
Jon Wells
AT+DCS1,0. Mindspring's text throughput is now 200kbs, which is
understandable (4x compression). In modem log, i can see that I negotiated
at v.42. When I take out that string (so that v.44 is enabled if possiblem
v.42 otherwise), I also connect at v.42 in modem log, which is
understandable because Mindspring is not v.92/v.44 capable. Yet, text
throughput goes up to 390 kbs. Can anyone shed light on this?
"Jon Wells" <jwel...@toast.net> wrote in message
news:3eb5...@news03.toast.net...
Franc Zabkar
finger to keyboard and composed:
>Well, it even gets weirder. I dropped my compression to v.42 with the string
>AT+DCS1,0. Mindspring's text throughput is now 200kbs, which is
>understandable (4x compression). In modem log, i can see that I negotiated
>at v.42. When I take out that string (so that v.44 is enabled if possiblem
>v.42 otherwise), I also connect at v.42 in modem log, which is
>understandable because Mindspring is not v.92/v.44 capable. Yet, text
>throughput goes up to 390 kbs. Can anyone shed light on this?
Just to be completely sure that your results are not coincidental,
limit your speed to 40000bps, say, and check that there are no
speedshifts or retrains in your modem's postcall stats. See Ed
Schulz's suggestions at end of post.
FWIW, I prefer WS_FTP to CuteFTP, as the latter contains spyware.
WS_FTP also reports the transfer time, so you don't really need
Net-Medic or Turtle Speed-O-Meter.
>"Jon Wells" <jwel...@toast.net> wrote in message
>news:3eb5...@news03.toast.net...
>> My modem is a Zoom v.92/v.44 3025n PCI controllerless (Agere Mars 3.2
>1648C
>> chipset) running on WinXP. I created a 1gb file in MS Write composed of
>> nothing but the letter 'a' in plain text (in other words the most
>> compressible file you can make).
Did you save it as a .txt or .wri file? The latter contains formatting
info which would make it less compressible than a .txt file.
Here is an easy way to create a file (zeros.txt) consisting of the
character "0" repeated one million times, without CRLF terminators.
http://groups.google.com/groups?selm=3b7233ae.12421536%40news.dingoblue.net.au&oe=utf-8&output=gplain
Here are the results of similar testing by "Steve":
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&selm=VKjW9.1855%24zF6.155226%40bgtnsc04-news.ops.worldnet.att.net
... and some good suggestions for accurate measurement from Ed Schulz:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&selm=3E2D612D.26311C34%40agere.com
-- Franc Zabkar
Please remove one 's' from my address when replying by email.
Jon Wells
<snip>Did you save it as a .txt or .wri file? <snip>
I SAVED IT AS A .TXT FILE.
It appears Steve uses AT&T for his ISP. I'll have to check that out,
because his speeds are much better using v.44. Its my understanding that
unless the ISP is v.44, you'll transfer at v.42. Still don't understand why
my v.42 ISP transfers text at twice the speed of my v.44 ISP, when jpeg's
transfer at comparable rates.
"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
news:t76bbvcgkld1h9a6q...@4ax.com...
Tom Schmidt
1648C
> chipset) running on WinXP. I created a 1gb file in MS Write composed of
> nothing but the letter 'a' in plain text (in other words the most
> compressible file you can make). Uploaded it to my ftp site on toast.net,
> along with a 300kb jpeg file. Then I downloaded both using with CuteFTP
> using three different connections on the same comptuer:
> 1. toast.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation
verified
> in modem log)
> 3. meer.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation verified
> in modem log)
> 2. mindspring.com connecting @ 49.6k (v.90/v.42, with v.42 negotiation
> verified in modem log)
>
> I monitored throughput using Net-Medic and Turtle Speed-O-Meter. Here are
> the results which were taken well into the download:
> toast connection-jpeg = 48 kbs
> toast connection-text = 200 kbs
> meer connection-jpeg = 46 kbs
> meer connection-text = 180 kbs
> mindspring connection-jpeg = 48 kbs
> mindspring connection-text = 380 kbs
>
Are you using and external or internal modem to do these tests? External
modem speed is limited to 115 or 230 kbps.
I agree the differences in compression are a puzzle.
Are you sure these test are average transfer over a reasonable period of
time?
At 53.3 kbps assuming 10% TCP/IP and PPP overhead 48 kbps is maximum
possible speed. The numbers look a little too good to be true.
/Tom
Jon Wells
transfer (the rates were taken towards the end of the download).
"Tom Schmidt" <Tom...@tschmidt.invalid> wrote in message
news:HHlta.49409$J27...@nwrdny02.gnilink.net...
Jon Wells
extremely stable. I have an Athlon 1900+ with 512mb of ram, so resources
aren't an issue. According to Agere, the maker of the chipset, its a
"Host-Based Controller Modem Chip Set". Not sure what that means but I
think its some type of hybrid setup. The link to the data sheet is
http://www.agere.com/client/docs/PB01028.pdf
"Jon Wells" <jwel...@mindspring.com> wrote in message
news:b94pjk$mkh$1...@slb6.atl.mindspring.net...
Franc Zabkar
<jwel...@mindspring.com> put finger to keyboard and composed:
>Thanks for your info.
>
><snip>Did you save it as a .txt or .wri file? <snip>
>I SAVED IT AS A .TXT FILE.
>
>It appears Steve uses AT&T for his ISP. I'll have to check that out,
>because his speeds are much better using v.44. Its my understanding that
>unless the ISP is v.44, you'll transfer at v.42. Still don't understand why
>my v.42 ISP transfers text at twice the speed of my v.44 ISP, when jpeg's
>transfer at comparable rates.
I don't understand either. FWIW, here is a link to a thread where a
Lucent user posted the results of a series of throughput tests:
Is it possible you are using two different DUN connectoids to connect
to Mindspring, one with software compression, the other without?
Franc Zabkar
finger to keyboard and composed:
>Well, it even gets weirder. I dropped my compression to v.42 with the string
>AT+DCS1,0. Mindspring's text throughput is now 200kbs, which is
>understandable (4x compression).
Actually, I measured a compression ratio in excess of 10, and it could
be much greater than that. I tested as follows.
I forced a connection at 19200bps (V.34) and transferred a text file
consisting of one million repetitions of the letter "a" using WS_FTP.
Windows System Monitor reported a steady upload speed of 21.4KBps.
WS_FTP calculated the transfer rate, including overhead, at 19.29KBps
(1,000,000 bytes in 50.6 secs).
At 19200bps, assuming 9 bits/byte, one would expect a modem-to-modem
transfer rate of 2133Bps. Therefore, the compression ratio, for this
test, is 21.4 x 1024 / 2133 = 10.3.
My maximum DTE rate is limited by design to 230400bps, ie 22.5KBps.
Hence, I cannot tell for certain if the figure of 21.4KBps is limited
by the DTE rate, or by the compression algorithm.
Tom Schmidt
Just a nit is you are using an external modem each byte costs at least 10
bits, byte plus start/stop. If parity is enabled that adds another bit
bringing total to 11. Internal modems do not have this bottleneck since they
don't use the serial connection just emulate it.
/Tom
Rick
The start and stop bits are stripped on error-correcting
connections on the DCE link. The data is sent in a packet, 8
bits per char, with a header. That's the link that matters
'cause that's where the compression occurs.
Parity doesn't enter the equation - it's 8 bits no parity or
7 bits + 1 parity bit.
Franc Zabkar
<fza...@optussnet.com.au> put finger to keyboard and composed:
>On Sun, 04 May 2003 22:07:50 GMT, "Jon Wells" <jwel...@toast.net> put
>finger to keyboard and composed:
>
>>Well, it even gets weirder. I dropped my compression to v.42 with the string
>>AT+DCS1,0. Mindspring's text throughput is now 200kbs, which is
>>understandable (4x compression).
>
>Actually, I measured a compression ratio in excess of 10, and it could
>be much greater than that. I tested as follows.
>
>I forced a connection at 19200bps (V.34) and transferred a text file
>consisting of one million repetitions of the letter "a" using WS_FTP.
>Windows System Monitor reported a steady upload speed of 21.4KBps.
>WS_FTP calculated the transfer rate, including overhead, ...
Sorry, that should have read "excluding overhead".
>... at 19.29KBps
>(1,000,000 bytes in 50.6 secs).
>
>At 19200bps, assuming 9 bits/byte, one would expect a modem-to-modem
>transfer rate of 2133Bps. Therefore, the compression ratio, for this
>test, is 21.4 x 1024 / 2133 = 10.3.
>
>My maximum DTE rate is limited by design to 230400bps, ie 22.5KBps.
>Hence, I cannot tell for certain if the figure of 21.4KBps is limited
>by the DTE rate, or by the compression algorithm.
I performed the same test at 9600bps. System Monitor showed a transfer
rate of 13-14KBps. WS_FTP required 79.0 sec to transmit the 1MB file,
ie 12.35KBps. The compression ratio is therefore about 14 x 1024 /
(9600/9) = 13.4.
Franc Zabkar
<Tom...@tschmidt.invalid> put finger to keyboard and composed:
I'm using an internal full hardware ISA Rockwelloid. It emulates a
16550 UART, but not quite in the same way that a soft or
controllerless modem does. One significant difference is that the DTE
rate is emulated accurately, including start and stop bits, ie the
modem will set its DTE transfer rate to match the port rate in the
UART registers. For example, if I set the DTE rate to 115200bps, then
the modem's throughput ceiling is reduced to 11.5KBps. Lucent/Agere
controllerless modems, OTOH, will ignore the DTE rate setting and
transfer data as fast as the hardware and software allow (according to
Ed Schulz of Agere). Having said that, there are several curious
differences between my modem's emulated UART and the real thing. If I
choose an unsupported DTE rate, eg 110bps, the modem will behave as if
it had been set for 57600bps. However, any terminal app that queries
the UART's baud rate divisor latches will see 110bps, not 57600.
Another important difference is that my modem's FIFO buffer will never
experience serial overrun errors, even if I disable it.
On the subject of 11 bit word lengths, I think you will find that few,
if any modems will support such a configuration. IIRC, someone posted
to c.d.m in search of such an animal and was unable to find one.
Just one final observation. I notice that, for the most part, the OP's
modem has a throughput ceiling of ~20KBps. Elsewhere in this thread I
have shown that the compression ratio for a particular highly
compressible text file is ~13 (for V.42bis). Since the DCE rate is
about 5KBps, one would expect a DTE rate of ~65KBps for the OP's
modem. This suggests that there is a bottleneck somewhere. Now, as the
Lucent is a controllerless modem, and as EC and compression are
handled by the modem's controller (AFAIK), and as the controller is
emulated in the modem's driver, it follows that the bottleneck is in
the 32-bit host based software. Curiously, my hardware modem has
better throughput, yet it is based on a lowly 8-bit Rockwell CPU
(AFAIK).
FYI, here are the results of my V.42/V.42bis/MNP data compression and
error correction tests:
http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.au&oe=utf-8&output=gplain
Aaron Leonard
is that you are encountering bottlenecks in the ISP side
modems.
For example, if they're using Cisco NASes, then the top
throughput available will vary depending on how old the
modems are ... if they're using the old Microcom V.90
modems (which support V.90 and V.42bis but not V.92 or
V.44), then your top compressed throughput rate will be 92k
(115200bps * 0.8.) If they're using MICA modems (which
suupport V.90/V.92/V.42bis/V.44), then your top rate
will be around 180-200k. If they're using our newest
(NextPort modems), then your top rate with V.44 compression
will be around 400k.
I don't know about other vendors' top speeds, but I'm
sure that they vary considerably also.
In the real world, getting 180kbps or above throughput on
actual data is very GOOD. You will NOT be doing large bulk
transfer of text that contains nothing but the letter 'a'.
You will be moving already-compressed stuff ... of the
compressible stuff (HTML, email, EXEs), you will be doing
quite well to get the 4:1 compression that you report
seeing - let alone 8:1.
V.44 *is* somewhat better (especially on HTML) than V.42bis
in compressing real world data. Moving your 'a' file is
not really a meaningful comparison between the V.44 and V.42bis
algorithms ... even MNP5 can achieve arbitrarily large
compression ratios with a file like that.
Have fun,
Aaron
---
~ My modem is a Zoom v.92/v.44 3025n PCI controllerless (Agere Mars 3.2 1648C
~ chipset) running on WinXP. I created a 1gb file in MS Write composed of
~ nothing but the letter 'a' in plain text (in other words the most
~ compressible file you can make). Uploaded it to my ftp site on toast.net,
~ along with a 300kb jpeg file. Then I downloaded both using with CuteFTP
~ using three different connections on the same comptuer:
~ 1. toast.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation verified
~ in modem log)
~ 3. meer.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation verified
~ in modem log)
~ 2. mindspring.com connecting @ 49.6k (v.90/v.42, with v.42 negotiation
~ verified in modem log)
~
~ I monitored throughput using Net-Medic and Turtle Speed-O-Meter. Here are
~ the results which were taken well into the download:
~ toast connection-jpeg = 48 kbs
~ toast connection-text = 200 kbs
~ meer connection-jpeg = 46 kbs
~ meer connection-text = 180 kbs
~ mindspring connection-jpeg = 48 kbs
~ mindspring connection-text = 380 kbs
~
~ - Above tests were done one after another on different days and times and
~ the results are represenative.
~ - To eliminate the ftp server variable, I uploaded/downloaded onto the meer
~ and mindspring ftp sites as well and the results are consistent.
~ - The jpeg (uncompressible) throughputs are substantially the same,
~ indicating similar connectivity.
~
~ Why would mindspring's v.42 throughput on highly compressible text be almost
~ twice that of v.44 on two different sites? Seems to me that v.44 is a bunch
~ of bunk.
~
Jon Wells
throughput on my test .txt file is about 380kbs, it takes about 50-55
seconds to full display the cnet home page. In contrast, my v.44
connection, which downloads my .txt file at only 200kbs, loads the cnet.com
home page in 40-45 seconds. jpeg's, which are essentially uncompressible,
download at about the same speed on each connection. In my test, cache
files were deleted and cache disabled; test repeated numerous times. So, I
don't really understand the results, but there you have it.
"Aaron Leonard" <Aa...@Cisco.COM> wrote in message
news:8evfbvk2srsrtfd0r...@4ax.com...
Aaron Leonard
note that you're talking about V.42bis (the specification for BTLZ
compression) *not* V.42 (the specification for LAPM/MNP4 error control.)
~ throughput on my test .txt file is about 380kbs, it takes about 50-55
~ seconds to full display the cnet home page. In contrast, my v.44
~ connection, which downloads my .txt file at only 200kbs, loads the cnet.com
~ home page in 40-45 seconds.
Makes perfect sense to me:
V.44 compresses better than V.42bis. It ESPECIALLY compresses
HTML better, since it's HTML-aware.
So if V.44 gives you (say) 3:1 compression while V.42bis gives you
2.5:1 compression, on some particular data patter, then your page
should display quicker with V.44.
Now, it's true that, with some entirely fanciful data pattern
(all a's), the one modem connection could do 380kbps and the
other could do 200kbps. But with the real world data, you
don't need 380kbps or even 200kbps to handle your 2.5:1 or
3:1 compression. So the 200k bottleneck that you found
with your contrived test didn't kick in on the real world data.
~ jpeg's, which are essentially uncompressible,
~ download at about the same speed on each connection.
That certainly makes sense.
~ In my test, cache
~ files were deleted and cache disabled; test repeated numerous times. So, I
~ don't really understand the results, but there you have it.
Hope this explains it better.
Cheers,
Aaron
---
~ "Aaron Leonard" <Aa...@Cisco.COM> wrote in message
~ news:8evfbvk2srsrtfd0r...@4ax.com...
~ > One likely explanation of the speeds that your seeing
~ > is that you are encountering bottlenecks in the ISP side
~ > modems.
~ >
~ > For example, if they're using Cisco NASes, then the top
~ > throughput available will vary depending on how old the
~ > modems are ... if they're using the old Microcom V.90
~ > modems (which support V.90 and V.42bis but not V.92 or
~ > V.44), then your top compressed throughput rate will be 92k
~ > (115200bps * 0.8.) If they're using MICA modems (which
~ > suupport V.90/V.92/V.42bis/V.44), then your top rate
~ > will be around 180-200k. If they're using our newest
~ > (NextPort modems), then your top rate with V.44 compression
~ > will be around 400k.
~ >
~ > I don't know about other vendors' top speeds, but I'm
~ > sure that they vary considerably also.
~ >
~ > In the real world, getting 180kbps or above throughput on
~ > actual data is very GOOD. You will NOT be doing large bulk
~ > transfer of text that contains nothing but the letter 'a'.
~ > You will be moving already-compressed stuff ... of the
~ > compressible stuff (HTML, email, EXEs), you will be doing
~ > quite well to get the 4:1 compression that you report
~ > seeing - let alone 8:1.
~ >
~ > V.44 *is* somewhat better (especially on HTML) than V.42bis
~ > in compressing real world data. Moving your 'a' file is
~ > not really a meaningful comparison between the V.44 and V.42bis
~ > algorithms ... even MNP5 can achieve arbitrarily large
~ > compression ratios with a file like that.
~ >
~ > Have fun,
~ >
~ > Aaron
~ >
~ > ---
~ >
~ > ~ My modem is a Zoom v.92/v.44 3025n PCI controllerless (Agere Mars 3.2
~ 1648C
~ > ~ chipset) running on WinXP. I created a 1gb file in MS Write composed
~ of
~ > ~ nothing but the letter 'a' in plain text (in other words the most
~ > ~ compressible file you can make). Uploaded it to my ftp site on
~ toast.net,
~ > ~ along with a 300kb jpeg file. Then I downloaded both using with CuteFTP
~ > ~ using three different connections on the same comptuer:
~ > ~ 1. toast.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation
~ verified
~ > ~ in modem log)
~ > ~ 3. meer.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation
~ verified
~ > ~ in modem log)
~ > ~ 2. mindspring.com connecting @ 49.6k (v.90/v.42, with v.42 negotiation
~ > ~ verified in modem log)
~ > ~
~ > ~ I monitored throughput using Net-Medic and Turtle Speed-O-Meter. Here
~ are
~ > ~ the results which were taken well into the download:
~ > ~ toast connection-jpeg = 48 kbs
~ > ~ toast connection-text = 200 kbs
~ > ~ meer connection-jpeg = 46 kbs
~ > ~ meer connection-text = 180 kbs
~ > ~ mindspring connection-jpeg = 48 kbs
~ > ~ mindspring connection-text = 380 kbs
~ > ~
~ > ~ - Above tests were done one after another on different days and times
~ and
~ > ~ the results are represenative.
~ > ~ - To eliminate the ftp server variable, I uploaded/downloaded onto the
~ meer
~ > ~ and mindspring ftp sites as well and the results are consistent.
~ > ~ - The jpeg (uncompressible) throughputs are substantially the same,
~ > ~ indicating similar connectivity.
~ > ~
~ > ~ Why would mindspring's v.42 throughput on highly compressible text be
~ almost
~ > ~ twice that of v.44 on two different sites? Seems to me that v.44 is a
~ bunch
~ > ~ of bunk.
~ > ~
~ >
~
Franc Zabkar
finger to keyboard and composed:
>Well, your right about real world data. Even though the v.42 connection
>throughput on my test .txt file is about 380kbs, it takes about 50-55
>seconds to full display the cnet home page. In contrast, my v.44
>connection, which downloads my .txt file at only 200kbs, loads the cnet.com
>home page in 40-45 seconds.
How fast does the same page load if you limit your V.44 ISPs to V.42?
Jon Wells
Did three tests downloading cnet home page and results were consistenet.
With v.44 on toast.net, download time was 40 seconds. With compression
limited to v.42bis, download time was 45 seconds. Difference = 11%.
Certainly not dramatic. Cache cleared before each test.
Jon Wells
(v.42bis) download my test .txt file (a million letter "a"s) at 380 kbs
(about 8x compression) when my toast and meer connections (v.44) download
the same file at 200 kbs. jpeg download for each connection is about the
same, indicating similar connectivity.
"Aaron Leonard" <Aa...@Cisco.COM> wrote in message
news:57sibvstu1nnpi095...@4ax.com...
Tim Jenson
v.92. So it's possible that your connection to mindspring is a v.92
connection. If you one the Level 3 back bone their pops are v.92 capable.
Anyway just a thought. I was on Earthlink not to long ago and was getting
v.92 connections.
"Jon Wells" <jwel...@mindspring.com> wrote in message
news:b94ija$1uv$1...@slb5.atl.mindspring.net...
Aaron Leonard
~ But what's not clear is my original observation. Why would mindspring
~ (v.42bis) download my test .txt file (a million letter "a"s) at 380 kbs
~ (about 8x compression) when my toast and meer connections (v.44) download
~ the same file at 200 kbs. jpeg download for each connection is about the
~ same, indicating similar connectivity.
Again, my hypothesis is different modems at the server end. The
Mindspeed ones can do up to 380kbps assuming infinite compression
while the others can "only" do up to 200kps.
If you try toast and meer with V.42bis, I predict that you'll
get 200kbps still.
Aaron
---
~
~ "Aaron Leonard" <Aa...@Cisco.COM> wrote in message
~ news:57sibvstu1nnpi095...@4ax.com...
~ > ~ Well, your right about real world data. Even though the v.42 connection
~ >
~ > note that you're talking about V.42bis (the specification for BTLZ
~ > compression) *not* V.42 (the specification for LAPM/MNP4 error control.)
~ >
~ > ~ throughput on my test .txt file is about 380kbs, it takes about 50-55
~ > ~ seconds to full display the cnet home page. In contrast, my v.44
~ > ~ connection, which downloads my .txt file at only 200kbs, loads the
~ cnet.com
~ > ~ home page in 40-45 seconds.
~ >
~ > Makes perfect sense to me:
~ >
~ > V.44 compresses better than V.42bis. It ESPECIALLY compresses
~ > HTML better, since it's HTML-aware.
~ >
~ > So if V.44 gives you (say) 3:1 compression while V.42bis gives you
~ > 2.5:1 compression, on some particular data patter, then your page
~ > should display quicker with V.44.
~ >
~ > Now, it's true that, with some entirely fanciful data pattern
~ > (all a's), the one modem connection could do 380kbps and the
~ > other could do 200kbps. But with the real world data, you
~ > don't need 380kbps or even 200kbps to handle your 2.5:1 or
~ > 3:1 compression. So the 200k bottleneck that you found
~ > with your contrived test didn't kick in on the real world data.
~ >
~ > ~ jpeg's, which are essentially uncompressible,
~ > ~ download at about the same speed on each connection.
~ >
~ > That certainly makes sense.
~ >
~ > ~ In my test, cache
~ > ~ files were deleted and cache disabled; test repeated numerous times.
~ So, I
~ > ~ don't really understand the results, but there you have it.
~ >
~ > Hope this explains it better.
~ >
~ > Cheers,
~ >
~ > Aaron
~ >
~ > ---
~ >
~ >
~ > ~ "Aaron Leonard" <Aa...@Cisco.COM> wrote in message
~ > ~ news:8evfbvk2srsrtfd0r...@4ax.com...
~ > ~ > One likely explanation of the speeds that your seeing
~ > ~ > is that you are encountering bottlenecks in the ISP side
~ > ~ > modems.
~ > ~ >
~ > ~ > For example, if they're using Cisco NASes, then the top
~ > ~ > throughput available will vary depending on how old the
~ > ~ > modems are ... if they're using the old Microcom V.90
~ > ~ > modems (which support V.90 and V.42bis but not V.92 or
~ > ~ > V.44), then your top compressed throughput rate will be 92k
~ > ~ > (115200bps * 0.8.) If they're using MICA modems (which
~ > ~ > suupport V.90/V.92/V.42bis/V.44), then your top rate
~ > ~ > will be around 180-200k. If they're using our newest
~ > ~ > (NextPort modems), then your top rate with V.44 compression
~ > ~ > will be around 400k.
~ > ~ >
~ > ~ > I don't know about other vendors' top speeds, but I'm
~ > ~ > sure that they vary considerably also.
~ > ~ >
~ > ~ > In the real world, getting 180kbps or above throughput on
~ > ~ > actual data is very GOOD. You will NOT be doing large bulk
~ > ~ > transfer of text that contains nothing but the letter 'a'.
~ > ~ > You will be moving already-compressed stuff ... of the
~ > ~ > compressible stuff (HTML, email, EXEs), you will be doing
~ > ~ > quite well to get the 4:1 compression that you report
~ > ~ > seeing - let alone 8:1.
~ > ~ >
~ > ~ > V.44 *is* somewhat better (especially on HTML) than V.42bis
~ > ~ > in compressing real world data. Moving your 'a' file is
~ > ~ > not really a meaningful comparison between the V.44 and V.42bis
~ > ~ > algorithms ... even MNP5 can achieve arbitrarily large
~ > ~ > compression ratios with a file like that.
~ > ~ >
~ > ~ > Have fun,
~ > ~ >
~ > ~ > Aaron
~ > ~ >
~ > ~ > ---
~ > ~ >
~ > ~ > ~ My modem is a Zoom v.92/v.44 3025n PCI controllerless (Agere Mars
~ 3.2
~ > ~ 1648C
~ > ~ > ~ chipset) running on WinXP. I created a 1gb file in MS Write
~ composed
~ > ~ of
~ > ~ > ~ nothing but the letter 'a' in plain text (in other words the most
~ > ~ > ~ compressible file you can make). Uploaded it to my ftp site on
~ > ~ toast.net,
~ > ~ > ~ along with a 300kb jpeg file. Then I downloaded both using with
~ CuteFTP
~ > ~ > ~ using three different connections on the same comptuer:
~ > ~ > ~ 1. toast.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation
~ > ~ verified
~ > ~ > ~ in modem log)
~ > ~ > ~ 3. meer.net connecting @ 50.6k (v.92/v.44, with v.44 negotiation
~ > ~ verified
~ > ~ > ~ in modem log)
~ > ~ > ~ 2. mindspring.com connecting @ 49.6k (v.90/v.42, with v.42
~ negotiation
~ > ~ > ~ verified in modem log)
~ > ~ > ~
~ > ~ > ~ I monitored throughput using Net-Medic and Turtle Speed-O-Meter.
~ Here
~ > ~ are
~ > ~ > ~ the results which were taken well into the download:
~ > ~ > ~ toast connection-jpeg = 48 kbs
~ > ~ > ~ toast connection-text = 200 kbs
~ > ~ > ~ meer connection-jpeg = 46 kbs
~ > ~ > ~ meer connection-text = 180 kbs
~ > ~ > ~ mindspring connection-jpeg = 48 kbs
~ > ~ > ~ mindspring connection-text = 380 kbs
~ > ~ > ~
~ > ~ > ~ - Above tests were done one after another on different days and
~ times
~ > ~ and
~ > ~ > ~ the results are represenative.
~ > ~ > ~ - To eliminate the ftp server variable, I uploaded/downloaded onto
~ the
~ > ~ meer
~ > ~ > ~ and mindspring ftp sites as well and the results are consistent.
~ > ~ > ~ - The jpeg (uncompressible) throughputs are substantially the same,
~ > ~ > ~ indicating similar connectivity.
~ > ~ > ~
~ > ~ > ~ Why would mindspring's v.42 throughput on highly compressible text
~ be
~ > ~ almost
~ > ~ > ~ twice that of v.44 on two different sites? Seems to me that v.44 is
~ a
~ > ~ bunch
~ > ~ > ~ of bunk.
~ > ~ > ~
~ > ~ >
~ > ~
~ >
~
Aaron Leonard
~ >How fast does the same page load if you limit your V.44 ISPs to V.42?<
~
~ Did three tests downloading cnet home page and results were consistenet.
~ With v.44 on toast.net, download time was 40 seconds. With compression
~ limited to v.42bis, download time was 45 seconds. Difference = 11%.
~ Certainly not dramatic. Cache cleared before each test.
Again, note that V.44 should show (some) performance benefit vs. V.42bis
with real-world web pages. (More if the web pages are mostly HTML, less
if they are heavy on graphics.)
But with your all-a file, I predict no difference with V.44 vs V.42bis;
both can compress such a file infinitely (or a close enough
approximation to infinity such that the compression algorithm
is NOT the salient bottleneck.)