Applies To:
  • CitectSCADA 3.40 4.20
Summary:
We have tried version 4.20 on two client workstations. One running Windows95 and One running Windows NT Workstation 4.0 Beta2. Both were setup using all the normal default settings. Our IO server is running Citect V3.30 under Windows95. The test client workstations were tested individually on the existing control system. In both instances, after displaying a page of about 70-80 tags (including Disk PLC tags) for a few minutes the IO server starts to report Out of buffers lan.read.pool and the Kernel buffer pool display's short count for lan.read.pool rises. If the offending client is not shutdown in time, the IO server eventually slows down to a crawl and some of the other clients on the system lose contact with the IO server (Display tags greyed out).

We do not experience this problem if we run Citect V3.3 on these same client workstations. Could this problem be related to the mixing of 16 and 32 bit client applications with a 16 bit application on the IO server?

 

Solution:
In version 3.40 and 4.20 we have made various changes in increase the network performance. This was mainly to cover the case when using TCP/IP as the network protocol for Citect client/server communication. Microsoft has put in place various "Optimisations" in TCP/IP which clash with Citects real time requirements. In version 4.20 (not 3.40) we have increased the defaults for the [LAN]ReadPool and [LAN]WritePool to 256. They are still set at 64 in version 3.40 as these buffers use critical DOS memory under Windows 3.11. We have also added a feature to try to work around the performance degrading effect of TCP/IP. This feature is enabled by default and you can disable it by setting [LAN]KillPiggyBackAck=0. This feature has been added to versions 3.40 and 4.20. This feature causes extra network traffic and if the Citect at the other end is before version 3.40 or 4.20 it will cause extra loading on the lan.read.pool.

So what is happening in your setup is that the 4.20 computer is sending data very quickly to the 3.30 computer. The 3.30 computer cannot keep up with this data rate so it's receive buffers full up.

Your solutions are:

  1. Install Version 3.40 instead of version 3.30 on the I/O Server (best solution).
  2. Set [LAN]KillPiggyBackAck=0 on the 4.20 computer to slow down the transmission. This will solve the problem, however you will get degraded performance if you are using TCP/IP or IPX. If you are using NetBEUI then you will see no degrade in performance.
  3. Set the [LAN]ReadPool=256 on the 3.30 computer to increase the size of the LAN read pool. This may not solve the problem.

Also if possible you should upgrade the 3.30 I/O server to 4.20 if there is 32 bit drivers for all the protocols you want to use.

 
Keywords:
 

Attachments