Input lag on TBT3-UDZ with macOS Big Sur

Hey all,

Really liking my UDZ so far, other than having repeated issues with input lag on things directly connected to it. It’s been happening both with a Logitech unifying receiver for an MX Master mouse, as well as with a CamLink 4k from Elgato. Both will operate fine for a while before the mouse starts to stutter, and the CamLink works fine for several minutes before it freezes.

Neither happens when the devices are connected directly my MacBook Pro, bypassing the dock.

Any suggestions? Happy to provide logs or anything else to help troubleshoot!


Thank you for contacting Plugable support! Sorry to hear about this issue. I’d be more than happy to assist you.

I do not know what would be causing this freezing issue, though, we have had two other reports from customers of this kind of behavior as well (also described as lag when there’s a lot of movement on screen or with mouse pointer movement). We’re trying to reproduce this issue ourselves, but have yet to be able to so far in our testing with dual 4K displays at 60Hz here on several Mac models.

Can you say which exact Mac model you have? We have a possible theory that should be easy enough to test. If you have a MacBook Pro with both Intel and AMD graphics, the system is designed to dynamically switch between these two GPUs. There’s a setting to disable this, I’m curious if this would have any effect on the lagging issues if you have a moment to test this out. To turn off GPU switching see here:

This will tell the system to only use the AMD graphics, which when using the dock may be preferable since that GPU is far more powerful. If there’s no change, or if your system is Intel graphics only, we’ll have to keep investigating.

I apologize for not immediately having a solution, but we’re making this a top priority.

Please don’t hesitate to let us know of other questions.

Thanks again for contacting Plugable support and best wishes!

Joshua Henry

Senior Engineer | Product Owner
Plugable Technologies

Hey Joshua!

Thanks for the quick reply. I have a 2019 16" MacBook Pro. I’ve attached a screenshot of the exact configuration.

I’ve given the automatic graphics switching checkbox a shot - I wasn’t in front of my desk much today, but I’ll see if it’s any better tomorrow and report back.

Thanks for the info, and for giving that a shot!

I have a similar system I’ve been testing, so far I’ve not been able to reproduce the issue. For reference, mine is the 2019 15" with the 6-Core i7 and Radeon 555x.

We do have a 6-core i7 16" model with the newer generation Radeon that I should be able to test with as well. I’ll see about procuring this to more closely match your system for my additional testing.

Please do keep me in the loop with your findings with the changed setting!


I believe I’ve come across the same problem. I start with only a USB mouse attached to the front port and my HP 2159 display was attached (DVI port of display connected to Plugable hub via DVI to HDMI cable) to the HDMI port farthest from the power port.

When I unplug the HDMI cable and plug it back in the stuttering of the mouse starts. If I just move the cursor around in a circle it will move normally for a bit, stop for a fraction of a second, and then continue on. This effect can continue sometimes for over a minute before the problem stops.

It appears that there is a direct correlation between the stuttering and the following errors in the Console:

