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

Add simple compile-time txpower control and boost/neg-boost. [...] #12

Merged
merged 7 commits into from
Jun 18, 2020
Merged

Add simple compile-time txpower control and boost/neg-boost. [...] #12

merged 7 commits into from
Jun 18, 2020

Conversation

yavincl
Copy link
Contributor

@yavincl yavincl commented Jun 18, 2020

Making this go all the way to iw or iwconfig is way outsidet of my capabilities but if you want to give it a try, go ahead. Right now this is enough for my needs.

All the changes here have been throughly tested.

Added LD optimizations.
Added DKMS to use threaded compile
Add simple compile-time txpower control and boost/neg-boost and reference to it in readme.
Fixed readme typos on HT-capabs and other improvements

with underflow protection. Making this go all the way to iw or iwconfig is way outsidet of my capabilities but if you want to give it a try, go ahead. Right now this is enough for my needs.
Fix a typo in HT capab DSSS_CCK-40   
Add HT disclaimer from my findings  
Add info about manual compile-time txpower control  
Replace some stuff with tee commands  
Remove options line for 8192ee, they didn't really do anything good.
@lwfinger
Copy link
Owner

I do not like hard-coding the "-j" part to make. It is fine when the driver builds; however, it is a PITA when there are warnings or errors as they scroll off the screen. In addition, the recommended value is not nproc, but 2*nproc+1. That will keep all processors busy as long as you have sufficient memory. IF you get into swapping, then using multiple jobs will slow the build.

@yavincl
Copy link
Contributor Author

yavincl commented Jun 18, 2020

Odd. Con Kolivas recommends using -j$(nproc) and not any higher. But that may be restricted to what he sees in his CPU scheduler.

I can change it, but do note that people using DKMS are usually not debugging the driver, rather, they are updating their kernel. It is important that this process is not too slow, at least how I see it. If you need to have nice warnings. just run make all on the source folder instead.

@lwfinger lwfinger merged commit d9a70eb into lwfinger:master Jun 18, 2020
@lwfinger
Copy link
Owner

I build many, many kernels. My main laptop has 4 processors. Using 'make -j4' does not keep all CPUs busy for these 20 minute builds. I tested various numbers and -j9 used the least elapsed time. On a 2 minute build, it does not make much difference

@yavincl yavincl deleted the patch-1 branch June 18, 2020 20:05
@yavincl
Copy link
Contributor Author

yavincl commented Jun 18, 2020

My i3 also has four cores. Here are my results:
-j4 -> real 0m39,729s
-j9 -> real 0m38,470s
no -j -> real 1m22,159s

Obviously 2*nproc+1 will usually lead to a performance increase because more stuff will be loaded in memory. It is not ideal if you want to do stuff in the foreground, as it may starve other processes of memory and CPU time. Really depends on your workflow.

It's really whatever in this driver's case, -j nproc fits the role well in dkms, but only very impatient people will really notice anything.

I don't think a rule for thread amount actually exists.

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

Successfully merging this pull request may close these issues.

None yet

2 participants