Regarding sluggish performance on the secondary

Inerrupts and DPCs through the roof

from JoeUser Forums
Greetings,

I have been having an ongoing problem using Multiplicity with my Motion M1300 TPC. And it appears to be getting worse with each update.

Configuration:

Dell Dimension 4550 3.02 GHz desktop for the primary
Motion M1300 1.0 GHz Pentium-M with 1G RAM
100BT Ethernet connection

Here's what I've observed:

1) Clean boot works fine

2) Disconnecting the TPC from the Ethernet and using it elsewhere with wireless leads to a little problem when returning to the network. Mostly manifests as the clipboard not working in either direction between the systems and random, fairly frequent disconnects between the system when using the KB and mouse on the secondary.

3) Disconnecting the TPC and putting the TPC into standby or hibernate results in the Multiplicity front-end crashing on the way down. Upon return, after a short period of normal operation, CPU utilization starts to climb. Examination using Process Explorer from systinternals.com shows that Interrupts and DPCs are soaking up a tremendous amount of CPU time. Starting at about 25% each and climbing until they soak it all up. Restarting Multiplicity cleans up the problem for a short time and then the slide starts again. Reboot required to clean it up.

That's what I have. The rest is up to The Powers That Be.
thinkdesk
5,447 views 6 replies
Reply #2 from Stardock Forums Top
Mark,

I know there were some bugs with Multiplicity and PowerSave/Hibernation. I am not sure if they were cleared up or not. I will see what I can find out for you.
Sins of a Solar Empire II
Reply #4 from Stardock Forums Top
Intel PRO/100 VE on the desktop

Realtek RTL8139/810X on the tablet
Reply #5 from Stardock Forums Top
Some new information:

I started playing around with various permutations of restarts yesterday when the % CPU for the Interrupt handler on the secondary was exceeding 30% when nothing was happening. Unloading Multiplicity on either end would stop the problem, albeit causing some limitation to Multiplicity's functionality. At this point I was theorizing that the primary was bombarding the secondary with some sort of traffic. But I couldn't get it to stop. Unloading Multiplicity, restarting the Multiplicity service and reloading Multiplicity did nothing. As soon as the connection was reestablished the % CPU for the Interrupt handler on the secondary would jump.

I rebooted the primary to no avail. Finally, I rebooted the secondary and things returned to normal. Well, not really. This morning the % CPU was up to almost 20% and presumably would have continued climbing. So I started poking around at some of the advanced settings. I hit it on the first try. Disabling 'Quick detection of disconnected secondary machines' did the trick. Conceptually I can understand why this would generate traffic. What I can't figure is why does it increase over time.
Reply #6 from Stardock Forums Top

Thats an advanced user option and isn't enabled by default.

It may be that by sending lots and lots of tiny packets to the secondary machine it is exposing some sort of leak which gradually makes processing the packets more & more cpu intensive.