What’s the Best PC for Running Multiple DisplayLink USB Monitors?

Posted on 21. Aug, 2010 by in Windows

One of our customers is building a six monitor setup on their PC for stock trading and ESignal Qcharts.

They asked: “What is the best Windows laptop and/or desktop to run six Plugable USB graphics adapters to get six monitors simultaneously on a single PC?” It’s a great question, because there are definitely ways to head off potential problems when you pick a PC. It really comes down to two main things to think about.

Intel Graphics Controller

First, for maximum compatibility with USB graphics products, pick a system with Intel-only graphics if possible. Here’s why:

  1. ATI and nVidia, because they’re shooting for the higher end, do more out-of-the-box things to try to differentiate their technology and software drivers. Sometimes those things can conflict with other complex software, like DisplayLink’s USB graphics drivers.
  2. In particular, look out for “switching” or “hybrid” graphics on laptops. These add a discrete nVidia or ATI GPU on top of the Intel GPU already in the chipset, for the purpose of providing switchable “high power” and “low power” graphics by enabling or disabling one or the other GPU. They attempt to do this switching without Windows noticing (just Like DisplayLink tries to add USB display outputs to the primary graphics controller without Windows noticing), but in combination this can cause conflicts. DisplayLink has made some progress with compatibility with these types of systems, but it’s still the #1 hardware compatibility issue we see for USB graphics.
  3. Even though nVidia and ATI provide higher 3D performance, they don’t have higher performance everywhere: in particular with USB displays, the rendered pixels must be transferred from the GPU back to the CPU to be sent over USB. When the GPU has its own memory on the other side of the PCI bus (as is the usually case with ATI and nVidia), those transfers back can be slow. With Intel chipset graphics, the pixels remain in system memory the whole time – which ends up being faster overall.
  4. Intel is in closer collaboration with DisplayLink than nVidia or ATI has been.
  5. Intel’s is the lowest cost solution. For business applications (like stock trading) with many displays, it makes sense to favor simplicity and compatibility over 3D gaming performance.

nVidia and ATI/AMD are great companies that produce high-performance products, and DisplayLink’s software rarely have problems with them. But as it happens the simplest and lowest cost solution is also the best choice for this particular application.

Mid-range or better CPU and Memory

Second, for the system itself, more memory and a faster CPU make a difference. Take the money saved on a high-end 3D processor, and funnel it back into the main CPU and memory that’ll make everything on your PC faster. But no need to go overboard – there’s usually a sweet spot.

For memory with Windows 7 and something like 6 USB displays, 2GB is enough .. although going to 4 or more will produce noticeable overall system gains (mostly because of all the additional apps you’ll be running to display on all those monitors). Even though Windows 7 is much improved over Vista, multiple monitors and many open applications still consume a lot of memory.

But just as important as the amount of RAM is the amount of cache. In the USB graphics case, memory and the memory controller is getting a lot of use, as pixels change on the screen (at least 4 times – when an application renders new pixels, when those pixels are composited on the desktop, when they’re copied to a shadow framebuffer, and when those changed pixels are compressed into USB packets). Note that once the changed pixels are sent over USB, the CPU isn’t involved anymore to refresh the display .. that work is all done by the hardware framebuffer on the USB device, so in terms of CPU load, it’s just about the pixels that are changing at any given moment.

So what to look for in the CPU’s memory controller? Faster memory interface and larger caches. Products change quickly, but currently Intel’s “Nehalem” microarchitecture provides the best alternatives. The sweet spot currently is with DDR3-1066 memory interface or better and at least 3 MB L3 cache. In terms of particular CPUs, that maps out to Intel CPUs like the the Core i3 530 or higher for the desktop, and the Core i3 330M or higher for laptops.

Hope that helps. Feel free to comment if you have any questions.

DisplayLink Linux kernel driver (udlfb) updates slated for 2.6.37

Posted on 18. Aug, 2010 by in UT-1

The latest set of patches for udlfb, the Linux kernel framebuffer driver for DisplayLink chips, has been submitted and looks on track for kernel 2.6.37. This will catch the kernel up to everything on http://git.plugable.com/

Linux is a big and constantly shifting platform. With our USB graphics products (and generally for DisplayLink based products, since we try to make them work for all devices), it’s easy to output a few pixels, but configuring a USB display as an X terminal, or certainly for an extended desktop, is still a process on Linux that requires manual xorg.conf editing and is for very advanced users only. But we try to contribute what we can at Plugable, and that has meant focusing on making the kernel driver that actually talks to the hardware and everything else builds on, as solid as possible.

The contributed patches start with this post to the linux driver project list.

————–
To: devel-request@linuxdriverproject.org
[PATCH 0/11] staging: udlfb: patches from udlfb development branch (Bernie Thompson)

This patch series contains all current fixes and features from
the udlfb development branch.

udlfb is a framebuffer driver for DisplayLink USB 2.0 era chips.

Diffstat of this 11 part patch series:

udlfb.c | 989 +++++++++++++++++++++++++++++++++++++++++———————–
udlfb.h | 41 +-
2 files changed, 664 insertions(+), 366 deletions(-)

Major changes:

* Added summary documentation for users of udlfb
* Added logic to query DisplayLink chip for max area mode,
so low-end chips on high-end monitors no longer get black screen
* Added support for DPMS. X servers now control monitor
power with existing standard interface
* Added back in support for char interface (e.g. cat file > /dev/fb0)
* Systems without EDID or with failing EDID can now supply fixed
EDID to sysfs interface, also avoiding black screen
* Fixed big-endian (PowerPC) rendering
* Fixed teardown race conditions that could result in shutdown hang
* Added fb_defio and fb console module options (default off)
* Fixed udlfb’s fb_defio client code so no longer incorrectly shares
state across udlfb device instances – fixes hangs and errant rendering
* Removed IFDEFs for building against older kernels – those will
be retained in the udlfb development branches at git.plugable.com

Todo:

There have been no additional reported bugs in the last few months,
although there are several wishlist features. Udlfb may be ready
to move out of staging at this point.

Patches are against Linus’ latest 2.6 tree.

This complete quilt patch series can be downloaded from http://plugable.com/udlfb-patches-2.6.35-v2.tgz