wardc@banana.cse.eng.auburn.edu (Christopher Ward) (05/20/91)
Greetings friends in netland. I am currently evaluating some in-house software for a client and would like some "in reality" information on a communications product they are using. Perhaps you can help on one of the questions listed below. Your interest in appreciated. 1) They will be using US Robotics HST/V.42bis 14.4K data compression modems for communications, these modems automatically step down to slower speeds if the line is of poor quality. The sites may be anywhere in the US. Does anyone know approx % of connections or time that modems will slow down, and to what extent (perhaps there has been a study in ..?) E.g. 5% of connections can be expected to only operate at 4.8K. 2) Again, with the modems above. I was experimenting by sending data records between stations. The data was 1K records of mostly spaces which I would have thought would be compressed. Just for kicks I decided to change the records to be random characters instead (random typing on the keyboard). Suprise! The transfer times were exactly the same. It would seem that either the compression algorithm is very efficient or not working! And yes, I did have the modem's compression enabled (&K3 for those in the know). Any ideas? I will follow up with any pearls of wisdom I receive. Thanks Chris Ward -- INTERNET: wardc@eng.auburn.edu US-MAIL: CSE Dept. Auburn University, Auburn, AL 36847 PHONE: (205) 844-6320
wardc@banana.cse.eng.auburn.edu (Christopher Ward) (05/23/91)
I received a little information regarding high speed transfers. Apparently no-one has had any problems with noisy lines causing the 14.4K V42bis modems to fall-back to slower rates - comments anyone? Regarding the transfer rates for compression. One observation made was whether the modem was being sent data fast enough to bother with compression. The source/dest's are 286 using the 38400 bps transfer rate. I use Y-Modem G for the transfers and it records a transfer rate of 3200 bytes/sec = 25600 bps. Since the modem is 14.4K this would seem to indicate compression was taking place. But, I am still unclear as to why sending all blanks vs "random" data should come out to be _exactly_ the same. Chris Ward Please post replies or mail to wardc@eng.auburn.edu -- INTERNET: wardc@eng.auburn.edu US-MAIL: CSE Dept. Auburn University, Auburn, AL 36847 PHONE: (205) 844-6320
rdthomps@vela.acs.oakland.edu (Robert D. Thompson) (05/23/91)
In article <28675@uflorida.cis.ufl.EDU> wardc@banana () writes: >I received a little information regarding high speed transfers. > [...] > >Regarding the transfer rates for compression. One observation made was >whether the modem was being sent data fast enough to bother with >compression. The source/dest's are 286 using the 38400 bps transfer [...] I have a related question... Do modems with V.42 compression cause compressed files (e.g. PKZIP, LHARC, etc...) to become effectively larger when transferred? In other words, is there negative compression when transferring a compressed file via V.42? Thanks. --- Robert
sdkuo@argo.acs.oakland.edu (Steven D. Kuo) (05/23/91)
In article <28675@uflorida.cis.ufl.EDU>, wardc@banana.cse.eng.auburn.edu (Christopher Ward) writes: >Apparently no-one has had any problems with noisy lines causing the >14.4K V42bis modems to fall-back to slower rates - comments anyone? If an HST does slow down due to a poor connection it will not let you know. You may notice a slower transfer rate if there is a poor connection. The only other way to see the speed change is to type +++, and then type ATI6 which will print a link diagonistics screen. This will show the current connect rate at that time. Since the connection rate is mostly at 14.4K, you will seldom see anything else. Steven D. Kuo VMS: sdkuo@argo.acs.oakland.edu Ultrix: sdkuo@vela.acs.oakland.edu Oakland University, Rochester, Michigan, USA
curt@cynic.wimsey.bc.ca (Curt Sampson) (05/23/91)
In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: > Do modems with V.42 compression cause compressed files (e.g. > PKZIP, LHARC, etc...) to become effectively larger when > transferred? In other words, is there negative compression > when transferring a compressed file via V.42? Well, V.42 is an error correcting scheme. It does introduce a certain amount of "compression" when it strips the start and stop bits, generally giving you about a 15% increase in bps rates no matter what you transfer. V.42 is often paired with MNP-5, which is a compression scheme. Yes, MNP-5 can slow down your transfers if you transfer stuff that's already compressed. V.42bis, which has its own compression as well as error correction (thus avoiding the need for MNP-5) will detect compressed files and transfer them as is, rather than attempting to compress them and expanding them in the process. cjs -- Curt Sampson | "[Atari's Race Drivin'] is more fun as a perverse curt@cynic.uucp | sort of flight simulator than a driving game." curt@cynic.wimsey.bc.ca | --Kevin Nomura (chow@netcom.com)
cg108dbd@icogsci1.ucsd.edu (Steve -Social Hacker) (05/23/91)
--=}>> On 22 May 91 22:21:30 GMT, rdthomps@vela.acs.oakland.edu (Robert D. Thompson) said: In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: RDT> In article <28675@uflorida.cis.ufl.EDU> wardc@banana () writes: >I received a little information regarding high speed transfers. > RDT> [...] > >Regarding the transfer rates for compression. One observation made was >whether the modem was being sent data fast enough to bother with >compression. The source/dest's are 286 using the 38400 bps transfer RDT> [...] RDT> I have a related question... RDT> Do modems with V.42 compression cause compressed files (e.g. RDT> PKZIP, LHARC, etc...) to become effectively larger when RDT> transferred? In other words, is there negative compression RDT> when transferring a compressed file via V.42? RDT> Thanks. RDT> --- RDT> Robert Well, I am no expert, and have just started using my HST w/ V.42. I have yet to see V.42 slow things down, and I usually transmit .ZIP or .GIF files, which are very compressed. My usually xfer speed is 1600-1720 bytes/sec on large files. (>200K) 1730 is the highest I have ever seen (last night :) and it rarely drops below 1580 (multi-node BBS's mostly). With V.42 off, the speeds are much closer to 1500 or so (1400-1550?). In the USR manual, it states that V.42 can _not_ take longer than non-V.42, and I am inclined to believe it. Oh, I have transfered a files-list that was NOT compressed (about 30K) and the transfer speed was 2650 bytes/sec and rising when the transfer finished! Wow. I have the DCE-DTE link locked at 38400 baud and am using ProComm+ v2.0, and have had similar results with DSZ. Of course, you mileage can, nay, WILL vary, so take this all with a grain of statistical salt. I have had no need to use MNP[1-5], so I can't comment there. Hope this helps. Good Luck! -Steve -- }>> Steve Haehnichen <<{ shaehnichen@ucsd.edu Disclaimer: UCSD and I do not share any opinions.
tnixon@hayes.uucp (05/23/91)
In article <6536@vela.acs.oakland.edu>, rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: > Do modems with V.42 compression cause compressed files (e.g. > PKZIP, LHARC, etc...) to become effectively larger when > transferred? In other words, is there negative compression > when transferring a compressed file via V.42? Any compression scheme will expand data that does not have enough redundancy in it, simply because of the overhead required to pass the data through the encoding scheme. This can happen if the data is pre-compressed, or simply random by nature (e.g., object code). V.42bis provides the ability for the transmitting modem to signal the receiving modem that it wants to switch from sending the original data (in the clear) to sending the encoded (compressed) data, and vice-versa. It is also possible, but not required, for V.42bis modems to monitor their transmitter performance, and determine when the compressed data requires more bits than the uncompressed data. V.42bis modems that incorporate such a performance monitoring function can use the mode-switching function to send the uncompressed stream instead of the compressed stream, if that happens to be more efficient at the time. I must point out that the parameters of this performance monitoring function and the decision points as to when to change modes are NOT a subject of V.42bis -- not a part of the standard. The reason this was left open is that it's NOT a compatibility issue -- the modems WILL accurately transfer data, even if they never switch modes when performance degrades. The monitoring of performance and switching of modes is a PERFORMANCE issue, and whenever possible the standards committees try to leave these things open for the creativity of implementors to shine through a differentiate well-engineered products from those that aren't. Therefore, this is an area where you will see performance differences between manufacturers (and it is not the only such area in V.42bis). -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
lstowell@pyrnova.pyramid.com (Lon Stowell) (05/24/91)
In article <1991May23.040723.18039@cynic.wimsey.bc.ca> curt@cynic.wimsey.bc.ca (Curt Sampson) writes: > >Well, V.42 is an error correcting scheme. It does introduce a certain >amount of "compression" when it strips the start and stop bits, >generally giving you about a 15% increase in bps rates no matter what >you transfer. Any V.22bis or V.32 modem does this....or any other phase modulated modem. Async data is NOT transferred end to end as a bit stream. It is converted to a sync format and xmitted. Any modem that needs to be configured for bits/character, parity and/or async DTE baud rate is converting the data...and recreating it at the far end.
rdippold@cancun.qualcomm.com (Ron Dippold) (05/24/91)
In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: > Do modems with V.42 compression cause compressed files (e.g. > PKZIP, LHARC, etc...) to become effectively larger when > transferred? In other words, is there negative compression > when transferring a compressed file via V.42? First, V.42 is only error correction, V.42bis is compression. However, V.42 is smart enough to realize when the compression is causing the data to expand and will send the data un"compressed". -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
atc@waikato.ac.nz (05/24/91)
In article <1991May23.193607.14738@qualcomm.com>, rdippold@cancun.qualcomm.com (Ron Dippold) writes: > In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: >> Do modems with V.42 compression cause compressed files (e.g. >> PKZIP, LHARC, etc...) to become effectively larger when >> transferred? In other words, is there negative compression >> when transferring a compressed file via V.42? > > First, V.42 is only error correction, V.42bis is compression. However, V.42 > is smart enough to realize when the compression is causing the data to expand > and will send the data un"compressed". > So do all compressed files expand or only some? i.e. if i'm only interested in sending compressed files, then is v42bis a waste of time? Your answer keenly awaited as I have on order a v22bis/v42bis modem. -- Andrew Chambers Computer Services University of Waikato New Zealand ATC@WAIKATO.AC.NZ
curt@cynic.wimsey.bc.ca (Curt Sampson) (05/24/91)
In article <156460@pyramid.pyramid.com> lstowell@pyrnova.pyramid.com (Lon Stowell) writes: > In article <1991May23.040723.18039@cynic.wimsey.bc.ca> curt@cynic.wimsey.bc.ca (Curt Sampson) writes: > > > >Well, V.42 is an error correcting scheme. It does introduce a certain > >amount of "compression" when it strips the start and stop bits, > >generally giving you about a 15% increase in bps rates no matter what > >you transfer. > > Any V.22bis or V.32 modem does this....or any other phase > modulated modem. Async data is NOT transferred end to end as > a bit stream. It is converted to a sync format and xmitted. > > Any modem that needs to be configured for bits/character, > parity and/or async DTE baud rate is converting the data...and > recreating it at the far end. Wrongo. NO V.22bis or V.32 modem, unless it includes V.42 or MNP levels 3 and above, is stripping start and stop bits. (And they do not need to be configured for bits/character or parity unless they are using V.42 or MNP levels 3 and above). MNP3, MNP4 and V.42 all strip start and stop bits. cjs -- Curt Sampson | "[Atari's Race Drivin'] is more fun as a perverse curt@cynic.uucp | sort of flight simulator than a driving game." curt@cynic.wimsey.bc.ca | --Kevin Nomura (chow@netcom.com)
curt@cynic.wimsey.bc.ca (Curt Sampson) (05/24/91)
In article <1991May23.193607.14738@qualcomm.com> rdippold@cancun.qualcomm.com (Ron Dippold) writes: > In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: > > Do modems with V.42 compression cause compressed files (e.g. > > PKZIP, LHARC, etc...) to become effectively larger when > > transferred? In other words, is there negative compression > > when transferring a compressed file via V.42? > > First, V.42 is only error correction, V.42bis is compression. However, V.42 > is smart enough to realize when the compression is causing the data to expand > and will send the data un"compressed". V.42 will "compress" everything by about 15% (by stripping the start and stop bits), period. It workes equally well on compressed and non-compressed files. If you are using V.42bis compression, it will detect if the compression is actually increasing trasfer time and will not compress. If you are using MNP-5 compression, which is quite common with V.42, it will *increase* transfer time on compressed files, because it does *not* check to see whether the compression is ineffective or not. Using V.42 will not help this situation at all. cjs -- Curt Sampson | "[Atari's Race Drivin'] is more fun as a perverse curt@cynic.uucp | sort of flight simulator than a driving game." curt@cynic.wimsey.bc.ca | --Kevin Nomura (chow@netcom.com)
tnixon@hayes.uucp (05/24/91)
In article <156460@pyramid.pyramid.com>, lstowell@pyrnova.pyramid.com (Lon Stowell) writes: > In article <1991May23.040723.18039@cynic.wimsey.bc.ca> curt@cynic.wimsey.bc.ca (Curt Sampson) writes: >> >>Well, V.42 is an error correcting scheme. It does introduce a certain >>amount of "compression" when it strips the start and stop bits, >>generally giving you about a 15% increase in bps rates no matter what >>you transfer. > > Any V.22bis or V.32 modem does this....or any other phase > modulated modem. Async data is NOT transferred end to end as > a bit stream. It is converted to a sync format and xmitted. > > Any modem that needs to be configured for bits/character, > parity and/or async DTE baud rate is converting the data...and > recreating it at the far end. Not exactly true. If you use a V.22, V.22bis, V.26ter, V.32, or V.32bis modem in its "async" mode (using V.14 async-to-sync conversion), then, yes, you are actually still transmitting synchronously on the phone line. But the start and stop bits of each character are STILL sent with the data -- you still send 10 bits per character (in most applications). Thus, a V.32 modem operating in "async" mode at 9600 bps sending user data that is 8 data bits, no parity, and one stop bit can send at most 960 characters per second. Using V.42 error control, however, the start and stop bits are actually removed from the individual characters, and, instead, the characters are packetized with frame headers and trailers. Instead of the 20% overhead of individual start and stop bits, these protocol elements typically add only about 1% overhead to the data. Thus, a V.32 modem operating in error control mode at 9600bps, sending user data that is 8 data bits, no parity, and one stop bit, can send approximately 1150 characters per second. The difference is that in one case the start and stop bits are simply aligned with the synchronous clocks of the underlying modem to allow them to be transferred on the link, but in the other case the start and stop bits are completely removed on the phone line and reconstructed on the other end. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
shihsun@phoenix.Princeton.EDU (S. Spencer Sun) (05/24/91)
In article <28675@uflorida.cis.ufl.EDU> wardc@banana () writes: >Apparently no-one has had any problems with noisy lines causing the >14.4K V42bis modems to fall-back to slower rates - comments anyone? No problems here... I have the latest HST Dual Standard... it automatically falls back on bad conditions, but it also steps up when it senses that the conditions have improved.
lstowell@pyrnova.pyramid.com (Lon Stowell) (05/25/91)
In article <1991May24.095529.101@cynic.wimsey.bc.ca> curt@cynic.wimsey.bc.ca (Curt Sampson) writes: > >Wrongo. NO V.22bis or V.32 modem, unless it includes V.42 or MNP >levels 3 and above, is stripping start and stop bits. (And they do >not need to be configured for bits/character or parity unless they are >using V.42 or MNP levels 3 and above). MNP3, MNP4 and V.42 all strip >start and stop bits. > As either Toby or some other modem guru pointed out in private email, the CCITT compliant modems strip only the stop bits...and in V.22bis are not to strip more than 1 in 8. The method is documented in V.22bis, and is unrelated to data compression. I know of no 2400 baud or above full dux dial modem that doesn't need to know about character length and rate. Whether it is explicitly configured or auto-configured...the AT sequence makes a pretty decent autobaud...
rdippold@cancun.qualcomm.com (Ron Dippold) (05/25/91)
In article <1991May24.181546.3802@waikato.ac.nz> atc@waikato.ac.nz writes: >In article <1991May23.193607.14738@qualcomm.com>, rdippold@cancun.qualcomm.com (Ron Dippold) writes: >> In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: >>> Do modems with V.42 compression cause compressed files (e.g. >>> PKZIP, LHARC, etc...) to become effectively larger when >>> transferred? In other words, is there negative compression >>> when transferring a compressed file via V.42? >> >> First, V.42 is only error correction, V.42bis is compression. However, V.42 >> is smart enough to realize when the compression is causing the data to expand >> and will send the data un"compressed". >> >So do all compressed files expand or only some? >i.e. if i'm only interested in sending compressed files, then is v42bis a waste >of time? > >Your answer keenly awaited as I have on order a v22bis/v42bis modem. The bottom line is that it _can't_ hurt you. And it is definitely a help in most cases. It depends on the modem's implementation, but many files that are compressed also have sections that aren't compressed (the individual file headers, etc.) and sometimes the V.42bis can compress other parts slightly better depending on the packer. I get about 1700 cps with V.42bis turned on and about 1500 cps with it turned off on a typical transfer. In addition, once you have V.42bis and the other side is using it, there are times when it is not worth it to use a packer, the V.42bis will speed things up enough. So you just send that text file instead of having to pack it first. More and more modems in the 2400 bps range are showing up with V.42bis, and there are plenty of high speed modems with it. I'd say it's definitely worth it. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
wardc@banana.cse.eng.auburn.edu (Christopher Ward) (05/25/91)
I have been watching with interest the follow up's to my original article on Using High Speed Modems. Thanks to those of you you contributed. The general e-mail consensus regarding data rates seems to be that transmission at slow rates (due to line noise) hardly ever occurs. It was also pointed out that it since this occurs automatically, one might not know. This issue may seen unimportant, until one pays the phone bill :-( Chris Ward -- INTERNET: wardc@eng.auburn.edu US-MAIL: CSE Dept. Auburn University, Auburn, AL 36847 PHONE: (205) 844-6320
dwh@twg.com (Dave W. Hamaker) (05/31/91)
tnixon@hayes.uucp writes: >In article <6536@vela.acs.oakland.edu>, >rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: >> Do modems with V.42 compression cause compressed files (e.g. >> PKZIP, LHARC, etc...) to become effectively larger when >> transferred? In other words, is there negative compression >> when transferring a compressed file via V.42? >Any compression scheme will expand data that does not have enough >redundancy in it, simply because of the overhead required to pass >the data through the encoding scheme. This can happen if the data >is pre-compressed, or simply random by nature (e.g., object code). >.... This is really an aside, but I'd like to point out that object code is not random. We tend to think of it in those terms simply because it is not designed for direct consumption by people; we just imagine it looks like random jiberish when we make a mental picture of object code as byte stream. In my experience, object code compresses quite well. -Dave Hamaker dwh@twg.com
tnixon@hayes.uucp (05/31/91)
In article <8998@gollum.twg.com>, dwh@twg.com (Dave W. Hamaker) writes: > tnixon@hayes.uucp writes: > >>Any compression scheme will expand data that does not have enough >>redundancy in it, simply because of the overhead required to pass >>the data through the encoding scheme. This can happen if the data >>is pre-compressed, or simply random by nature (e.g., object code). > > This is really an aside, but I'd like to point out that object code is > not random. We tend to think of it in those terms simply because it is > not designed for direct consumption by people; we just imagine it looks > like random jiberish when we make a mental picture of object code as > byte stream. In my experience, object code compresses quite well. Of course you're right. It doesn't compress as well as text, but depending on the source language and compiler you will see a lot of instructions used frequently (particular short jumps) that do indeed compress well. There are other types of files that aren't intended for human consumption that also compress extremely well, such as spreadsheets and dBase files (lots of filler). -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net