Category : Tutorials + Patches
Archive   : HAYES288.ZIP
Filename : ESOFT.TXT

Output of file : ESOFT.TXT contained in archive : HAYES288.ZIP

[This is from eSoft (TBBS) about the Hayes Optima 288 modems. It is about using
this modem with TBBS, but the performance testing is interesting for all modem

What Kind of Performance Can I expect?

eSoft has been conducting laboratory testing on high speed interfaces to
TBBS 2.2M and our results show that TBBS can support such interfaces very
well indeed. Here are some rough outlines of what we have determined:

1. With a 33Mhz 80486 computer that has no disk caching, a 20ms or
faster IDE disk drive, and a 64k CPU cache (a low end 486, and a
fairly "average" computer in today's market), we find that TBBS
2.2 can support the following connections with no speed loss under
full loading:

a. Four 115.2k hard wired interfaces

b. Nine to Ten 57.6k hard wired interfaces

c. Thirty-two V.FC modems transferring compressed files at 3300cps

2. A 50Mhz ISA bus 80486 with a caching SCSI disk controller and a 256k
CPU cache (the high end of "lower cost systems") can support the
following connections with no speed loss under full load:

a. Nine to Ten 115.2k hard wired interfaces

b. Twenty-four 57.6k hard wired interfaces

c. >64 V.FC modems transferring compressed files at 3300cps (but you
can only hook 64 of them up!)

3. A 66Mhz EISA bus 486 with a caching SCSI disk controller can support
the following connections with no speed loss under full load:

a. Twenty-eight 115.2k hard wired interfaces

b. Sixty 57.6k hard wired interfaces

c. All the V.FC modems you can hook up.

Note: These ratings are the typical conservative "eSoft numbers" for
performance. They mean that you can pump data all day on all lines at the
same time at full speed with less than a 10% speed loss at any moment. In
the real world, you can hook much more than this to a TBBS and see
performance that you will not think of as degraded in any way (i.e. the
kind of specs everyone else uses!). So when you compare this to the kind
of line counts at a given speed that other software claims, you can know
that with equal performance to those systems TBBS will support nearly
double the numbers given above on a given hardware configuration. But if
you want to win bets in a "metered environment" these are the numbers.
This is absolutely the best serial data performance of any software that
has ever been created for computers of any kind (notice we're a bit stoked
at how the lab tests turned out - you'll be happy with the results in the
real world too we're sure).

The truth of V.FC modems

The V.FC modem is an emerging industry standard for modems which go faster
than the V.32bios speeds of 14.4bps. The top speed of V.FC on a dial-up
line is 28.8kbps, and there are "fall-back" speeds of 16.8k, 19.2k, 21.6k,
24k, and 26.4kbps. In addition, the Rockwell chip set which supports this
modulation scheme is available in some lower priced versions which only
have a top speed of one of the lower fall-back speeds (typically 19.2k and
24k bps).

The first full speed V.FC modem to reach the marketplace is the Hayes
Optima 288. Zoom is also shipping a V.FC modem using the 24kbps top speed
version of the V.FC chip. The tests that eSoft conducted were with the
Hayes Optima 288 modem.

What speed do compressed (ZIP) files really go?

For all V.42/V.42bis based modems, there is a speed advantage over the base
carrier rate which comes from the protocol itself (not compression). Thus
a file which cannot be compressed at all by V.42bis will transfer at a bit
less than 20% faster than the carrier rate (1.185 * the carrier gives a
good estimate of the non-compressing speed of a V.42 modem). You see this
when a 14.4kbps modem gives you a 1700cps transfer rate for a ZIP file
(1440cps * 1.185 = 1706cps).

Since V.FC modems have several fall-back rates (which we will discuss
below) the following chart will let you know the actual transfer rates you
will see with compressed files:

Carrier Speed Nominal non-compressing Xfer in cps
------------- -----------------------------------
16.8kbps 1990cps
19.2kbps 2275cps
21.6kbps 2559cps
24.0kbps 2844cps
26.4kbps 3128cps
28.8kbps 3412cps

Note that individual files may go a bit faster or slower than this (just as
you see with 14.4kbps V.32bis modems) but non-compressible files will
center around these numbers. You will find that by doing a download and
watching your cps meter you can see the modem change carrier speeds if it
does, and even tell what speed it switched to just by the transfer rates.

V.FC modems that run faster than the 21.6kbps are really looking to find a
"better than spec" telephone connection. So the question arises, "in the
real world, what kind of speeds do I reliably see?" Our testing on this
issue is preliminary, but we've tried to do a lot of it in the time we had

Local Calls:

What we see is that on cross-town connections you can really get a
28.8kbps connection about 80% of the time. Some particular central offices
will not do this as often, and tend to only give you a 24kbps connection.
It can sometimes take two or three calls to get the maximum connect rates.
16.8kbps was the lowest we ever saw with 21.6kbps being normally the worst
any circuit would give.

Long Distance Calls:

Long distance calls seem to fall into categories based on where in the
country you are, and where you are calling. But even here, it seems to
vary day to day. All circuits we tried were usually capable of 24kbps and
this was the most frequent connect speed we saw. We did manage to get some
28.8kbps connects on every circuit we tried. Some circuits did this
easily, with only one fall-back on "bad" calls, while others did this
rarely and were more likely to give 21.6kbps and 24kbps connections.

Automatic speed adjustment

One very nice feature of the V.FC modems is that they "fall forward"
without a significant delay. So if the lines "get better" the modem will
switch to a higher speed automatically. In our testing we saw this happen
frequently and there was no evidence of any problems with the modems
staying "in sync" with each other through this process. When the modems
"fall back" to a slower speed they do a full retrain operation the same as
a V.32or V.32bis modem so there is about a 30 second stoppage in data flow
when the speeds are reduced. Again, the retrains seemed to have no
problems losing connections and overall this process looks to be as good as
or better than the V.32bis modems in similar circumstances.

Overall Assessment

These modems are hot!!! They represent a quantum leap forward in
transmission speed and they make yet another category of applications
realistic to do online. The V.42bis text compression makes an average text
file transfer at 7000-8000cps (25% faster than ISDN speeds) so menus and
other text displays "snap". In fact, they are usually limited by the
terminal software's video display speed which is almost always slower than
the transfer speeds for most terminal programs. We transferred some large
TDBS .DBF files which always compress well and saw transfer speeds as high
as 11,200cps! But in the real world of BBS use, compressed files are the
norm, and the 3300cps speed is what really counts. This is double a
V.32bis modem and the difference is enough to emotionally affect you when
you see it. Even with a 57kbps interface, these modems will provide a full
3300cps transfer rate for compressed files, and a 5600cps or better
transfer rate for menus and text.

If you take advantage of any of the generous sysop deals and obtain one of
these V.FC modems you can test it out on the eSoft support BBS. We will
soon be converting all lines except one to Hayes Optima 288 modems, and the
303-699-0205 Hayes modem line is already running with one. The
modifications included in this kit provide 100% support for these modems.

[Following is a message from Phil Becker (eSoft owner) to a question about the
v.34 ( standard and the Hayes 288 modems]

Date: 11-04-93 Time: 09:53a Number: 35028
From: PHIL BECKER Refer: 35010
Subject: NEW HAYES V.FC 7: MODEMS Status: Public
This isn't the CCITT next speed standard, but it is about to become a
"de-facto" industry standard. What is going on is that Rockwell and Hayes
developed the V.FC protocol because they didn't want to wait for the standards
committee (which could take another year or two). It is essentially what is
being discussed for the standard put into practice, but the actual written
standard may be a bit different when it finally comes out (from spite if
nothing else - standards are primarily political arenas). However, I don't
think it will matter much and here's why...

As I see it they've done this right. Rockwell makes the chip(s) that are at
the heart of this protocol. Over time (and probably not a long time - I'd
guess six months tops) there will be over 160 modem companies making modems
that use this chip. So unlike the HST/PEP/etc. 9600 wars of a few years back,
this is not destined to become a war of competing protocols for long (if at
all) as all of these modems will talk to each other at higher speeds. V.FC is
going to become the sort of "standard" that Bell 103 300bps and Bell 212A
1200bps is - one that occurs because everyone agrees to use the same thing
rather than because a standards committee decrees it. The 300bps and 1200bps
modems you use(d) are not standards because of any committee action, they are
standards because at the time Bell made all the modems. When this stopped,
everyone else made compatible modems. 2400bps is the first speed where the
CCITT standard (V.22bis) was widely used the world over.

What I think you are about to see with V.FC is the first modem standard made
by the marketplace, and it is a sign of the size and importance of the modem
market that it is happening. Vendors know their customers cannot wait for the
normal years-long standards committee efforts. They also know that modem
technology is now so important to their customers that they can no longer wage
a protracted multi-year battle of proprietary protocols as they did with
9600bps (most customers would choose not to participate). So the scene is set
for a leader in the industry to cause something like this to happen - a
protocol that is adopted by all quickly without having a formal standard behind
it (it does draw on the "next speed standards work" that has been done in order
to gain credibility and momentum).

So in my opinion what would have been a big risk a few years back - buying
into a protocol that wasn't a CCITT standard - is not risky at all this time
around. Only time will tell, but if you are concerned you won't have to wait
long. I would say that if you wait six months at the most you will see how
things shake out. I expect you to see a large installed base for V.FC develop
quickly. If so, then it IS a standard (the CCITT committee might even just
adopt it). But if there is going to be any market resistance to adopting this
technology you will see it clearly by then. If there isn't you will have a
variety of options to acquire the technology by then.

Meanwhile I plan to be transferring MY files at 3300cps minimum.

- Phil

  3 Responses to “Category : Tutorials + Patches
Archive   : HAYES288.ZIP
Filename : ESOFT.TXT

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: