Virtuoso Schematic Composer: slow property window

[kentauta]

Hello all,

When I remotely use (with a Windows-based X-server software) Virtuoso
Schematic Composer installed on a Linux box, it takes about 8 seconds
to close a fully expanded component property window. Shrunk property
windows close very quickly.

According to a network monitoring software, a lot of packets are
trasfered between the X-server software and the Linux server running
Cadence while the property window is being closed. I do not have
such a problem at all when I run Cadence locally on the Linux server
probably because those packets are internally transferred very
quickly. In addition, I have not had this kind of problem with
SunOS-based Cadence.

I have tried several Linux-based servers with different
distributions such as Debian(2.4 and 2.6) and Gentoo(2.6), two
different X-server sotwares, and many different window managers such
as twm, olvwm, etc. However, the same problem occurs in any case.

Version of Cadence is 5.0.33.500.2 (IC5033USR1 lnx86).

Unfortunatelly, I do not have access to Sourcelink as the licenses
belong to my school.

I am wondering if this is a bug of Cadence, and seeking a way to
solve this problem.

Any help is appreciated.

Thank you,

 

[Dylan]

Try starting icfb with 24-bit color disabled,
icfb -no24

-Dylan

 

[kentauta]

Hi Dylan,

Thank you for your suggestion. I tried -no24 and -use8, but I did not
see
any difference.

 

[Zhiheng Cao]

I have exactly the same problem in my environment
(Debian Linux, icfb 5.0.33. Windows with lots of
buttons such as the property window is slow when used
remotely from MSWindows client. The solution I found is to
use TightVNC instead of XWindow.

 

[kentauta]

Thank you Zhiheng.

The property window closes very quickly with VNC although the overall
performance is slightly worse than X-Window.

 

[David Cuthbert]

According to a network monitoring software, a lot of packets are
trasfered between the X-server software and the Linux server running
Cadence while the property window is being closed. I do not have
such a problem at all when I run Cadence locally on the Linux server
probably because those packets are internally transferred very
quickly. In addition, I have not had this kind of problem with
SunOS-based Cadence.

Linux is... different. With the direction that X.org is taking X11, I
would expect remote X to become a non-option in a couple years.
Basically, they're trying to put a lot of stuff in the X layer (better
font services, antialiasing, vectored graphics, message busses), but
this means the client has to interrogate the server far more often.

The X11 protocol was designed in an era when CPUs were ~20 MHz, networks
bandwidth was ~10 Mbit/sec and latency was < 10 msec, and graphics
resources were tight. It made a lot of sense for the client program to
interrogate the X server -- preserving CPU and graphics resources were
very important.

Today, CPU, graphics, and network bandwidth have all increased 100x --
but the speed of light has not kept up. Interrogations between the
client and server are now (relatively) 100x more expensive.

As Zhiheng noted, VNC generally fares better. After the initial
connection is set up, the client and server generally don't interrogate
each other. The server just pushes screen updates as fast as it can to
your client, and your client sends keystrokes and mouse movements back
when appropriate.

The downside is that VNC doesn't know anything about fonts, characters,
lines, rectangles, etc. -- everything is just a bitmap to it (hence why
its protocol is called the Remote Framebuffer protocol). Large updates
(like repainting a schematic) eat up a fair chunk of bandwidth even
though relatively little data is being transferred.

I have some side/personal projects in mind on how to improve this, but
at the rate I'm going on those, I should be getting to them in 10-15
years. <sigh>

 

[fogh]

Linux is... different. With the direction that X.org is taking X11, I
would expect remote X to become a non-option in a couple years.
Basically, they're trying to put a lot of stuff in the X layer (better
font services, antialiasing, vectored graphics, message busses), but
this means the client has to interrogate the server far more often.

The X11 protocol was designed in an era when CPUs were ~20 MHz, networks
bandwidth was ~10 Mbit/sec and latency was < 10 msec, and graphics
resources were tight. It made a lot of sense for the client program to
interrogate the X server -- preserving CPU and graphics resources were
very important.

Today, CPU, graphics, and network bandwidth have all increased 100x --
but the speed of light has not kept up. Interrogations between the
client and server are now (relatively) 100x more expensive.

As Zhiheng noted, VNC generally fares better. After the initial
connection is set up, the client and server generally don't interrogate
each other. The server just pushes screen updates as fast as it can to
your client, and your client sends keystrokes and mouse movements back
when appropriate.

The downside is that VNC doesn't know anything about fonts, characters,
lines, rectangles, etc. -- everything is just a bitmap to it (hence why
its protocol is called the Remote Framebuffer protocol). Large updates
(like repainting a schematic) eat up a fair chunk of bandwidth even
though relatively little data is being transferred.

I have some side/personal projects in mind on how to improve this, but
at the rate I'm going on those, I should be getting to them in 10-15
years. <sigh>

Dave,

I find it a quite insightfull comment. Do you have more to say on the
matter ? like comments on LBX , nomachine NX, citrix or tarentella ?

k.r.

 

[David Cuthbert]

I find it a quite insightfull comment. Do you have more to say on the
matter ? like comments on LBX , nomachine NX, citrix or tarentella ?

Thanks for the compliment.

The only one of these I've had any experience with is LBX (Low Bandwidth
X), though with dxpc (http://www.vigor.nu/dxpc/) instead of the X11R6.3
lbxproxy; from what I understand, they're roughly equal. It helps to
some degree -- especially with those large screen redraws -- but still
suffers from the round-trip-time limitations.

I've heard good things about NX, but haven't gotten a chance to use it
(or Citrix or Tarantella).


Aside:
The fastest remote GUIs I've used are where the GUI is an actual
application running on the head machine and is network aware. I've
written a Tcl app (before my time at Cadence) which allowed me to
control instrumentation in a lab from my cubicle in another part of the
building; because the messages were very small ("move head to 32mm,"
"spin disk," "write track," "get average amplitude," etc.), it felt like
it was the actual control machine (though it was problematic if
something went awry; I was thinking of putting a webcam on it for this
purpose...).

Such applications, though, require much more time to write and debug,
and it's not always clear how to divide responsibilities. In something
like Virtuoso Layout Editor, for example, it could easily be worse to
push the polygons across the pipe than just send a bitmap representation.

 

[Frank E. Gennari]

Thanks for the compliment.

The only one of these I've had any experience with is LBX (Low Bandwidth
X), though with dxpc (http://www.vigor.nu/dxpc/) instead of the X11R6.3
lbxproxy; from what I understand, they're roughly equal. It helps to
some degree -- especially with those large screen redraws -- but still
suffers from the round-trip-time limitations.

I've heard good things about NX, but haven't gotten a chance to use it
(or Citrix or Tarantella).


Aside:
The fastest remote GUIs I've used are where the GUI is an actual
application running on the head machine and is network aware. I've
written a Tcl app (before my time at Cadence) which allowed me to
control instrumentation in a lab from my cubicle in another part of the
building; because the messages were very small ("move head to 32mm,"
"spin disk," "write track," "get average amplitude," etc.), it felt like
it was the actual control machine (though it was problematic if
something went awry; I was thinking of putting a webcam on it for this
purpose...).

Such applications, though, require much more time to write and debug,
and it's not always clear how to divide responsibilities. In something
like Virtuoso Layout Editor, for example, it could easily be worse to
push the polygons across the pipe than just send a bitmap representation.

I'm not sure how Virtuoso and various X servers transfer data over the
network, or whether it can be done better. It really depends on the type
of data. If your screen is, say, 1024x1024 at 24-bit color, that's 3MB of
data. If the data consists of only a few unique colors (for instance
layout layers), a 256-color index will produce 1MB of data. If the colors
are solid (non-stipple) or mostly black background, you can compress it to
< 100K. Also, if only part of the image changes this will be even less,
especially if the server caches the image around the visible window. That
should in theory be very fast if the client/server understand these
optimizations.

Now, vector data will likely be larger for all but the smallest designs,
as rectangles are 16 bytes each and in general can't be compressed nearly
as well as images. Of course, the entire design could be sent over the
network as vector graphics during "load". If you're just viewing it, then
this amounts to copying the design onto the local machine and just viewing
it with a local tool, which is probably what you want to do. If editing is
required and the geometry is changing then it's much harder.

I've had to deal with slow graphics many times, and I keep wanting to
create my own solution to it but I'll probably never have the time. Maybe
eventually someone will have a good client/server that is optimized for
layouts/schematics. It doesn't seem too difficult to create this for a
fixed OS/platform. Exceed can work well if you set all of the
optimizations/window settings to the correct values, which is quite a
task, and maybe some day they will add an "Optimize for CAD tools" button
to it.

Frank

Frank

 

[David Cuthbert]

I'm not sure how Virtuoso and various X servers transfer data over the
network, or whether it can be done better.

Generally, it's instructions such as "draw a line from P0 to P1 using
PEN0" and "draw a rectangle from P2 to P3 using BRUSH0", where PEN0 and
BRUSH0 must be defined earlier. Virtuoso's layout canvas probably has
some optimizations built into it, but I'm not familiar with that part of
the code (and probably couldn't divulge much if I did...).

It really depends on the type
of data. If your screen is, say, 1024x1024 at 24-bit color, that's 3MB of
data. If the data consists of only a few unique colors (for instance
layout layers), a 256-color index will produce 1MB of data.

Yep. This is how VNC looks at the world.

If the colors
are solid (non-stipple) or mostly black background, you can compress it to
< 100K.

Whether something is solid or not matters only for run-length encoding
algorithms. Back in the day, this was the only image compression
algorithm that was feasible for realtime operations. Now with
processing power being far greater than network bandwidth,
pattern-matching (LZW/GIF and gzip/PNG) and frequency-space (JPEG)
algorithms are feasible (and used) for image compression.

Also, these are, (mostly) general purpose compression algorithms. If
the compressor/decompressor agree on some "pre-knowledge" about the data
being transferred, compression can get much better. For example,
transferring an image of the string "Cadence", rendered in Helvetica
with antialiasing at a height of 100 points occupies ~60000 bytes
(before compression). On the other hand, if I can tell the client to
render the string "Cadence" in font #1 (agreed upon as Helvetica,
antialised), point size 100, with a lower left corner at P0, this would
require maybe 28 bytes (and carries *more* information with it -- it's
text with the content Cadence in addition to an image of said text).

Now, vector data will likely be larger for all but the smallest designs,
as rectangles are 16 bytes each and in general can't be compressed nearly
as well as images. Of course, the entire design could be sent over the
network as vector graphics during "load". If you're just viewing it, then
this amounts to copying the design onto the local machine and just viewing
it with a local tool, which is probably what you want to do. If editing is
required and the geometry is changing then it's much harder.

As you note, there's a big difference between just looking at the data
and manipulating it.

The OASIS guys might have a bone to pick with you about the assertion
that rectangles are not very compressible. They've done a fair
amount of work in this regard. I've been curious to try to gzip an
OASIS dataset -- this is a good qualitative test for how much
compression has been achieved.

I've had to deal with slow graphics many times, and I keep wanting to
create my own solution to it but I'll probably never have the time. Maybe
eventually someone will have a good client/server that is optimized for
layouts/schematics.

Personally, I don't think that EDA tools are anything special in this
regard. We're just more aware of it because EDA users find themselves
having to use remote displays more often than the general public for a
multitude of reasons:
* Platform and licensing issues (it'd be expensive to get a license
for every laptop/home computer)
* Restrictions on transferring IP (I can't imagine Intel allowing
their engineers to take chip layouts out of the building)
* The users are just more savvy (i.e., most people probably aren't
aware that a computer can be used in this fashion).

I just don't think that the remote display problem has been
satisfactorily solved. Unfortunately, I doubt that we at Cadence or
anyone else in EDA will solve it -- while we're aware of the problem,
it's just not something we have the expertise in.

 

[David Cuthbert]

It seems you brushed already a portrait for the ideal thin client: use
generic bitmap compressors to start with, but train the compressor at
the same time. The trainer will detect that X client called virtuoso
layout editor has been lately using a given set of stipples, fonts, and
so forth, and for instance send a dictionary to the client when it is
obvious that that will give better performance than generic bitmap
compression.

You've hit on a good model -- it's similar to one I thought about for a
web-based chalkboard, but had a fatal flaw there which doesn't apply here.

The goal is to get an updated screen to the user as soon as possible.
Thus, for a large, complex update (maybe the user is joining in to an
existing session), push the bitmap across -- don't bother trying to tell
it about lines, stipples, fonts, etc. We can do that, however, for
small, incremental updates: say you've dragged a device, so erase this
area, put a few lines down, done.

The flaw for the chalkboard was that I wanted to make the shapes behave
as objects that the user could manipulate. Not easy to do if all you've
sent across is a bitmap.

That said, I have also an impression that indeed round-trip-times and
limiting the number of client-server negociations is more important than
dealing with bandwidth improvements. So this kind of compressor should
also know how to short-circuit those negociations.

This is easy to do. First, spec out a virtual machine for this purpose.
Then the display side implements it, while the application side models
the changes being made. The application should never have to
interrogate the display about its state -- it's all contained within the
server.

(Thinking about this a bit, I realized that this is essentially what
NASA, ESA, etc., do during their space missions. If you've seen the
Apollo 13 movie, recall the scene where the ground team is trying to rig
up an oxygen scrubber from the parts on the spacecraft. Rather than
waste time asking the astronauts if they have this filter, that torque
wrench, etc., they use their model of the spacecraft to figure out how
to put the scrubber together. Same thing as what I'm describing, just
with higher stakes.

( Sorry if my jargon is not right and this all sounds like hocus-pocus,
but I have not studied CS. )

Ah, don't worry. CS lost all jargon credibility when someone decided to
call the client you sit at the "X server" and the server that runs your
application the "X client".

(I'm an EE who learned how to do this software stuff because I had
gotten fed up with bad and non-existent design tools. It'll take me
awhile to fix it all, but my little one-man revolution is churning
along...

It is understandable that cadence does not work on these matters
directly, but it could participate otherwise in development efforts. I
don t find that VNC has made much progress since it was AT&T's. I tried
NX a long time ago, while it was not stable enough to start a gnome or
CDE desktop.

Heh, well, keep in mind that VNC was written as a side project at AT&T,
and it's now mature. What this means is that there's no group whose
main charter is to fix and improve it, and it's a mature project which
means that those who *do* work on it in their spare time need to make
sure they don't break backwards compatibility. Even so, there have been
a few interesting efforts out there -- I personally use TightVNC, as
they added a couple compression schemes which perform well.

Oh, and don't forget about some of the cool stuff others are doing with
VNC. I find vnc2swf a nifty tool for generating demos. (SWF =
Shockwave Flash; vnc2swf = tool which records a VNC session to a Flash
movie).

vnc2swf can be found at http://www.unixuser.org/~euske/vnc2swf/

 

[fogh]

Generally, it's instructions such as "draw a line from P0 to P1 using
PEN0" and "draw a rectangle from P2 to P3 using BRUSH0", where PEN0 and
BRUSH0 must be defined earlier. Virtuoso's layout canvas probably has
some optimizations built into it, but I'm not familiar with that part of
the code (and probably couldn't divulge much if I did...).



Yep. This is how VNC looks at the world.



Whether something is solid or not matters only for run-length encoding
algorithms. Back in the day, this was the only image compression
algorithm that was feasible for realtime operations. Now with
processing power being far greater than network bandwidth,
pattern-matching (LZW/GIF and gzip/PNG) and frequency-space (JPEG)
algorithms are feasible (and used) for image compression.

Also, these are, (mostly) general purpose compression algorithms. If
the compressor/decompressor agree on some "pre-knowledge" about the data
being transferred, compression can get much better. For example,
transferring an image of the string "Cadence", rendered in Helvetica
with antialiasing at a height of 100 points occupies ~60000 bytes
(before compression). On the other hand, if I can tell the client to
render the string "Cadence" in font #1 (agreed upon as Helvetica,
antialised), point size 100, with a lower left corner at P0, this would
require maybe 28 bytes (and carries *more* information with it -- it's
text with the content Cadence in addition to an image of said text).



As you note, there's a big difference between just looking at the data
and manipulating it.

The OASIS guys might have a bone to pick with you about the assertion
that rectangles are not very compressible. They've done a fair
amount of work in this regard. I've been curious to try to gzip an
OASIS dataset -- this is a good qualitative test for how much
compression has been achieved.



Personally, I don't think that EDA tools are anything special in this
regard. We're just more aware of it because EDA users find themselves
having to use remote displays more often than the general public for a
multitude of reasons:
* Platform and licensing issues (it'd be expensive to get a license
for every laptop/home computer)
* Restrictions on transferring IP (I can't imagine Intel allowing
their engineers to take chip layouts out of the building)
* The users are just more savvy (i.e., most people probably aren't
aware that a computer can be used in this fashion).

I just don't think that the remote display problem has been
satisfactorily solved. Unfortunately, I doubt that we at Cadence or
anyone else in EDA will solve it -- while we're aware of the problem,
it's just not something we have the expertise in.

Frank, David,

It seems you brushed already a portrait for the ideal thin client: use
generic bitmap compressors to start with, but train the compressor at
the same time. The trainer will detect that X client called virtuoso
layout editor has been lately using a given set of stipples, fonts, and
so forth, and for instance send a dictionary to the client when it is
obvious that that will give better performance than generic bitmap
compression.

That said, I have also an impression that indeed round-trip-times and
limiting the number of client-server negociations is more important than
dealing with bandwidth improvements. So this kind of compressor should
also know how to short-circuit those negociations.

( Sorry if my jargon is not right and this all sounds like hocus-pocus,
but I have not studied CS. )

It is understandable that cadence does not work on these matters
directly, but it could participate otherwise in development efforts. I
don t find that VNC has made much progress since it was AT&T's. I tried
NX a long time ago, while it was not stable enough to start a gnome or
CDE desktop.