NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR01G00520
Applies to: NX Software
Added on: 2009-01-07
Last update: 2019-02-01
Users may experience slowness when using Cadence Virtuoso with NX 3.5.0 and other 3D applications

Some of our customers have reported they experienced slowness when using the Cadence Virtuoso CAD application with NX. In particular, they put in evidence problems related to time requested for starting-up the CAD design application (it can need even 4 minutes) and the interactive responsiveness of the application.

By analyzing the data traffic statistics generated during the use of  Cadence Virtuoso 6.1, we can see that even if the NX compression is working fine, the amount of data to be transfered is often more than a few MBytes per seconds. 

The X11 requests generating high traffic are:

PolyRectangle (67)
PolyFillRectangle (70)
PolySegment (66)
FillPoly (69)

The FillPoly requests take almost the 7% of total amount of traffic, while the other three groups of requests take together the 90%.  It is also worthy to note that only a few of these X11 requests are cached. This can be explained with the complexity of pictures created using Cadence, so that almost all requests are different and can't be cached.

Analysis of the NX Server Side Protocol Statistics

Below you can see an excerpt of partial statistics for requests 66, 67, 69, and 70
gathered during about ten minutes of session running. Note that protocol compression ratio is about 21:1.

Request: #66          
Total:
64612    
Cached: 8361
Bits In: 1262262336 (154085 KB)           
Bits Out:
176497000 (21545 KB)  
Bits/Request: 19536/1 -> 2732/1         
Ratio: 7.152:1


Request: #67    
Total: 171639              
Cached:
Bits In:2171848224 (265118 KB)
Bits Out: 180637015 (22050 KB)  
Bits/Request: 12654/1 -> 1052/1         
Ratio:12.023:1

Request: #69    
Total:1489194 
Cached: 1489180           
Bits In: 431912960 (52724 KB)  
Bits Out: 15685630 (1915 KB)      
Bits/Request: 290/1 -> 11/1                
Ratio: 27.536:1

Request: #70    
Total: 139323  
Cached: 11324  
Bits In: 1679304160 (204993 KB)           
Bits Out: 168157612 (20527 KB)  
Bits/Request: 12053/1 -> 1207/1         
Ratio: 9.986:1


time: 459765 Ms idle, 104560 Ms (102444 Ms in read, 2116 Ms in write) running.

Protocol compression ratio is 21.417:1.

Some suggestions which may improve responsiveness

Using different settings in the NX Session could help to make the NX session more responsive. For example:

1-  Increase the cache size on disk (to be set in the NX Client GUI -> Advanced tab) . If CPU usage should increase significantly, try to set size 0 for cache instead.

2- Use link type MODEM or ISDN ( to be set in the  NX Client GUI -> General tab).

Deferring updates of the user's screen areas as possible solution

However, to fully support such graphical-intensive applications, we would need to implement a mechanism similar to the lazy encoding we are already using for the PutImage requests to defer the screen updates when the network is congested. 

This lazy encoding mechanism should be applied to all the graphics primitives, mainly for PolySegment and PolyRectangle requests, but even for CopyArea, PolyPoint , PolyFillRectangle, etc...

Based on the fact that nxagent knows the status of the network connection, when the connection is congested it could execute the X11 requests only on its internal frame buffer and send the information for updating the end-user's screen -in form of compressed images- only when the congestions status has decreased.

This would  improve the network traffic, since the image data needed to repaint the out of date screen areas would be much less than data carried by the thousands of X11 requests produced by this specific application.

A Feature Request has been opened to implement a generic display update policy to help with CAD software packages.  The Feature Request can be viewed here: