Thread captured on Compuserve's IBMNET Communication forum (IBMCOM) collected
and edited by Ray Tackett, 76416,276
#: 90421 S7/Modems/Comm Hdw [C]
12-Jan-92 22:14:06
Sb: #need v.32/bis tutorial
Fm: John Kelley 73467,450
To: All
I hope I can prevail upon the scholars of vee-dot lore to clear up some
questions I have about v.32/bis and v.42/bis. I *think* I know the names that
belong to the various vee-dots, but I want to know how some of it is supposed
to work, in a v.32 or v.32bis connection, i.e.:
1. Can a v.42 EC connection be made without v.42bis compression, in a case
where the answer modem starts out expecting compression? In other words, when
an answering modem insists on supplying v.42bis data compression with its v.42
error-correction, can you (as the caller) successfully accept the EC without
being forced to take the compression? (Am I making sense here?)
2. (Same question, substitute "MNP4" for v.42 and "MNP5" for v.42bis.)
I'm asking because I notice that I connect very successfully to CIS using v.32
and v.42, and I have the impression from past messages that CIS is not
providing compression. On my system, with a limited port speed, that's just
fine. When I call other remote systems I get compression, even if I don't
want it. So, under the v.rules, should I have the right to refuse it, without
giving up EC? --- Thanks for any enlightenment! -- John K.
#: 90535 S7/Modems/Comm Hdw [C]
13-Jan-92 16:15:27
Sb: #90421-#need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: John Kelley 73467,450 (X)
Here's a brief glossary of the v dot ccitt specs that are of interest:
V.32 Full duplex 9600 bps, with fallback to 4800 bps as required
V.32bis Idem, plus 14.4k, 12k and 7.2k bps speeds. Better negotiation
V.42 Error control
V.42bis Compression. Must run under v.42
Then, there are the mnp 'classes':
Mnp 1 Half duplex error control. Seldom used or seen
Mnp 2 Full duplex error control
Mnp 3 Idem, plus packetizing of data. Strips start/stop bits.
Mnp 4 Idem, plus improvements to reduce overhead
Mnp 5 Compression under mnp
When the two modems negotiate, the answering modem will first negotiate the
highest possible common speed, then v.42 (assuming it has v.42), or go to mnp.
Then, if the answering modem has v.42bis compression it will ask the other
modem if it is capable (or willing), and will enable compression if so.
The CompuServe v.32 nodes do have compression, v.42bis (not mnp5, by the way,
though they do have mnp4), but given the network limitations, the port speed of
the nodes is locked at 9600 bps. So, compression offers no benefits. Both
ends must have port speeds >9600 bps for compression to be of any value.
-er
#: 90668 S7/Modems/Comm Hdw [C]
14-Jan-92 02:39:44
Sb: #90421-need v.32/bis tutorial
Fm: Toby Nixon 70271,404
To: John Kelley 73467,450 (X)
Yes, you can most definitely establish an error control connection without
data compression, even if both modems actually do support data compression.
Most modems provide a separate command/parameter to enable/disable compression
independently of enabling/disabling error control. If both modems have error
control enabled but only one has data compression enabled, they will connect
with error control and without compression.
-- Toby
#: 90618 S7/Modems/Comm Hdw [C]
13-Jan-92 23:22:05
Sb: #90535-#need v.32/bis tutorial
Fm: Tom Brandt 70650,1742
To: earle robinson [ibmeur] 76004,1762 (X)
Earle,
Could you answer a dumb question:
What is idem (as in V.32bis)?
Tom.
#: 90686 S7/Modems/Comm Hdw [C]
14-Jan-92 08:00:13
Sb: #90535-#need v.32/bis tutorial
Fm: Ken Levy 72331,3403
To: earle robinson [ibmeur] 76004,1762 (X)
I assume when you say that the port speed on the CIS side is locked at 9600
bps, that you mean the interface between the modem/packet net gateway (in
CIS's computer room) and CIS's computers? I was under the impression that the
speed of all links (whether or not you use V.42bis) was at the base modulation
rate (9.6k w/v.32 or 14.4k w/v.32bis) and transmission/signaling over the
phone lines only occurs at that rate. Although the compression may encode
more bits into a smaller set of tokens, the stream goes through the pipe at
the same speed (9.6 or 14.4). The gateways between the hosts and the modems
on each end must be set up to go faster to get the uncompressed data down to
the modem where it can be compressed/decompressed to go over the line at the
standard (9.6 or 14.4) speed. While CIS's modems will talk at the higher
effective rates (i.e., support v.42bis), their host mainframes are limited to
9.6k rate between the mainframe and their modem. Is it correct to assume that
the 9.6 locking is not a function of the packet network (which would only be
sending data through the pipe between the modems at 9.6k, regardless of
compression) but rather of the host hardware/software interface?
ME MODEM Line, Packet net, Line MODEM CISmainframe
A---38k-------B------------------9.6K----------------C---9.6k------D
In other words, A-B above goes at 38k (or as fast as modem will accept data),
modem compresses the data and will push it onto the line at B at 9.6K, CIS's
modem will decompress at C, but their host D will only accept at 9.6K, thus
the limit on throughput?
#: 90669 S7/Modems/Comm Hdw [C]
14-Jan-92 02:39:49
Sb: #90618-#need v.32/bis tutorial
Fm: Toby Nixon 70271,404
To: Tom Brandt 70650,1742 (X)
"idem" is, I think, one of those arcane Latin abbreviations used in footnotes
which means "same as the above with the following exceptions", or something
like that. I think Earle meant for it to say "V.32bis is the same as V.32,
plus the following".
-- Toby
#: 90752 S7/Modems/Comm Hdw [C]
14-Jan-92 16:07:35
Sb: #90669-#need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: Toby Nixon 70271,404 (X)
Arcane, not at all. Look in your dictionary and the meaning is there, without
reference to it being arcane. Toby, I didn't realize you were so
anti-intellectual! -er
#: 90890 S7/Modems/Comm Hdw [C]
15-Jan-92 09:46:02
Sb: #90669-need v.32/bis tutorial
Fm: Tom Brandt 70650,1742
To: Toby Nixon 70271,404 (X)
Ancient Latin technospeak always crosses me up <G>.
#: 90753 S7/Modems/Comm Hdw [C]
14-Jan-92 16:07:45
Sb: #90686-#need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: Ken Levy 72331,3403 (X)
Your understanding is correct. I'd only add that using 38.4k bps between the
computer and modem is a waste of resources, and often not tolerated by many
systems. I'll also add that a uart with larger i/o buffers than the standard
82450 usually mounted, i.e. the ns 16550a uart, is a very good idea, too.
The locking at the link speed, 9600 bps, is simply because the network
backbone can't handle higher speeds without penalizing overall throughput. I
imagine that with ds3 becoming more widespread, and the highly touted frame
relay, we may see the v.32 nodes with higher port speeds eventually. -er
#: 90842 S7/Modems/Comm Hdw [C]
15-Jan-92 00:45:25
Sb: #90752-#need v.32/bis tutorial
Fm: Toby Nixon 70271,404
To: earle robinson [ibmeur] 76004,1762 (X)
Oh, I'm not "anti-intellectual". I am, however, strongly in favor of trying to
explain things to people in the clearest and simplest way possible, without
using jargon. While you may disagree, in my book words like "idem" are
academic jargon. They certainly are not in the vocabulary of the typical
American. Heck, _I_ had to guess what it meant (but it was pretty obvious to
me from the context and because I know what I would have written instead).
-- Toby
#: 91099 S7/Modems/Comm Hdw [C]
16-Jan-92 18:12:10
Sb: #90753-#need v.32/bis tutorial
Fm: Scott Compton 71650,2371
To: earle robinson [ibmeur] 76004,1762 (X)
earle,
Pardon me for dropping into your discussion but I don't understand
something you told Ken Levy re: network transmission speed locking.
If the remote node (your PC to node) goes at v.42/bis, the node to CIS
modem (network) goes at 9600 to CIS, CIS pulls down at 9600 w/no v.42/bis.
Okay so far?
My question is; if ds3 and frame relay (whatever those are) increase the
overall speed from your PC to the CIS modem, is CIS *still* going to pull data
off the net at 9600bps w/no v.42 bis? What good will faster connect speeds do
if CIS stays locked at 9600bps? There would just be a massive bit-build-up on
the network while CIS takes data at it's old rate (picture funnel). Seems
like the net would clog up, or whatever nets do when they can't get rid of
data fast enough.
It appears from what I've seen in this thread, CIS needs to get some
v.42/bis modems on it's end of the pipe before anyone starts increasing the
speed of the network --> CIS connection. Wouldn't CIS also have to upgrade
it's hardware (the computers) to accommodate v.42/bis speeds, and then upgrade
_again_ when the network speed went up again?
-Scott
#: 90921 S7/Modems/Comm Hdw [C]
15-Jan-92 13:57:29
Sb: #90842-#need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: Toby Nixon 70271,404 (X)
I'm afraid I can't agree with you about 'idem'. If it were 'academic jargon'
the dictionary would point this out. It doesn't. It is really better for
most people to expand their vocabulary. Alas, that of most americans is indeed
poor, and getting poorer as fewer people read books anymore. I learn new
words all the time, and keep at least a couple of dictionaries handy when the
need arises, which is less often than for some, but rarely does a day or week
pass without a dictionary being pulled down from the shelf to look up
something.
-er
#: 91031 S7/Modems/Comm Hdw [C]
16-Jan-92 09:32:28
Sb: #90921-need v.32/bis tutorial
Fm: Tom Brandt 70650,1742
To: earle robinson [ibmeur] 76004,1762 (X)
Earle,
When I saw "idem" I sincerely thought it was some technical term or acronym
not found in a standard dictionary (try looking up V.32bis in your
Merriam-Webster). I, too, keep a dictionary handy (I have several), but did
not think to look in one since I thought it would be a waste of time.
Tom.
#: *91218 S7/Modems/Comm Hdw [C]
17-Jan-92 17:01:31
Sb: #91099-#need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: Scott Compton 71650,2371 (X)
The modems used by CompuServe on the v.32 nodes already support v.42bis. But
its use is of no use due to the speed being locked to the link one, 9600 bps.
When the v.32 nodes were installed, we were promised that some day the port
speeds would be increased, perhaps in a year. That year has gone by, and they
are still not opened up. I have to assume that the upgrading of the network
backbone and of the host computers, too, in order to permit this. One reason
may be too is that the stampede toward v.32 may have taken CompuServe by
surprise. I doubt they expected so many to move to it so soon.
-er
#: 91221 S7/Modems/Comm Hdw [C]
17-Jan-92 17:16:48
Sb: #91099-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: Scott Compton 71650,2371 (X)
I think you've got the system layout wrong. It is:
Compuserve computer - high speed network (including thinks like DS1/3) -
access node with several modems (9600, V.42bis etc.) - telephone line - your
modem - your computer.
Speeding up the network will allow more simultaneous users and/or higher
speeds per user - the V.42bis part is at the user end of the network. Speed
locking occurs between the access node PAD and the modems.
Fred
#: 91359 S7/Modems/Comm Hdw [C]
18-Jan-92 17:40:34
Sb: #91218-#need v.32/bis tutorial
Fm: Scott Compton 71650,2371
To: earle robinson [ibmeur] 76004,1762 (X)
Thanks, earle and 'Fred,'
I understood that the modems CIS uses already support v.42/bis.
The host and the net are the limiting factor, currently, as I
understand it?
CIS today:
v.32 v.32 v.32 only v.32 v.32 only
v.42/bis v.42/bis v.42/bis
[me]-------[local node]-----????net?????-----[CIS modem]--[CIS Host]
can't use won't use upgrading for won't use upgrading
v.42/bis v.42/bis faster modulation v.42/bis for v.42/bis
CIS considering:
v.32 v.32 v.32 only v.32 v.32 only
v.42/bis v.42/bis v.42/bis
[me]-------[local node]-----????net?????-----[CIS modem]--[CIS Host]
v.42/bis still not upgraded for
necessary, data higher data
already compressed. throughput.
Upgrading for even --> Must also
faster data rate --> upgrade again
(Frame relay/DS1/3) --> to handle the
--> data rate
--> DS1/3 & Frame
--> relay allow.
Do I have it right, or am I still totally lost? <G>
-Scott
#: 91682 S7/Modems/Comm Hdw [C]
20-Jan-92 12:50:16
Sb: #91221-need v.32/bis tutorial
Fm: Len CONRAD, Paris 71251,462
To: 'Fred' Kirby [UK] 70734,126
So even if CIS has v.32bis/14.4 modems, they've been 'locked' to work at
v.32/9600 max and lower speeds? Salut,Len.
#: 91479 S7/Modems/Comm Hdw [C]
19-Jan-92 11:33:52
Sb: #91359-#need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: Scott Compton 71650,2371 (X)
You'r right except that there are no modems as such to connect the network
into the CIS computers - it will be more of a direct interface - V32 and V42
have no relevance here.
The network link may have a capacity of several megabits per second but it
will have to carry a number of calls at once (multiplexed). If it is 1Mbit/sec
and you expect it to carry 100 calls then each call must average somewhat less
than 10Kbits/sec due to network overheads. If you improve the end modems so
that they are individually capable of a greater capacity then the network must
be improved to cope.
Generally speaking data compression is a function of the modems. The network
will not pass data compressed unless given it that way by the host (e.g. when
file transferring .ZIP archives). Compression requires fairly capable
processors in modems - at network speeds it would probably require a
super-computer!
Fred
#: 91568 S7/Modems/Comm Hdw [C]
19-Jan-92 19:54:16
Sb: #91359-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: Scott Compton 71650,2371 (X)
I'm sorry, but I don't understand your message at all. But, I'll repeat what I
thought I have been trying to say:
v.32 with v.42bis port speeds are locked at 9600 bps, so no advantage
to the compression.
v.22bis with mnp port speed locked at 2400 bps. No compression offered.
-er
#: 91569 S7/Modems/Comm Hdw [C]
19-Jan-92 19:54:26
Sb: #91479-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: 'Fred' Kirby [UK] 70734,126
Compression is indeed at the modem, but is only of benefit if the speed
between the dce and dte is higher, and at both ends. The network backbone if
it has the bandwidth would be able to then support the higher dte/dce speeds.
Today this is not the case. Tomorrow?
The network does no compression at all, and I know of no plans to do so. It
certainly isn't defined or used at any of the iso levels, though it wouldn't
be impossible to implement. -er
#: 91720 S7/Modems/Comm Hdw [C]
20-Jan-92 17:32:56
Sb: #91569-#need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: earle robinson [ibmeur] 76004,1762 (X)
Data compression can be of benefit on a noisy line - retransmissions will
effectively reduce the bandwidth but compression can restore it to the full
value. Similarly I've seen my modem fall back to 7200 baud - compression kept
the data throughput at its normal value.
I wouldn't expect a high speed network to compress data - the host and user
are in a far better position to determine if the data is worth compressing in
the first place. It makes throughput of the network even harder to predict.
Fred
#: 91721 S7/Modems/Comm Hdw [C]
20-Jan-92 17:33:02
Sb: #91682-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: Len CONRAD, Paris 71251,462
Just about. The modems may or may not be locked to V.32. What definitely is
locked is the speed of the serial line between the modem and the multiplexor.
V.32 just defines the series of pops and whistles the modems use to
communicate with each other - they could connect at V.32bis/14400 but the full
line capacity in that case couldn't be used. It WILL however reduce the
turnaround delays (the data packets take a finite time to send increasing the
line speed will reduce that delay).
In real terms this means that a file transfer protocol such as Kermit or
Xmodem might benefit.
Fred
#: 91742 S7/Modems/Comm Hdw [C]
20-Jan-92 19:14:58
Sb: #91720-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: 'Fred' Kirby [UK] 70734,126
A noisy line means retransmissions, and too many of them will penalize
throughput immensely, and eventually lead to dropping of the line, usually
after 10 successive resends of the same packet. Compression is no more a
benefit then than it is on a clean line. For compressible data, it will
increase the effective throughput. But, whatever happens that modem is only
transmitting 9600 bits per second, and if it must repeat one or more frames,
those still go through at 9600 bits per second. Remember that a noisy line
for data communications really only means 1 bad bit out of 1000 at most. Any
more than that and the communication is lost or so crippled to make it seem
so.
One thing that people forget is that the modem itself is responsible for
handling the various line problems that may occur, including phase jitter,
amplitude jitter, etc. If that filtration isn't optimum, no error control
willl compensate for the poor performance of the modem itself. Except in very
special cases, a clean line for voice calls is quite adequate for data
communications. -er
#: 92049 S7/Modems/Comm Hdw [C]
22-Jan-92 08:37:32
Sb: #91956-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: 'Fred' Kirby [UK] 70734,126
I thought I made my point clear: Compression will improve effective
throughput on *any* line. A bad line will reduce throughput due to resends.
So, you use compression to get higher throughput, assuming the data is
compressible of course, not because the line is bad. Anyway, if it is bad,
you are likely to lose the connexion, or get such a poor one that you might do
better with federal express or ups.
Note that v.32 doesn't fall back to 7200 cps, that is a feature of v.32bis,
but to 4800 cps. My experience, for what it's worth, using phone lines here in
europe and in the states, is that if the line is so mediocre, it is more
likely lost rather than a drop to a lower speed. I should add, that v.32bis
has one advantage over v.32, too. It permits stepping back up to a higher
speed after a dropback, in case the line conditions improve. And, there is no
full retrain required, as with v.32. I find there is a greater likelihood of
retraining required, which takes several seconds, than a fallback, so v.32bis
is of interest in this regard. -er
#: 92050 S7/Modems/Comm Hdw [C]
22-Jan-92 08:37:42
Sb: #92024-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: Jack Jordan 70743,2663
V.42bis has two advantages over mnp 5. First, it uses a better algorithm, so
can compress data more. It also does a continual verification of the data to
see if there is redundancy, and if there is none, will not try to compress the
data. -er
#: 92155 S7/Modems/Comm Hdw [C]
22-Jan-92 21:05:24
Sb: #92024-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: Jack Jordan 70743,2663
I agree - networks don't compress - they try to be as cheap as possible!
What do you mean by 'multiple levels of compression'? You can't generally
compress data which has already been compressed - it comes out larger! Typical
compression schemes do use a combination of methods but they have to be
carefully interfaced to work effectively. A lot depends on the type of data
that is being transmitted. If you have a custom compression routine tailored
to 'very compressible' data then you'll do very well. Good compression schemes
may vary from 2:1 to 4:1 for object code or ASCII text. When people talk about
4:1 compression from V.42bis they are usually using trivial data. The best
archivers aren't that good. I've seen 'average' figures quoted as 2.3:1 for
V.42bis and 1.8:1 for MNP5. Although very wooly this seems to accord with my
experience.
What is it you don't understand - the type of compression used or where data
is transferred compressed?
Fred
#: 92136 S7/Modems/Comm Hdw [C]
22-Jan-92 19:42:27
Sb: #92049-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: earle robinson [ibmeur] 76004,1762
That's not quite true - the point is that with CIS there is a ceiling on
throughput of 9600 baud so compression on a clean link will produce no benefit
(other than perhaps on turnaround times) but compression on a bad link can be
very beneficial because it can keep the actual data rate up to 9600bps
(assuming compressible data etc.)
No doubt you are right about 7200 fallback - I do have a V.32bis modem. The
type of line impairment is very important. 'Bursty' noise will knock out the
odd block but the link will keep going. International calls in particular can
have a high hiss making the dynamic range insufficient for 9600baud but still
adequate for 4800.
I find fall forward very useful. Sometimes a connection takes a 10 seconds or
so to settle down. If the mode can't fall forward then it is stuck at the
lower speed for no good reason.
Fred
#: 92343 S7/Modems/Comm Hdw [C]
24-Jan-92 00:22:12
Sb: #92050-need v.32/bis tutorial
Fm: Jack Jordan 70743,2663
To: earle robinson [ibmeur] 76004,1762 (X)
Earle Thanks for the reply. I'm fascinated by the processing now resident in
modems. If I continue to follow these discussions I may learn something yet.
Thanks -jrj
#: 92156 S7/Modems/Comm Hdw [C]
22-Jan-92 21:05:28
Sb: #92079-#need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: SysOp Jim McKeown 76702,1102 (X)
It needn't make much difference where the data is compressed. If the data is
compressed in the modem then the link between modem and computer needs to be a
higher capacity to carry the uncompressed data but this is not usually a
problem.
The computer may have specialised compression for the particular type of data
being transferred. In this case it will be better than the generalised modem
compression. The modem can only see the data as a single 1 pass stream. It
might be that the computer can make a better job at compression by using
several passes. Real compression schemes don't seen to require much of this.
Fred
#: 92220 S7/Modems/Comm Hdw [C]
23-Jan-92 06:12:48
Sb: #92079-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: SysOp Jim McKeown 76702,1102
No question that a precompressed file is better, if it feasible to run that
way. Sometimes, however, for security reasons, or because huge amounts of
data must be transmitted, online compression is a better choice. -er
#: 92344 S7/Modems/Comm Hdw [C]
24-Jan-92 00:22:27
Sb: #92155-need v.32/bis tutorial
Fm: Jack Jordan 70743,2663
To: 'Fred' Kirby [UK] 70734,126
Fred
I'm (relatively) new to PC's and the networking involved. Thus, all of the
discussions in this forum are new to me.
We do use compression on our IBM, Amdahl & HDS mainframes running MVS, but it
is all host based. As to your reference to trivial data, that is true. We
move large pricing and inventory data. This is guaranteed not to be designed
to be compact or efficient.
The software used is an IBM product called FTP. It has a native compression
routine. With our large files, FTP does give reasonable compression.
However, when we add on another two levels (different algoritims), the
transmission is markedly reduced. For these data files, the compression can
give us up to four or five fold decrease in xmit times.
As far as the discussion here, I am learning that the compression is in the
modem, and that there are negotiated levels of this compression.
Keep up your conversations, they are very enlightening to a mainframe bigot
like myself. Hopefully you don't mind questions from folks like me.
Regards -jrj
#: 92161 S7/Modems/Comm Hdw [C]
22-Jan-92 21:12:28
Sb: #92156-need v.32/bis tutorial
Fm: SysOp Jim McKeown 76702,1102
To: 'Fred' Kirby [UK] 70734,126
I suppose it *need* not make much difference, Fred, but I just recently saw a
report in one of the mags where there was a very substantial difference in the
effective file size transferred (and hence the speed) between standalone ZIP
then transfer vs using the modem's compression.
jcm
#: 92382 S7/Modems/Comm Hdw [C]
24-Jan-92 05:03:15
Sb: #92272-need v.32/bis tutorial
Fm: earle robinson [ibmeur] 76004,1762
To: 'Fred' Kirby [UK] 70734,126
I can't envisage an on-the-fly compression scheme being more efficient than a
standalone one, where timing isn't at all so important, especially in the
competitive environment of the compression program market.
You point about the throughput increase achieved through the stripping of the
start/stop bits is quite true, and often overlooked.
Given the system resources required and the better compression achieved by the
best compression programs, use of v.42bis is really limited for most users, to
interactive sessions or when security reasons require sending ascii data.
-er
#: 92455 S7/Modems/Comm Hdw [C]
24-Jan-92 16:33:19
Sb: #92344-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: Jack Jordan 70743,2663
Compressors work on the principle that a file being sent is likely to exist in
a very small subset of all possible bit patterns. A compressor is trying to
transform the data so that elements of that subset are converted into short
files. Correspondingly other files (hopefully outside the subset) are going to
be transformed to larger files. As an indication of how small this subset is
imagine generating, say, a million files of random binary data and putting
each through your 'best' compressor. It may not be able to reduce the size of
any of them. (The likelihood of this depends on file size).
A compressor can map the subset to shorter strings because it maps them to a
greater proportion of the whole bit set. The output of a good compressor will
look almost like random data. This is why putting it through another
compressor is not likely to be very beneficial.
In your case are the compression stages designed to complement each other or
do you just plug the output of one program into the input of another?
Certainly you may require several stages to end up with 'good compression'.
I wonder how compression algorithms in the mainframe world compare with those
on PCs. PCs seem to have a definite industry with compression - perhaps due to
lower capacities generally available.
Fred
#: 92454 S7/Modems/Comm Hdw [C]
24-Jan-92 16:33:12
Sb: #92382-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: earle robinson [ibmeur] 76004,1762
I agree that an on-the-fly compression scheme can't be more efficient than a
good host based one. But I think I can hope to be not far off. An interesting
question is which one needs to be less processor intensive. Even at 38400 baud
the modem one only needs to process under 4000 bytes per second. People now
expect a PC based compressor to squash a 100K file in no time at all. There is
a significant tradeoff to be had between speed and efficiency. Just how fast
are the processors in high speed modems?
Modems compression is useful for online systems - V.42bis would be excellent
for forum navigation but library files would be better pre-compressed. Apart
from anything else the compression would only have to be done once!
I think we're agreed!
Fred
#: 92640 S7/Modems/Comm Hdw [C]
26-Jan-92 00:06:36
Sb: #92455-need v.32/bis tutorial
Fm: Jack Jordan 70743,2663
To: 'Fred' Kirby [UK] 70734,126 (X)
Fred I can't speak to the algorithms of the compressors, but in the case of
our installation the following applies.
Stage 1: IBM routine built into the file transfer application (FTP).
Stage 2: Routine designed by either GE or Westinghouse (I don't remember
which) in the 70's (REMOT370).
Stage 3: Routine designed by a company called ATPCO (Airline Tariff clearing
house) (XMTXOR).
The data is typically airline fares/schedules.
Your question about the efficiency of mainframe vs PC compression is a good
one. My feeling is that if it takes us three compressions to get a good file
then none of the algorithms are likely to be great. It would be interesting
to run a test file through the best of both and check the results.
Regards -jrj
#: 92694 S7/Modems/Comm Hdw [C]
26-Jan-92 09:11:56
Sb: #92640-need v.32/bis tutorial
Fm: 'Fred' Kirby [UK] 70734,126
To: Jack Jordan 70743,2663
Maybe there is a suitable text file in the libraries.
If you have a PC there you could compare both compression systems directly.
Fred