default 18:44:57.288458-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141507375009792, nextTime: 141507575008961, crtc: 3! default 18:44:59.885859-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141509972339595, nextTime: 141510172338210, crtc: 3! default 18:45:02.405371-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141512491768586, nextTime: 141512691767791, crtc: 3! default 18:45:04.956589-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141515042928931, nextTime: 141515242928141, crtc: 3! default 18:45:07.584358-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141517670626316, nextTime: 141517870625633, crtc: 3! default 18:45:10.101996-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141520188198523, nextTime: 141520388195771, crtc: 3! default 18:45:12.644109-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141522730239548, nextTime: 141522930239058, crtc: 3! default 18:45:15.243848-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141525329905851, nextTime: 141525529905551, crtc: 3! default 18:45:17.763298-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141527849287081, nextTime: 141528049286468, crtc: 3! default 18:45:20.303536-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141530389456143, nextTime: 141530589452283, crtc: 3! default 18:45:25.424068-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141535509849060, nextTime: 141535709845544, crtc: 3! default 18:45:27.963566-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141538049276309, nextTime: 141538249276041, crtc: 3! default 18:45:30.587791-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141540673429580, nextTime: 141540873428250, crtc: 3! default 18:45:33.105566-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141543191134333, nextTime: 141543391134273, crtc: 3! default 18:45:35.679614-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141545765112044, nextTime: 141545965108642, crtc: 3! default 18:45:38.302473-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141548387899809, nextTime: 141548587897399, crtc: 3! default 18:45:40.821839-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141550907195460, nextTime: 141551107194261, crtc: 3! default 18:45:43.372704-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141553457989644, nextTime: 141553657984611, crtc: 3! default 18:45:45.963366-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141556048579820, nextTime: 141556248575063, crtc: 3! default 18:45:48.479156-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141558564302539, nextTime: 141558764300614, crtc: 3! default 18:45:51.032250-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141561117327064, nextTime: 141561317323772, crtc: 3! default 18:45:53.629091-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141563714097104, nextTime: 141563914097028, crtc: 3! default 18:45:56.158979-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141566243913312, nextTime: 141566443908205, crtc: 3! default 18:45:58.698028-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141568782873883, nextTime: 141568982873068, crtc: 3! default 18:46:01.302429-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141571387222373, nextTime: 141571587217195, crtc: 3! default 18:46:03.822489-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141573907214546, nextTime: 141574107213971, crtc: 3! default 18:46:06.365813-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141576450468641, nextTime: 141576650467302, crtc: 3! default 18:46:11.495047-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141581579559061, nextTime: 141581779557986, crtc: 3! default 18:46:14.035765-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141584120210625, nextTime: 141584320207444, crtc: 3! default 18:46:16.638031-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141586722404573, nextTime: 141586922403546, crtc: 3! default 18:46:19.157790-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141589242093458, nextTime: 141589442092991, crtc: 3! default 18:46:21.698869-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141591783103500, nextTime: 141591983102925, crtc: 3! default 18:46:24.302232-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141594386391192, nextTime: 141594586388879, crtc: 3! default 18:46:26.821480-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141596905573315, nextTime: 141597105572096, crtc: 3! default 18:46:29.364543-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141599448566566, nextTime: 141599648563254, crtc: 3! default 18:46:31.965435-0500 kernel [3:0:0] [HDCP:3] runEvent() !!! Action is stall currentTime: 141602049384942, nextTime: 141602249384917, crtc: 3!

Generally each error line equates to a single stalling instance of the mouse, with few exceptions. And when the errors stop showing up, the mouse problem goes away too. The interval between the error messages is about 2.39 seconds

My systems specs are:
macOS Catalina (10.15.7)
MacBook Pro (16-inch, 2019)
Processor: 2.4 GHz 8-core Intel Core i9
Memory: 64 GB 2667 MHz DDR4

  • AMD Radeon Pro 5500M 8 GB
  • Intel UHD Graphics 630 1536 MB

If more details or tests would be helpful, please let me know.

1 Like

Thank you for sharing this info @Wanderer. Doing some online research for this type of error, I am seeing others who’ve experienced it. Some reports going back prior to our dock release, so this may be a more general macOS issue. I’ve not found any conclusive reasons for this behavior, nor have I found any real solutions, but I have shared this information with our team to discuss and explore possible options.

If you try connecting a different display, perhaps an HDMI TV which should support HDCP, does that also cause the stuttering? I’m wondering if in your specific case if your DVI display doesn’t properly support HDCP.

EDIT: Your monitor should support HDCP:

Thank you!

I just ran a few more tests that might be helpful in the meantime before I test other displays, etc:

A) I moved the USB mouse a port directly on the MacBook so the only thing attached to the dock was the display. When I unplugged the display and plugged it back in the same errors occurred and the mouse stuttered the same as when the mouse was routed through the dock.

B) Suspecting a more general error as you also mentioned, I disconnected the dock altogether and used a USB-C to HDMI adapter to plug the HDMI to DVI cable into the screen. While the same error occurred, sometimes, it only happened once or twice before going away - and that’s if it had the issue at all. So while the issue is not strictly the dock, it appears the dock’s presence amplifies the issue.
19:25:13.573856-0500 kernel [3:0:0] [HDCP:2] runEvent() !!! Action is stall currentTime: 143923647744789, nextTime: 143923847738538, crtc: 2!
Whatever the crtc is, it appears to vary if it’s the dock (3) or the USB-C to HDMI adapter (2)

C) I left the dock connected and powering the MBP with nothing else attached to the dock. I then had the usb mouse directly attached to another port, and the USB-C to HDMI adapter on the third USB-C port. When I disconnect and reconnect the HDMI cable then the same 0-2 stutters occur before stopping. So the routing of the HDMI signal through the dock is definitely amplifying the issue. Though if it’s simply plugged in but not used for anything besides power then it doesn’t amplify the problem.

