3 Replies Latest reply on Mar 2, 2009 4:58 PM by yu.yanfeng

    Expedition PCB Memory Usage

    Jerry_Suiter

      Hello,

       

      There have been a few questions about Expedition PCB memory usage.  I would like to provide a little information on this topic.

       

      As Expedition PCB is a 32 bit application, it’s limited to the amount of addressable memory that can be defined for a single process.  For operating systems based on the Microsoft Windows NT technology, this limitation is 2 GB of virtual address space for a single process.

       

      History

       

      Starting back in 2006 we started to see a few customer designs exceeding this 2 GB limitation.  When this occurs the application will crash.  Exceeding this limitation can be caused by many factors:

       

      Bugs (memory leaks) – This type of issue is seen when the design opens with far less than 2 GB of memory and after a relatively short time within the design environment the process runs out of memory.   If this type of situation is seen, it’s best to log a bug through CSD.  The bug will then be resolved within engineering.

       

      Extraneous number of graphic objects – I have seen some customer designs where construction objects have been poorly managed.  In this case the user kept importing DXF data into the design without removing the previous data.  A relatively small design had over 1.2 GB of user graphics which was mostly graphics shapes on top of other graphics shapes.  This type of situation can be resolved by cleaning up the construction elements imported onto user layers.

       

      Small hatch widths for drawn plane data – In this case the board was the size of a full panel and the positive plane data was hatched with a 1 mil line.  This situation was easily solved by changing over to 274X Gerber using a solid shape fill instead of hatching.

       

      Migration – I saw one truly large customer design in which moving from 2005.X to 2007.X would crash when running out of memory during the load process.  In this case the load process was migrating between two major releases.  Seeing no other solution for this situation we enabled our 2007.X software to support Windows extended memory.

       

      Starting with 2007 Release Windows OS

       

      In 2007, we started building our Expedition PCB application using Microsoft’s ‘/LARGEADDRESSAWARE’ option.  This feature allows 32 bit processes to access an additional 1 GB of additional virtual address space above 2 GB.

      Even though Expedition PCB is built to support this additional virtual address space, it is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file.  The following example shows how to add the /3GB parameter to the Boot.ini file to enable application memory tuning:

       

           [boot loader]

           timeout=30

           default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS

           [operating systems]

           multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /3GB

       

      Therefore, starting with 2007.0, Expedition PCB can support up to 3GB of virtual address space if the /3GB parameter is added to the Boot.ini running on Windows XP/Vista.

       

      When running Windows Server 2003 Enterprise Edition you can also enable more memory beyond 2 GB of virtual address space. Customers running this OS can enable Physical Address Extension, thus allowing the operating system to access 1 GB additional virtual address space.  To enable the operating system to use PAE, the ‘/PAE’ switch must be defined in the Boot.ini file. 

       

      64 Bit OS

       

      Another option is for customers to use a 64 bit version of Windows which allows a 32 bit process to access up to 4 GB of virtual address space.  True 64 bit versions of XP and Vista are available and these versions allow 32 bit applications even more virtual address space than is supported by the same 32 bit versions.  No changes are needed to these 64 bit operating systems to take advantage of the additional virtual address space.

       

      Linux

       

      When running 32 bit Linux, the default addressable memory size is also 3 GB.  However, 4 GB of virtual address space can be accessed by a process if the HugeMem kernel is used.  64 bit Linux supports up to 4 GB of virtual address space natively.

       

      Graphics Cards and Memory

       

      The last thing to be aware of is that if you have a 32 bit operating system, you’re limited to 4 GB of virtual address space.  However, this same virtual address space is also used to map the physical memory within your graphics card.  Therefore, the total address space available to the operating system is reduced to less than 4 GB.  In this case, if you have a graphics card with 512 MB of RAM, the available virtual address space will be reduced to 3.5 GB.  64 bit operating systems don’t have this issue since they allow greater than 4 GB of virtual address space.

       

      Reference

       

      Here are some additional references on how Windows operating systems handles large memory support:

      http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

      http://msdn.microsoft.com/en-us/library/bb613473(VS.85).aspx

       

      Regards,

      Jerry Suiter

      ExpeditionPCB/XtremePCB Product Marketing Manager

       

        • 1. Re: Expedition PCB Memory Usage
          yu.yanfeng

          Hi Jerry,

          Thank for the updating!

          I also saw another capacity problem in the Libary Manager.The question is maxium number of part items supported in one partition. That's why I think 64bit Layout tool will be needed.

          Yanfeng

          • 2. Re: Expedition PCB Memory Usage
            Jerry_Suiter

            Yanfeng,

             

            Specific to Library Manager capacity issues, I am not aware of any specific beyond issues what is supported by the OS.  Therefore if the OS only supports 2GB file, then a library partition database would be limited to 2GB.  However, I feel this is a corner case since customers should be properly partitioning their library objects across multiple partitions and having one with 2GB of data would be unmanageable by the librarian and difficult to use by the end user.

             

            In this case of internal database boundaries, switching to 64bit would not resolve the issue since it would require a software change specific to data type, for example limitations of using a signed short integer over other data types must be solved within the software itself.  Again, I am not saying there are boundary issues, I just wanted to ensure that it is understand that switching to 64bit OS or application may not solve them thus requiring software changes.  In the end if an issues is discovered by a customer, then they should use the support process to raise their concerns.  I do believe because of the length of time these databases have been unchanged capacity wise, issues that are found by a customer might be specific to their library process of not using partitioning to organize their library objects.

             

            Regards,

            Jerry Suiter

            ExpeditionPCB/XtremePCB Product Marketing Manager

            • 3. Re: Expedition PCB Memory Usage
              yu.yanfeng

              Yes. It's a limitation from 32Bit Application.I have raised it on the supportnet and communicated with CSE.

               

              Before arranging the partition scheme, User have to get it clear that how many part items can be suported in one partition.As we known, 32bit OS only support 2G application,so individual partition should keep file size below 2GB.It's apparent there is the limitation in maxium number of part items in one partition.O f course the maxium number of part items is dependt on the part types, for big-pins devices such as having over 1000 pins, a 20,000 of maxium item  allowed be estimated. .