No announcement yet.

Poor performance in WIN2K

  • Filter
  • Time
  • Show
Clear All
new posts

    Poor performance in WIN2K

    I've got a bit of a strange problem, I'm wondering if anyone has run into this.

    I have an old PowerBasic program called DBASELEN.EXE my boss wrote a while ago that basically just reads the layout of a specified DBF file into a file.

    We've been using this program for years under WIN2K in our own offices without any difficulty, performs as expected.

    While running this program through a terminal services connection to one of our COLO machines we get very odd performance issues.

    When the program is executed at the command line there is a 10-12 second delay before anything appears in the window. During this time I've noticed that NTVDM.EXE loads up and also
    is continually taking cycles even after the program has been loaded. If I don't specify the name of the DBF file to read and just let the program waiting for user input the CPU cycles
    revert back to normal usage. If I try to specify the filename, as soon as I hit the first keystroke, the CPU levels raise back up and the performance is horrible once again, it can take
    10 seconds for the file name to even appear as I typed it.

    On subsequent loads of the program, it will display almost instantly, however the typing problems performance issue is still there.

    I don't believe that Terminal Services is an issue at least for the display problems or the slow typing because normal command prompt type things perform exactly as expected, its only when
    running this or other old PowerBasic programs that the performance issue occurs.

    I have tried to replicate this problem on several of our office machines, even running the program through a TS session and it performs normally.

    The only thing I can think of is the CPUs on the COLO box are dual Xeon P4s with Hyper Threading and that might be causing some kind of strange anomaly.

    Thanks in advance for any help.



    I see no one has bitten on this thread, I will have a go

    Terminal Services passes alot of data via its interface (RDP protocol).
    You will note that in XP, terminal services has been replaced by
    Remote Desktops (to take advantage of W2K3), a kinda MMC snap in that is much
    improved, however there is still alot of data to move ( I personally
    find client improvements if the remote desktop is low res and color depth).
    You did not say what kinda link there is, Dial up, dsl etc ... but
    this will all affect how you see processes running on remote pc's.

    The fact that is operates as "your boss" intended in your office
    hints at a network type issue here, also you state late in the post
    that "I have tried to replicate this problem on several of our office
    machines, even running the program through a TS session and it performs
    normally" suggests network problems.

    Have you tried the remote desktop download from Microsoft for W2K instead ?
    I have and it performs better than Terminal services ever did.

    Also console mode apps do appear to be better via this type of interface ?
    well 80x25 is a lot better to transmit than in depth color to transmit.

    sorry if I have taken this the wrong way but just wanted to help out !

    give us some more info and I can re evaluate


    Mark Baker

    [This message has been edited by Mark Baker (edited December 22, 2003).]

    Mark Baker


      maybe my answer is wasted, what the is a "COLO" machine,
      I bin around for a long long time and have never heard of this type ??

      please someone explain


      Mark Baker

      [This message has been edited by Mark Baker (edited December 22, 2003).]

      Mark Baker


        Hi Mark,

        Thanks for your reply...

        When I say COLO machine I meant that it was one of our servers at our hosted facility. I will give the remote desktop a try and see if that improves performance any but I'm a little doubtful just because of the behavior I've seen so far with the problem.

        When I connect via TS we are going over a 768k/768k DSL line we have here at our office, there is a VPN setup here and at the hosted facility. From what I can tell it really doesn't seem like TS is the culprit because we have run many other programs through TS and haven't experienced any performance issues quite like this.

        Even if TS was the problem, it still doesn't quite explain why I see such a difference on CPU usage when running the program locally on a WIN2K box or on the server WIN2K box through a TS session. Since I'm in Seattle and the servers are located in Atlanta I can't go verify the performance problem locally on the box but I believe I would see the same thing. I may have a SA go and check for me if I get time.



          Here is another update...

          I tried using the remote desktop, while I think I may prefer this client to the TS client, I still got basically the same issues. The program now starts up a little faster, but the keystroke pausing is still there. I can type in a file name watch maybe 1-2 characters appear as they should then it just sits there. Meanwhile I can open up SQL, browse directories, do virtually anything else on the machine while I wait for the keystrokes I entered to catch up. This tells me that I'm not having a connection problem. The program is just sitting there waiting to do something even though it should have been echoing my keystrokes. This is why this issue is leading me to point toward a hardware issue even though it would normally seem unlikely.



            Remote desktop and terminal servers are windowsprograms, that
            cache's windows, ico's etc. A Dos program requires a screen send over
            instead of cached windows controls movement send. You can test this to
            partly overlay the dos window with another (windows)window on the remote
            machine, let's say youre just able to type in and see the command. If that
            speed up things, you know it's the dos-screen, together with the NT-VirtualDosManager.
            You may wanna suppress output to screen, and instead use file input-output if possible!!
            Or try rewriting it in a windows program.


            You gotta run, and don't loop back.
            You gotta run, and don't loop back.


              It doesn't sound exactly like a TermServ issue but then again I've seen TermServ
              do strange things to a few programs. If I suspect its an issue I usually test by
              getting on with VNC.


                its only when running this or other old PowerBasic programs that the performance issue occurs
                More likely, programs from a specific old PowerBASIC programmer.

                Many of those old MS-DOS programs were written with the user input loop something like..

                  K$ = INKEY$
                LOOP UNTIL LEN(K$)
                (process keystroke here)
                Nearways as I can tell, this particular coding technique sucks CPU time in the simulated MS-DOS provided by 32-bit Windows.

                Not that i can think of any better way to code the DOS program, but this might be a contributing cause to poor performance.


                [This message has been edited by Michael Mattias (edited December 23, 2003).]
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]


                  Thanks for the tip Michael, from what I've seen of my boss' old PB code he usually doesn't write inputs like that but it is still possible in this case. I'll investigate the code and see what I can find out.



                    have you tried tamedos?
                    free trialware download



                      I had a similar problem with Win2k and XP when using PC AnyWhere and
                      DosBoxes.When i used the PC Anywhere with Win32 apps runing on the host PC all went ok,but as soon
                      as i run a Dos program the connection was becoming very-very-very .... very slow.
                      I solved the problem by setting the priority of the PC AnyWhere host modul to "Above Normal"
                      I think your problem is the same.The Dos program takes up most of the CPU priority and the
                      TS communication modul doesn't take much of the CPU's attention.

                      Byte Hunters of the World Unite.
                      Byte Hunters of the World Unite.


                        Thanks for those extra ideas Shawn and Stavros, I will give them a try when I get a chance and let you know the results.



                          Looks like TAME is the best solution, I tried changing the priority of termserv.exe but you aren't allowed to change the priority because of "Access Denied". After installing the evaluation version of TAME the programs work normally, great little utility.

                          Thanks for everyones responses. My boss is happy we don't have to re-write lots of old PB programs into windows apps.



                            Mike ...

                            For what this may be worth, who knows. You have just discovered both
                            one of the real problems of using PB for DOS in later and greater operating
                            systems, together with one of the most important little utilities which
                            can be acquired and used to sincerely help you for the future.

                            This is not just an issue with later and greater versions of WIN when
                            used with these programs, but can also show up big time in the IBM OS/2
                            operating system as well. And it is VERY far from dead and funded through
                            absolutely 12-31-2006 plus spoken-to in public toward by IBM actually as
                            far as the year 2019 now. There are just too many embedded system, mission
                            critical and hardware-related oriented issues which absolutely cannot be
                            addressed for many people in any operating system platform which goes
                            off and forgets the past. I have hardware, software and complete operations
                            running code all the way from 1974 to current date, including every single
                            bit of PB 3.5 code that has ever been created here .. and it will continue
                            to be supported, as far as I and a lot of others know as posted above.

                            That's important, particularly when by law you have to be able to support
                            things with no questions asked for seven, ten or more years in the future, or
                            face serious liability issues if you fail. And PB, for the real answer, as
                            a DOS application in these superb heritage operating system support issues,
                            simply is one of the best toolsets you could ever use for this stuff.

                            What you have just, apparently discovered, is that TAME introduces required
                            time slice releases in your much more recent multi-tasking operating system
                            which are simply not normally required in PB 3.5 for DOS as a single tasking
                            operating system! That is *NOT* a fault, really, in PB 3.5 for DOS, although
                            in a future release of it, it would very kind of the PB crew to consider making
                            available the tools to help us, which can be written.

                            For any future reference, the same general utility TAME330 also exists in the
                            OS/2 operating system world. It is a God-send for a lot more than just the
                            PB arena with the looped polling problems. It is paid-for utility and in
                            my standard arsenal of DOS tools here in OS/2 and has been for years now.

                            If you are sincere about re-writing the code to provide internal time slice
                            releasing, there a a series of ASM coded routines which are known and
                            documented in the forum here. They can be used to internally do the same
                            kind of thing that TAME does for you. But it takes some learning, and thinking
                            about all this to provide the general solution for source with which you
                            work. Different trace techniques in the ASM code can determine, at least up
                            to just before WIN-XP here, figuring out what operating system is in use,
                            and how to release time slices for it which eliminate the need for TAME which
                            you have discovered. I think if you do a forum search here you'll find most
                            if not all you need to know to learn this is right at hand.

                            I'll prolly get toasted at sunrise for making this suggestion, but I'm not
                            at all embarzado! If the issue of support resolves into an issue where you
                            simply have to stay in the DOS arena with PB, you might actually consider
                            even a brand new route to OS/2 to do this! ECS as a dedicated toolset for
                            intalling the brand new OS/2 MCP versions, totally supported even as we speak,
                            in some places, I think, can be found still for only about $75 now! Although
                            IBM makes it difficult for you to find how, frankly, the entire official IBM
                            total new MCP system at Fix Pack 4 now, with EVERYTHING in all the official
                            fixes, is only about USD$175 which includes a full year of upgrades and
                            even defect support, plus only USD$65 a year from then at this time! We'll
                            not dwell on defect support as the importance of it can make the cost vary
                            considerably, but the Usegroup support for this still C2 security mission
                            critical system is darned good.

                            I have servers which have not failed in FOUR years, nor lost one byte
                            of mission critical information under it.

                            You can even get host operating system capability for it under WIN of all
                            kinds, grin, plus both Citrix and VMware can absolutely fix the issue of
                            Host/Guest operations to support you. Given the CPU horsepower and memory
                            needed, I can frankly run WIN-XP or even two or three different WIN
                            operations under my own licensed Connectix Host operation under mission
                            critical OS/2. And also LINUX if I want to.

                            What you have stumbled on to, and solved, is your first real look at how
                            things have grown up in the world! Yes, you can move with PB tools direct
                            to the Brave New World. But if you have to run a whole machine shop of
                            NMC stuff or whatever, do some real investigation on how to cross work
                            with the tools which are really available to you. You may find that the
                            future does hold PB 3.5 for DOS upgrades for you. But it will be LINUX
                            and directly available too. Don't sell anything short in your search for
                            the light ..

                            It shines brightly for all use here; really it does! And PB with it
                            is mission critical as well, case closed, at least in my humble world.

                            Mike Luther
                            [email protected]
                            Mike Luther
                            [email protected]



                              I'll prolly get toasted at sunrise for making this suggestion, but I'm not
                              at all embarzado!
                              Does not "embarzado" mean "pregnant in Spanish?

                              Robert DeBolt
                              mailto:[email protected][email protected]</A>