AREV over a WAN (AREV Specific)
At 01 FEB 2000 09:19:57AM Jeff Fawcett wrote:
I need to run AREV over a WAN link between Florida and California. Most likely the connection will be frame relay. Any recommendations as to minimum bandwidth needed to get decent performance over the WAN? Please give details of your experience.
Thanks in advance!
At 01 FEB 2000 09:23AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Can you configure this so the binaries are local, that you are using an NLM/NT service and that only the data is passed over the WAN? This is the constraining factor.
World Leaders in all things RevSoft
At 01 FEB 2000 09:54AM Don Bakke wrote:
Jeff,
Does it have to be a WAN connection? You can use your frame relay or other high speed connection (e.g. DSL via the internet) and get much better performance with a remote control approach and probably for less cost too. Far less bandwidth than a traditional WAN approach, except for printing of course.
dbakke@srpcs.com
At 02 FEB 2000 10:50AM Jeff Fawcett wrote:
Yes, I can configure to run the NLM and binaries at the CA point. I am also running IPX, not IP. We were recommended to not use a VPN, by the way. Anyway, the connection I am originally working w/ is a 56K frame w/ 32cir. Over the WAN it takes about 5 minutes to open an AREV application. AT&T is recommending to upgrade to a 128K w/128cir. Any thoughts on this?
At 02 FEB 2000 01:49PM Victor Engel wrote:
I am curious why they recommended against using VPN.
I will have to agree with Don Bakke on this one. Even with an obsolete computer (like a 486) at each end, you will get greater performance using pcAnywhere or other remote control software that by using a WAN setup. If you decide you must use a WAN setup, localize as much as possible. This could be done using transaction control, where deltas are posted to a transit table and then used to update local files. If you have two separate data centers with a significant user base on each end, it would probably pay to set up a dedicated connection between the two sites that did nothing but ensure the two databases were synchronized. Users at each end would then access the databases on their LAN only.
We used this approach when interfacing Arev to Prime Information about 10 years ago.
At 07 FEB 2000 11:36AM Ralph Johler wrote:
Eric,
To restate what you are saying, in order to see if I understand:
- Use remote control software even if you can't print
OR
- Install on the remote server another copy of Arev (with it's own NLM and user count)
- Link the main and remote server arev data bases with synchronization software (probably an MFS?)
- Distribute 'client' upgrades (screens, programs etc) with a different version of the db synchronization software
But all this hard work gets you a much faster response time than running over the WAN from one centralized server, right?
So how much faster do you think?
Ralph
(Our client's wan performance is generally too slow, but more bandwidth seems like an easier and more reliable solution than all the non-printing and sychronization software)
At 08 FEB 2000 03:45AM Philip Horner wrote:
I cannot comment from experience of running Arev over a WAN, but is not Terminal Server and Citrix a viable alternative? This should give good response times over the limited bandwidth.
At 09 FEB 2000 05:56PM Harold Vance wrote:
We have a WAN with 56K links to two branches. We got fed up with transfering data to the branches and installed a MetaFrame. We have not yet achieved satisfactory results, though.
For some reason the limited 56K bandwidth seems to affect the performance of Arev. If I log in to MetaFrame from our LAN, Arev works well. This includes the Windows and Linux ICA clients. However, when a branch user logs in, Arev gets Quickdex load errors and it also locks up, especially if the user stops using the computer for a while.
My guess is that the lack of bandwidth is choking the keyboard input and maybe Arev is timing out or something. (We run arevfix and another utility for the keyboard/CPU problem.) My other guess is that the 512 MB of RAM on our NT Server is defective.
We did discover a Revelation NLM setup problem in that our REVPARAM file name was misspelled. Correcting it has not fixed the other problems, so we are stuck in limbo. Basically we have traded one set of problems for another. The good news is that I don't have to maintain three separate systems anymore, which was a big pain over the WAN.
Win some, lose some.