is there a maximum memory allocated?

[Ernest Mendoza]

Dear all,

Anyone knows if there's a limitation to the maximum memory
that labview can allocate in Win98?

I cannot allocate more than ~ 19500 KB and my computer has
1GB.

Cheers,

Ernest

[waldemar.hersacher]

Hi Ernest,

there is a limitation in Win98. Win98 cannot handle more than 512 or 256 MByte of memory. Ask Micorsoft and you get "this is by design". If you don't have another OS on the same machine it has a little bit too much memory installed.
Wademar

[Ernest Mendoza]

Hi Waldemar,

I will install Win2000 to see if changes. However, my problem is that
I don't know why but I am not able to fill more than 19 MB while doing
an i/o acquisition.

Thank you,

Ernest


waldemar.hersacher wrote:
> Hi Ernest,
>
> there is a limitation in Win98. Win98 cannot handle more than 512 or
> 256 MByte of memory. Ask Micorsoft and you get "this is by design". If
> you don't have another OS on the same machine it has a little bit too
> much memory installed.
> Wademar

[waldemar.hersacher]

Hi Ernest,

where do you have problems allocation more than 19 MBytes of memory? Is this during the allocation of buffers in the intermediate or advanced DAQ VIs?
These buffers are restricted in amount you can allocate by the OS. These buffers must be locked in memory so the driver can write/read to/from it at any time especially during interupt handling from the DAQ card. This buffers cannot be swapped to the virtual memory space which lies on the hard drive. Windows restricts the amount of memory which can be locked on a per process basis. There is a minimum value and you can increase it to a maximum value depending on physical RAM and virtual memory.
We ran into this problem using NIDAQ from a Visual C++ application since on the tar
get system the application was suspended by some system activity for such a long time that we got a buffer overwrite error from NIDAQ.
Waldemar

[Ernest Mendoza]

Hi Waldemar,

I am using DAQ VI to perform a burst acquisition with a MI6533.
I want to use ~800 Mb of the system physical memory to
do the acquisition.But I cannot use more than 19 MB, otherwise
Labview gives the following error:

Error -10444 Digital Buffer Config
No more system memory is available on the heap, or no more memory
is available on the device, or insufficient disk space is available.

> We ran into this problem using NIDAQ from a Visual C++ application
> since on the target system the application was suspended by some
> system activity for such a long time that we got a buffer overwrite
> error from NIDAQ.

I thought that most part of the NI cards have Busmastering DMA access,
at least NI6533 has it, and then the acquisition was not affected by
the system activity.

> These buffers are restricted in amount you can allocate by the OS.
> These buffers must be locked in memory so the driver can write/read
> to/from it at any time especially during interupt handling from the
> DAQ card. This buffers cannot be swapped to the virtual memory space
> which lies on the hard drive. Windows restricts the amount of memory
> which can be locked on a per process basis. There is a minimum value
> and you can increase it to a maximum value depending on physical RAM
> and virtual memory.

How did you fix this problem? I don't find that much documentation about
this subject...

Thank you in advance,

Ernest


waldemar.hersacher wrote:
> Hi Ernest,
>
> where do you have problems allocation more than 19 MBytes of memory?
> Is this during the allocation of buffers in the intermediate or
> advanced DAQ VIs?
> These buffers are restricted in amount you can allocate by the OS.
> These buffers must be locked in memory so the driver can write/read
> to/from it at any time especially during interupt handling from the
> DAQ card. This buffers cannot be swapped to the virtual memory space
> which lies on the hard drive. Windows restricts the amount of memory
> which can be locked on a per process basis. There is a minimum value
> and you can increase it to a maximum value depending on physical RAM
> and virtual memory.
> We ran into this problem using NIDAQ from a Visual C++ application
> since on the target system the application was suspended by some
> system activity for such a long time that we got a buffer overwrite
> error from NIDAQ.
> Waldemar

[waldemar.hersacher]

It seems it is a problem with the working set size and locking of pages. We have developed under Win2000 and have a double buffer daq application. The problem was the application was too late in the loop to get the data from the driver so it gets overwritten. Think of calling AI Read in a loop and the loop stopped for some time.

I suppose you have no documentation for the windows API so I give you some from the MSDN.
VirtualLock is the function which locks memory into RAM.
"The VirtualLock function locks the specified region of the process's virtual address space into physical memory, ensuring that subsequent access to the region will not incur a page fault.
All pages in the specified region must be committed. Memory protected with PAGE_NOACCESS cannot be locked.

Locking pages into memory may degrade the performance of the system by reducing the available RAM and forcing the system to swap out other critical pages to the paging file. Each version of Windows has a limit on the maximum number of pages a process can lock. This limit is intentionally small to avoid severe performance degradation. Applications that need to lock larger numbers of pages must first call the SetProcessWorkingSetSize function to increase their minimum and maximum working set sizes. The maximum number of pages that a process can lock is equal to the number of pages in its minimum working set minus a small overhead.

Pages that a process has locked remain in physical memory until the process unlocks them or terminates.

To unlock a region of locked pages, use the VirtualUnlock function. Locked pages are automatically unlocked when the process terminates."

The SetProcessWorkingSetSize functions allows you to get more locked memory.
"The SetProcessWorkingSetSize function sets the minimum and maximum working set sizes for the specified process.

The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The size of the working set of a process is specified in bytes. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
The working set of the specified process can be emptied by specifying the value -1 for both the minimum and maximum working set sizes.

If the values of either dwMinimumWorkingSetSize or dwMaximumWorkingSetSize are greater than the process' current working set sizes, the specified process must have the SE_INC_BASE_PRIORITY_NAME privilege. Users in the Administrators and Power Users groups generally have this privilege. For more information about security privileges, see Privileges.

The operating system allocates working set sizes on a first-come, first-served basis. For example, if an application successfully sets 40 megabytes as its minimum working set size on a 64-megabyte system, and a second application requests a 40-megabyte working set size, the operating system denies the second application's request.

Using the SetProcessWorkingSetSize function to set an application's minimum and maximum working set sizes does not guarantee that the requested memory will be reserved, or that it will remain resident at all times. When the application is idle, or a low-memory situation causes a demand for memory, the operating system can reduce the application's working set. An application can use the VirtualLock function to lock ranges of the application's virtual address space in memory; however, that can potentially degrade the performance of the system.

When you increase the working set size of an application, you are taking away physical memory from the rest of the system. This can degrade the performance of other applications and the system as a whole. It can also lead to failures of operations that require physical memory to be present; for example, creating processes, threads, and kernel pool. Thus, you must use the SetProcessWorkingSetSize function carefully. You must always consider the performance of the whole system when you are designing an application."

But these functions will not be supported under Win98. I know from some other function which was stated to be not supported under Win98 were supported under Win98SE.

But thats the time to get an answer from NI personal with more insight into what NIDAQ and the lvdaq.dll does.
Waldemar

[waldemar.hersacher]

Also I have found this Knowledgebase article
Waldemar