From: tom.kustner@emjay.com (Tom Kustner) Subject: BREQUEST and the "/O" option (for compression) Date: Thu, 12 Dec 1996 20:48:35 GMT Organization: Emjay Corporation
We are running a Btrieve DOS application on a Compaq Proliant 5000 running NetWare 3.12. We are running the latest 6.15 NLM version in client/server mode. We also have the latest BREQUEST version.
Our users use NETX and Windows 3.1.
We have found that we can greatly enhance performance of our DOS-based application (by a factor of 7-8 times) by using the "compression" option that comes with BREQUEST - the "/O" option. It seems to work fine for us, but I'm just wondering if anyone else is using it and has found it to work for them. I have found no examples of other people using it, but it may be a new option. Has anyone used it and what was your experience?
Some of you may remember I ask an earlier question about vast speed differences noticed when running out of Windows on various types of Dell Optiplexes. We have never narrowed it down, but the compression option would take care of our problems. We *do* think we have narrowed down the behavior to the integrated 3COM NIC card that comes with the Optiplexes or some change in engineering by Dell.
From: Mike Hanlon <mhanlon@mpd.tandem.com> Subject: Re: BREQUEST and the "/O" option (for compression) Date: Wed, 18 Dec 1996 08:42:42 -0600 Organization: Tandem Computers Inc., Austin TX
My officemate at the time developed the /O option for Brequest/BSPXCOM, for version 6.10 of the btrieve NLM package (back when Novell owned it). We believed that in normally fast networks with modest-sized messages (say 200 bytes per btrieve call) the compression didn't help performance, probably because the only-slightly-smaller compressed message was not transmitted much faster and didn't compensate for the time spent compressing and decompressing. But for slower networks, especially with large messages (either large records being used in btrieve calls, or else the btrieve Extended Get APIs), the speedup was noticable.
So, you're probably not surprised but this at leasts corroborates your hunch that you have problems in the NICs.
From: tom.kustner@emjay.com (Tom Kustner) Subject: Re: BREQUEST and the "/O" option (for compression) Date: Wed, 18 Dec 1996 17:21:01 GMT Organization: Emjay Corporation
Mike,
Thanks for taking to time to write back and thank your comrade, if you ever see him/her for the option. I just want to add further info to see if something can be surmised.
Here is a record size sample for different record types we use: 117 bytes, 265 bytes, 653 bytes, 1159 bytes, 3460 bytes. This is not a listing of all record types, just a sample, but obviously our sizes tend to fall in a larger range. I don't know how often each one is used, either. This is what we found under the following circumstances for a specific report within the DOS application *without* compression:
DOS box in Win 3.1 on Dell GL+ Optiplex Pentium 133: 22 seconds.
Same except for a Pentium 90: 430 seconds (yes, it was *that* much of a difference).
If we jumpered the Pentium 90 up to 133 mhz, it acted just like the true Pentium 133, running the report just as fast! The same behavior seen on a Pentium 90 was also seen on a Pentium 120. We can only guess that the CPU increase is causing some time-critical limitation to be overcome. Whether it's Windows, SPX, or something else, can only be guessed. Here are the rough results *after* turning compression on with BREQUEST:
DOS box in Win 3.1 on Dell GL+ Optiplex Pentium 133: 12 seconds.
Same except for a Pentium 90: 15-17 seconds (Yes, compression made *that* much
of a difference!)
N.B.: This anomaly only appeared when running out of Windows 3.1. When the Btrieve DOS application was run from DOS, everything worked as expected.
Is it that Windows is stealing CPU that's critical to SPX? Any other thoughts?
Regards,
Tom Kustner
\Copyright © Madis Kaal 2000-