PxPlus User Forum
Main Board => Discussions => Programming => Topic started by: Lawrence_Leavell on August 08, 2018, 04:19:00 PM
-
When using a standard text emulator, our input program loads without hesitation. However, using Windx, the program requires at least a second to load. We have added "ADDR" to the program in an attempt to speed this up to no avail. No difference.
What are we missing here?
-
The emulator would just be loading into server memory. Windx would be loading it across the network.
Does turbo mode help ('TU' parameter)?
-
What do you mean by "Text Emulator"?
Are you referring to a terminal emulator such as Putty?
When you are running WindX -- how are you connecting? SSH, Telnet, Simple CS, NTHost/Slave, App Server?
Also when you say you LOAD a program into memory do mean issuing a LOAD "xxxxx" command at command line and if so what is the pathname of the program?
-
Using a text emulator such as putty or SecureTerm, in either telnet or ssh connections, the input program loads up and returns the input instantly. However, using the very same programs with Windx in telnet or ssh connections (these are all currently CHUI programs) and the performance is distressingly slow, about one second per entry.
We have looked at ADDR, 'PC', '+C', and 'TU', nothing seems to speed this up.
-
What do you have the terminal type set to?
For WindX it should be set to 'ansi' or 'winterm'.
What Server OS and version of the software.
Also is this just simple input or are you running your input through some form of input handling routine?
We have seen instances where an input handler attempts to get information from the workstation in each keyboard input. Basically reading a character at a time then asking for the FIB/FIN/FID or other information that has to be requested from the workstation. This can slow down performance since when using WindX we forward the request to the workstation for the information whereas with text mode terminals we simply use information held on the server and just assume that things like cursor position are correct.
If the problem persists we suggest you open a helpdesk ticket so we can provide further assistance.
-
This is a Red Hat Linux system, 47 Users, TERM=ansi, connection=SSH.
We are using FIN( to determine quite a number of values, such as COL, ROW, MAX_COL, MAX_ROW, WINDOWs and COLORs.
Can you suggest an alternative method to determine these parms?
-
Have you tried a simple program such as:
10 INPUT "Enter your name:",x$
20 PRINT "Hello ",x$
Does this also exhibit the slow down?
Also your post title is "Slow Program LOAD". I'm not certain how a slow program load is related to terminal input. Slow program loads generally has to do with system loading or perhaps the number of directories being searched to find the program.
Lastly, with regards to the FIN/FIB functions, while these provide information about the terminal state, on WindX they also include information only know to the workstation such as X/Y screen co-ordinates which the user can change at any time. Accessing the FIB requires a packet exchange with the workstation thus can slow down input processing. (This additional information is not applicable/available when using text terminal emulators).
You should make sure you minimize the number of calls to this function to improve performance when using WindX.
Mind you a packet exchange with WindX on most networks only takes a few hundredths of a second (if that) so unless you have a very slow network or are doing an excessive number of requests your performance should not be visibly impacted by a couple of FIN/FIB requests.
-
Mike, This is a nationwide network. The server is in New York while operators are in Nashville, Miami, Los Angeles.
-
Lawrence, you mentioned you use FIN() for quite a few values. Are you setting a variable to it once, and using the variable for those queries? On a wide area network like this you'll have much higher transit times and latency than on a local network, so those calls to FIN will be expensive.
-
Lawrence, a good wide-area network should still have a fairly respectable packet exchange time. For example we have an Amazon server in Oregon and when we time how long a FIN request takes we get an response of less than a 1/10th of a second for the packets to go between Toronto and Oregon (basically coast to coast plus an international gateway -- routing over 24 points according to tracert )
Here is what we ran:
-;list
0001 LET x=TMR(0)
0010 FOR i=1 TO 100
0020 LET x$=FIN(0)
0030 NEXT i
0031 PRINT TMR(0)
-;run
8.609
(so 100 requests in 8.6 seconds or 0.086 seconds per request)
So given that most users could not distinguish anything below about 1/2 a second, you should be able to run a handful of FIN requests in your logic without any noticeable delay.
However going back to the original question you have not answered; Did you try a simple INPUT statement to see how it performed and how does all of this relate to program load times???
-
Mike,
An INPUT statement is essentially instant. Using only one FIN( function in the called program reduces the delay to an acceptable amount but it is still noticeably slower than an INPUT statement.
-
Lawrence, if a single FIN request is taking a long time to return then your network is slow. This is either due to the line speeds (bandwidth), too much traffic, or latency. If using satellite communications latency delay is generally over 600ms per packet caused mostly by the time for the transmission to get bounced off the satellite regardless of bandwidth.
I suggest you time the turnaround for functions like FIN and if these are not less 200 ms (1/5th of a second) then I would strongly suggest you not attempt to use the network for anything but text mode communications. Trying to run a graphical environment such as WindX with slow packet delivery is not likely going to yield an acceptable results.
-
Lawrence, I have changed the subject line for this topic to better indicate that your performance issue wasn't program Load times, but rather poor performance in your input handler when running under WindX.
When running under WindX, all FIN/FIB/MSE requests get forwarded to the workstation for processing as some of the information returned is only know at the workstation such as window handle, position, etc.. It is therefore important to minimize the number of these types of requests since on a slow network they can adversely impact overall performance.
It should also be pointed out, if you are using these function to get/save information about the device (so that your program can change settings then restore them) you would be better served by switching to the 'SA' and 'RA' mnemonics which save and restore terminal attributes.