Go Back   DisplayLink Forum > DisplayLink Graphics Technology > Linux and Open Source

Reply
 
Thread Tools Search this Thread Display Modes
Old 06-28-2016, 10:45 AM   #1
wdeguara
Junior Member
 
Join Date: Jun 2016
Posts: 9
Default High CPU load and slow display performance

Hi.

Our organisation is in the midst of rolling out the first of 5000 USB 3.0 DisplayLink docks throughout our offices.

We have encountered a problem with Linux compatibility we are seeking assistance with.

Our Linux development team has been testing the latest Displaylink v1.1.62 driver package and experienced a number of issues, particularly in regards to display performance.

To assist with diagnosis of the problem, one of our developers has run the DisplayLink Linux Support tool with the output attached to this post.

The key issue seems to be that of CPU load. As each external display is connected to the usb dock, the cpu load increases substantially to the point where the performance of all displays (including the inbuilt display of the connected laptop) decreases to the extent where the system becomes practically unusable. As an example, a simple keypress would take 1-2 seconds till the characters appear onscreen.

Our developer has also provided a screenshot of 'htop', a system resource monitor, which shows the CPU usage with 2 monitors attached via the DisplayLink usb dock. In particular, it was noted that there were 3 DisplayLink processes consuming high amounts of CPU. It was also noted that Enlightenment (the Window Manager) and X began consuming high amounts of CPU relative to what they'd normally consume. (Enlightenment typically consumes about 2% on 1 core while idle, and X also around 2% on 1 core)

The flavour of Linux used for testing is Gentoo, however we notice from other users posting into this forum that similar symptoms are appearing with Ubuntu as well. As such, we suspect this issue is not specific to the Gentoo flavour of Linux.

Are there any recommendations on how to further troubleshoot this issue ? We are happy to provide additional logs, dumps, and configuration information if it assists the diagnosis.
Attached Images
File Type: jpg shot-2016-06-28_12-21-57.jpg (99.0 KB, 1 views)
Attached Files
File Type: zip lenin_2016-06-28T121529.397059.zip (388.4 KB, 0 views)
wdeguara is offline   Reply With Quote
Old 06-28-2016, 11:35 AM   #2
Sparxy
Junior Member
 
Join Date: Jun 2016
Posts: 12
Default

Which compositor are you using, if any?
It can be noted that DisplayLink CPU usage tends to decrease when using a compositor that only redraws areas of the screen that have changed, as opposed to full-scene redraws.
High CPU usage while the entire DisplayLink screen is constantly updating (i.e. watching a video on it) is considered normal on linux.
Sparxy is offline   Reply With Quote
Old 06-28-2016, 11:48 PM   #3
dkasak
Junior Member
 
Join Date: Jun 2016
Posts: 4
Default

Quote:
Originally Posted by Sparxy View Post
Which compositor are you using, if any?
It can be noted that DisplayLink CPU usage tends to decrease when using a compositor that only redraws areas of the screen that have changed, as opposed to full-scene redraws.
High CPU usage while the entire DisplayLink screen is constantly updating (i.e. watching a video on it) is considered normal on linux.
I'm using Enlightenemnt ( www.enlightenment.org ) built from git. I've also tested with Gnome 3 and had the same results.

As for whether the entire screen was updating - there was an 'htop' terminal on ONE display, which was updated every second or so. Nothing else was happening. Regardless of whether there was screen activity or not, there is constant extreme CPU usage, and very large latency in updating the displays. This can't be "considered normal".
dkasak is offline   Reply With Quote
Old 06-29-2016, 10:40 AM   #4
Sparxy
Junior Member
 
Join Date: Jun 2016
Posts: 12
Default

Quote:
Originally Posted by dkasak View Post
I'm using Enlightenemnt ( www.enlightenment.org ) built from git. I've also tested with Gnome 3 and had the same results.

As for whether the entire screen was updating - there was an 'htop' terminal on ONE display, which was updated every second or so. Nothing else was happening. Regardless of whether there was screen activity or not, there is constant extreme CPU usage, and very large latency in updating the displays. This can't be "considered normal".
Which swap method are you using for the Enlightenment compositor?
Sparxy is offline   Reply With Quote
Old 06-29-2016, 12:39 PM   #5
dkasak
Junior Member
 
Join Date: Jun 2016
Posts: 4
Default

Quote:
Originally Posted by Sparxy View Post
Which swap method are you using for the Enlightenment compositor?
I have it set to 'auto', with the options being:

- Auto
- Invalidate (full redraw)
- Copy from back to front
- Double buffered swaps
- Triple buffered swaps
Attached Images
File Type: jpg shot-2016-06-29_21-34-06.jpg (58.5 KB, 3 views)
dkasak is offline   Reply With Quote
Old 07-21-2016, 06:06 PM   #6
DisplaylInkLinuxUser
Junior Member
 
Join Date: Jul 2016
Posts: 2
Default

I have a similar issue. I have high cpu by the DisplayLinkManager
DisplaylInkLinuxUser is offline   Reply With Quote
Old 07-28-2016, 05:11 AM   #7
dkasak
Junior Member
 
Join Date: Jun 2016
Posts: 4
Default

Sadly, our final solution has been to buy everyone VGA and HDMI cables. Linux support is clearly not there yet.
dkasak is offline   Reply With Quote
Old 10-15-2018, 09:19 PM   #8
JoelAdams
Junior Member
 
Join Date: Oct 2018
Posts: 1
Default Update

Hey Team,

I am still experiencing this issue. Has anyone found an update as to why the CPU utilization for DiplayLinkMana is so high?

Thanks
JoelAdams is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 12:51 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.