Re: Growing memory usage in D4 app with SerialNG

Paul E. Schoen schrieb:

Those are good suggestions, but the constraints of my project dictate that it must run on a Windows platform, usually a laptop, and the hardware that might use the RTS and CTS has a limited amount of memory for a buffer, and it would certainly overrun if it were asked to hold off transmission for any longer than a hundred mSec or so. I also need to use a USB virtual COM port rather than a true serial port. The isolated TxD and RxD are actually between the USB PIC and a second PIC used for data acquisition.

This is a common scenario nowadays <sigh>. I've been fighting such problems more than 10 years ago, with the first IBM-compatible laptop and MS-DOS 3.0, and com ports without a FIFO. But while it was easy to have an almost-realtime program run on DOS, one will have all kind of problems when the same is attempted on Windows. You better ask in a Windows group, how to make an application and Windows itself as responsive as possible.


This indicates a degradation of the response time only when Windows starts swapping.

At this point my application has been running for 27 hours error-free. My debug dialog shows several occasions where the application had to wait for as long as 700 mSec before there was data in the secondary buffer to be analyzed. But the primary low-level 48k buffer apparently has not been adversely affected by Windows swapping. Its peak data content is 12291 bytes.

Sounds good. But don't forget to put a large "Keep Off!" sign on your keyboard, when running your program ;-)


I admit to having little knowledge of Windows memory management. But I just don't understand why my application continues to show increasing memory usage, way beyond the size of the executable (about 800 kB), and all assigned memory (probably about 300 kB). The initial memory usage shown when I minimize the application is 1100 kB, which is exactly what I would expect for those figures, but I don't know why it should keep climbing.

You'll have to use a library that can tell the exact heap usage, from *inside* your application. E.g. heap fragmentation can result in growing memory requirements. Windows only can tell the amount of requested memory, and the amount of resident pages, not whether that memory is used at all. BTW, which memory manager do you use?


When I run the program without the communications, the memory usage sometimes remains the same, and sometimes climbs as before. It also sometimes jumps when I set or lose focus on the main form or sub-forms. But it seems like the growing memory effect is mostly when the communications thread is running. I just don't understand why manipulating the forms causes the memory usage to be affected so much.

I'm not sure what your memory usage figures include. Your application may use system or third party DLLs, e.g. for common controls, which have to be swapped in when something in the GUI changes.


I'll try to read up on memory management, but I am mostly an electronics design engineer and programming is more of a sideline which is required to utilize the hardware I design. I am more comfortable designing systems that use microprocessors and PICs where the memory is precisely defined and everything is under control of the software that one writes. When dealing with an operating system, there are many more considerations, especially for realtime applications such as this. But thanks for the attempt to explain it and offer suggestions.

My background is very similar. I started with building my first computers myself, because at that time nothing but mainframes was for sale. Later I constructed data acquisition hardware for a pdp-11, where we used up to 16 RS-232 connections, at 19200 Baud each, for data input. No problem so far, even RSX-11M was responsive enough for handling that traffic. Problems came with PCs and DOS, where the first graphics card drivers used to disable all interrupts while updating the screen.

Did you ever think about an spooler, i.e. a microcontroller with enough RAM for buffering all incoming data, that can bridge all Windows delays?

DoDi
.

Relevant Pages

  • Re: Crashes and the Blue Screen of Death!
    ... but the most common cause is hardware failure. ... The most common cause of this is hardware memory corruption. ... are listed on the Windows 2000 Hardware Compatibility List. ... recommended that all users install them as they become available. ...
    (microsoft.public.win2000.general)
  • Re: error restarts intermittently
    ... A problem has been detected and windows has been shut down to prevent ... And text about newly installed hardware or software, ... Device manager is good. ... The system attempted to access pageable memory using a kernel process ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Windows installation problem. Help.
    ... 2004 Windows MVP "Winny" Award ... tries to read the memory, can't find it, generates a processor fault, ... This Stop message usually occurs after the installation of faulty hardware ...
    (microsoft.public.windowsxp.general)
  • Re: BAD_POOL_HEADER blue screen of death
    ... The "pool" referred to is a memory pool. ... > Also, I installed no new hardware, except for some more memory. ... >> Here is a MSDN article with regard to this error in Windows 2000. ... >> the error reporting tool will get this for you. ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: [opensuse] 4GB computer slowdown
    ... What I experienced was correct Windows ... I agree with Carlos that LInux most probably uses hardware more ... memory check tool showed that memory was bad => computer to the IT ... That would depend on whether parity checking is enabled. ...
    (SuSE)