Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

performance analysys #5

Open
efschu opened this issue Apr 17, 2023 · 7 comments
Open

performance analysys #5

efschu opened this issue Apr 17, 2023 · 7 comments

Comments

@efschu
Copy link

efschu commented Apr 17, 2023

Hi,

I want to share my experiences on optimizing UPS and power usage. (Because I have a 144Hz display so I want to reach (at least) 144 UPS but with polling rate 1 it is not reached all time)

note that I have pinned lgproxy source to Core 6 and Core 7

default CPU clock with polling rate 1 I get around 130 UPS while one core runs on 100%:
0.0924W / UPS
https://github.com/efschu/debuglgproxy/blob/main/Bildschirmfoto%20vom%202023-04-17%2007-43-35.png?raw=true

CPU in powersave state with polling rate 1 I get around 120 UPS while one core runs on 100%:
0.0242W / UPS
https://github.com/efschu/debuglgproxy/blob/main/Bildschirmfoto%20vom%202023-04-17%2007-44-23.png?raw=true

default CPU clock with polling rate 0 I get around 260 UPS while one core runs on 100% and another on ~60%:
0,0765W / UPS
https://github.com/efschu/debuglgproxy/blob/main/Bildschirmfoto%20vom%202023-04-17%2007-45-31.png?raw=true

CPU in powersave state with polling rate 0 I get around 230 UPS while one core runs on 100% and another on ~66%:
0.0236W / UPS
https://github.com/efschu/debuglgproxy/blob/main/Bildschirmfoto%20vom%202023-04-17%2007-45-42.png?raw=true

So we see that it doesnt realy matter if the CPU runs on 560MHz or on 4.7GHz and I think there is plenty of room for optimization for getting higher UPS with lower cpu usage.

Maybe this analysys helps you improving this project.

And many thanks for your great work, I love your project and I'm using it personaly almost daily since last year.

@beanfacts
Copy link
Member

Hi,

Thanks for your performance analysis and using the project. Internally due to the way RDMA is designed to work most of the time is spent by the CPU just polling for data availability, so your setup with the lower clock speed is probably the best idea for efficiency at the moment.

LGProxy 0.2.0 intends to address these issues in a few ways:

  • Polling intervals will be float values: you can fine-tune it as much as you like (also under 1ms)
  • Polling will be performed on a single thread: setting a polling rate of 0 will consume 100% of a single core instead of 2, with no significant latency impact
  • Direct placement of mouse data: no copying should ideally reduce latency

I don't have a timeline, but the update is ~80% of the way there. I hope the upcoming updates will improve the usability and performance for you.

Please let me know if you have experienced any issues (specifically related to performance, rendering, glitches, etc.) so they can hopefully be fixed by the next release.

@efschu
Copy link
Author

efschu commented Apr 23, 2023

Nice to hear. Will udp be supported on next build?

@beanfacts
Copy link
Member

UDP will probably not be supported due to limitations that would require a complete change to the way messages are constructed and handled. For reference, enabling TCP support in LGProxy required only one line of code changed. If you would like to use LGProxy on a (fast) network without RDMA NICs, I recommend trying the software-based rdma_rxe module, since it works on most NICs and provides much better performance than is possible out of TCP and UDP.

@efschu
Copy link
Author

efschu commented Sep 29, 2023

I know everyone hates that question, so sorry for that, but did you made any progress? Maybe a test version around?

@beanfacts
Copy link
Member

There will be a new version soon. There is a test version on the tcm branch, but right now this version doesn't react to mouse input properly. When it's stable enough for testing, the changes will be pushed to the main branch. I don't have the hardware needed to do proper testing right now, so I can't really say when.

@efschu
Copy link
Author

efschu commented Jan 22, 2024

If you're missing RDMA capable NICs I could donate them to you. I have some unused ones lying around.

@beanfacts
Copy link
Member

If you're missing RDMA capable NICs I could donate them to you. I have some unused ones lying around.

Thanks for your offer! I am currently missing these, and the project would benefit greatly from your donation.

That being said, LGProxy is still a FOSS project with one maintainer (i.e., me) working on it in my spare time, alongside my studies and paid work. Therefore, I can't (and won't) make any promises. If the fact that a new version of LGProxy could arrive at an indeterminate point in the future is something that you would be fine with, and you still would like to send the network cards, I can provide you a Packstation address or similar. You can email me privately at [email protected] for more details.

In any case, I'll provide updates when the next version of LGProxy is stable enough for testing. If you have any feature suggestions, you can always put them here or in the "Discussions" tab. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants