Actually, you are misunderstanding a little bit here. While the render time on a fairly weak terminal emulator, such as some of those popular with MV users (bit which I will restrain myself from knocking) can be an issue as it causes flow control delays, once the data has left the process and entered the socket layer on the transmitting process, it does not affect the speed of the running process. On earlier RS232 system then the effect depended on the hardware implementation. Later Reality systems used plan, which acted in a similar manner to sockets. However many systems had hardwired ports and the transmission time did affect things because the RS232 buffer was very small and would quickly fill up and block the process.
However, by far the more significant issue is the fact that even before the days of pre-emptive kernels, queuing yourself up for some IO meant that you lost your time slice and had to wait for the monitor to come back around and pick you up again. Pre-emptive scheduling helped this a little but even so, you have given up your time slice for no reason and this is the real issue. Minimizing the local telnet client will only [possibly] save you some local CPU cycles. A crude benchmarking system could be created on dedicated hardware, which would give you an indication of the load on the CPU at any point in time by seeing how many single '*' characters the process could send to the screen in a given period of time (say a second or 5 seconds). Because the process would RQM as soon as the IO was dished up, then in order to queue the next '*' you had to wait for another time slice and that meant that the higher the load, the smaller the number of '*' sent to the screen. Of course I know of nobody at all that has fallen for this, most especially not any ex-Microdata programmers who might have written a transaction journaling system and printed '*' the screen to indicate transactions being processed/restored/etc. Oh no, yes indeed, definitely didn't happen to any mate of mine and definitely not on the journal restore program. Jim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Gravagno Sent: Tuesday, March 02, 2010 4:38 PM To: [email protected] Subject: RE: Resizing files based on jstat output I noticed the situation you describe sometime in the early 90's .... or was it in the 80's? Serial lines and the Telnet protocol both throttle a server, forcing it to complete the write before it moves to the next instruction. Individual instructions may take a few milliseconds to process, but it may take full a second to transport text down a wire and render it to a UI, thus crippling the performance of an app. One solution (as you said) is to do something like this: IF MOD(COUNTER,1000) THEN CRT COUNTER Another solution (depending on the technology involved, is simply to minimize the window on a telnet client which is receiving streamed output. You still incur transmission time but you don't incur time in the UI to render text, which can also be substantial. HTH Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno From: Will J > I have a funny story about a whole-file-process which, > as it ran, output a status message on how many records > it had processed, etc. Of course the file ran pretty > quickly on new hardware, but the program still output > a status line for *each* record processed. Record 1, > 2, 3, 4, 5, etc up to 500,000 or whatever it was. The > messages went by now, so quickly you couldn't really > read them, so it was pointless. > > The whole process took about 2 hours. I changed that > status to only output every 1000th record. The > process from that point on, now took 10 minutes. The > vast consumption of time, was just in printing status > messages. Funny isn't it? > > Some things just don't scale well, when the hardware > speeds up. -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
