root@charlie.OZ (Just call me SUPER) (04/24/89)
Are there any users of ACCELL/CP that can give me feedback as to its performance (good/bad?). Does it free the processor of I/O significantly to improve database performance? Looking forward to any replies/experiences. Wayne Jennings. -- Computer Services, DEAKIN UNIVERSITY, Victoria, 3217, AUSTRALIA. VOICE: (052) 471 161 (International: +61 52 471 161) UUCP: ...uunet!munnari!charlie.oz!wayne ARPA: wayne%charlie.oz.au@uunet.uu.net
itkin@mrspoc.UUCP (Steven M. List) (04/26/89)
In article <7495@charlie.OZ> wayne@libra.cc.deakin.OZ () writes: > Are there any users of ACCELL/CP that can give me > feedback as to its performance (good/bad?). Does it free > the processor of I/O significantly to improve database > performance? > I've worked with ACCELL/CP somewhat. Certainly enough to offer an opinion (actually, it doesn't take much for me to offer an opinion :^>~). The design goals of ACCELL/CP are good. The implementation leaves a bit to be desired, but only from certain perspectives. To explain: ACCELL/CP DOES indeed offload the host processor significantly. Both Unify's testing and my own lead clearly to that conclusion. The effect of ACCELL/CP is to LEVEL performance. That is, the response for each user will be pretty much the same regardless of whether there is one user or there are 16 users. This is largely a function of the fact that the PC is performing much of the local field editing and cursor movement. The cost, however, is that the PC MUST communicated with the host EACH TIME YOU MOVE BETWEEN FIELDS! Thus, for one user, there is still a noticeable pause when you press RETURN before the cursor moves to the next field. The place where you will see a noticeable improvement is when you return (PREV FORM) to previous forms. Since the PC using ACCELL/CP will be caching forms lower on the stack, they pop up IMMEDIATELY. My problem is that this is a small benefit. The cost in the field-to-field movement is far higher than the savings in popping forms off the stack. Where I think there is the potential for far better gains will be the networked version of ACCELL/CP whenever that becomes a reality. I think that the biggest problem with ACCELL/CP is that cost of communicating between host and PC at terminal speeds (9600 or 19200). There is one other problem that we experienced with ACCELL/CP: it was apparently not well tested with multi-occurrence forms (one of my favorite feature of ACCELL). It frequently bombs out with messages about the "host not cooperating". Since most of my applications use multi-occurrence forms liberally, this pretty well prevents me from using ACCELL/CP even if I really wanted to. For me, the net is that I don't plan to use ACCELL/CP until and if the performance is reasonable with ONE user. If you are planning an installation with large numbers of users, it may make sense since it does LEVEL performance. You will get fewer complaints from users about performance degrading, since it won't (or at least not significantly). -- : Steven List @ Transact Software, Inc. :^>~ : Chairman, Unify User Group of Northern California : {apple,coherent,limbo,mips,pyramid,ubvax}!mrspoc!itkin : Voice: (415) 961-6112
vfm6066@dsacg3.UUCP (John A. Ebersold) (04/28/89)
In article <7139@mrspoc.UUCP> itkin@mrspoc (Steven List) writes: >In article <7495@charlie.OZ> wayne@libra.cc.deakin.OZ () writes: >> Are there any users of ACCELL/CP that can give me >> feedback as to its performance (good/bad?). Does it free >> the processor of I/O significantly to improve database >> performance? >> Some nice stuff about ACCELL/CP deleted.... >This is largely a >function of the fact that the PC is performing much of the local field >editing and cursor movement. Offloading the need to do single character reads. >The cost, however, is that the PC MUST >communicated with the host EACH TIME YOU MOVE BETWEEN FIELDS! Thus, for >one user, there is still a noticeable pause when you press RETURN before >the cursor moves to the next field. Have you tried making the packet the PC sends, small like 96 bytes or less? (Aside: This is configurable at each PC using ACCELL/CP.) I looked at this problem a while back and concluded that 96 or less was a good figure. It provided a good balance bewteen field to field movement and updating a record. In my tests at 9600 baud, I noticed a SLIGHT pause before the cursor moved to the next field - very livable (sp?). >Where I think there is the potential for far better gains will be the >networked version of ACCELL/CP whenever that becomes a reality. I believe - a networked version of ACCELL/CP is available with ACCELL/SQL. >I think that the biggest problem with ACCELL/CP is that cost of >communicating between host and PC at terminal speeds (9600 or 19200). Could you expand upon this statement please? >There is one other problem that we experienced with ACCELL/CP: it was >apparently not well tested with multi-occurrence forms (one of my >favorite feature of ACCELL). It frequently bombs out with messages >about the "host not cooperating". If the host is very busy a timeout can occur, try adjusting the packet timeout values. > >For me, the net is that I don't plan to use ACCELL/CP until and if the >performance is reasonable with ONE user. I suggest that by adjusting the packet size and timeout values you can get things to work the way you want. -- John A. Ebersold at Defense Logistics Agency osu-cis!dsacg1!dsacg3!vfm6066 Unify Corporation System Automation Center Columbus, Ohio 1-614-238-5923 Me? Speak for anyone else? Don't be ridiculous! AV 850-5923 Systems with poorly understood requirements cannot be developed in a crunch.