D) If I only plug the HDMI screen into the dock, and have nothing else plugged into the MBP, then if I use the touchpad on the MBP, each time the errors pop up then there’s a stutter to the cursor moving around. So the issue doesn’t require an external usb mouse.

What I’m curious about it whether the issue is the USB system being locked up, or if the whole system is freezing for that moment. Further tests will answer that.

If the issue with the dock is identified as a firmware issue, is there a way for the firmware to be updated? Or would the device need to be returned and replaced?

I just played a video while the cursor was stuttering, and it appears that the cursor freezing does not also freeze the screen and video

Screen Recording 2020-11-30 at 9.40.37 PM

Quick update this morning from me, too. Disabling automatic graphics switching did not help. My display is connected via DisplayPort (a Dell U2720Q), and the stuttering is just as bad as regardless of the graphics setting.

Oddly, the problem seems to happen significantly less frequently - possible going away completely - if I use the USB ports on the front of the dock. I’m going to try that for the rest of the day today, but so far this morning it was a night and day difference switching the receiver to the front USB ports instead of the back ones.

It definitely does not happen when the mouse receiver is directly connected to the MacBook Pro, though.

Fun bug!

@kputnam Thanks for the update. I wonder if there are several issues happening here that may seem similar, but be very different in nature. If you’re seeing no issues with the mouse directly through the laptop, and lesser issues by moving the mouse receiver to the front of the dock, that is different than the behavior @Wanderer has mentioned (where the issue with the mouse seems to happen directly via the laptop too).

Since you’ve got a wireless mouse, this could be an interference problem (many wireless mice operate on the 2.4GHz spectrum, USB 3.0/USB-C/Thunderbolt 3 devices are prone to emit some interference on this same frequency which we’ve seen cause poor mouse behavior before). Do you have a wired mouse to try? If you do, that could help us really narrow down this behavior.

How’s your Elgato CamLink doing? Does it behave differently if connected via front or rear?

Thanks for bearing with us as we work through these things!

@Wanderer Thanks for providing all of that extra information! It’s really appreciated. Some interesting behaviors you’ve noted.

Before we go further, I’d like to try and take a step back to see if we can narrow this down a little further. I’d asked, but understand it may not be possible, for you to possibly try a different display with native HDMI like a TV to see if the behavior is different. This will allow us to determine if the current HP display and/or the HDMI to DVI video cable are in any way contributing to the behavior here with the HDCP errors.

I do understand the errors are lesser when using a USB-C to HDMI adapter instead of the dock, so our dock could be making the issue worse in some way. There’s just too many variables to draw any solid conclusions at this moment which is why I’d like to test with a different display to see what happens if we can! Apologies for the hassle with this request.

You’d asked:
“If the issue with the dock is identified as a firmware issue, is there a way for the firmware to be updated? Or would the device need to be returned and replaced?”

We would likely need to replace it. However, firmware development for Thunderbolt 3 products is not a trivial process. Updates would likely need to be approved by Intel and possibly other involved parties as there are strict standards and processes for Thunderbolt 3 devices that must be adhered to.


@Joshua_H Yup, I saw your request for trying a different screen. I just hadn’t dug out a different screen yet to be able to test for that. I’ll get back with those results once I have them. I’ll also try using a straight HDMI cable as well so there’s no adapting going on.

Since kputnam’s issue appears to be a bit different from what I’m encountering, should I open a separate thread or continue to post in this one?

1 Like

No worries @Wanderer Just wanted to check that. If we can split these issues up, that may be ideal for the sake of clarity for kputnam or others who’re reading through the forum. If you’re OK with it, feel free to post a new topic and link to this one for reference. Or, I can move our conversation over to you through e-mail directly if that’s preferred. Whatever is easiest for you! Thanks for working through these issues with us, it’s most appreciated.


Cool. I’ll make a separate thread then and reference this one. I prefer a public forum over email since it provides transparency to other individuals in the future who may encounter similar issues.

1 Like

So I have been experiencing the same input hang that @Wanderer demonstrated in his GIF. It seemed to be related to the polling/reporting rate on my mouse. I have experienced it before as well, rapid mouse movement would result in a cursor hang.

Adjusting my polling rate down below 500 resolved the issue for me. Interestingly though, I was able to raise it again without the hang returning. But upon reconnect to the dock the hang would return.


Thanks for sharing this information. Good to know that you seem to have been able to resolve it, but if that changes just let us know. For now, we’ll keep our eyes out for other instances of this behavior.

I started a new thread with new information on the issue:

Thanks for the heads up. I’ll take a look and comment!

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.