htop-dev
Implement Network & Disk IO support on MacOS
Hello the sudo htop running in my MacMini, macOS Catalina cannot be setup to display Network & Disk IO as the one running in my raspberry Linux can. How do I enable it?
For MacOS, the necessary functions to determine the disk and network I/O are not implement.
Thus in order to activate these meters, a working implementation for Platform_getDiskIO and Platform_getNetworkIO in darwin/Platform.c is required.
I see... Should I close this?
Is it still possible installing any (maybe 3rd party) SW? or... is it something that could be suggested as improvement?
We can just update this ticket as a feature request to implement these missing functions, although I doubt there will be any work from inside the core team as noone here really works on darwin …
I'll try to implement Platform_getDiskIO for Darwin. This may take some time, since I'm kind of busy recently.
That sounds great, please keep me posted. On Sunday, 16 April 2023, 04:45:16 AM GMT-6, UeiWang @.***> wrote:
I'm interested in implementing Platform_getDiskIO for Darwin. This may take some time, since I'm kind of busy recently.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
@pbrena you can now test the Disk IO Meter for Darwin by building the latest commit of #1228 (if your local repository is already configured, run ./autogen.sh and ./configure before building). Please pay special attention to if "Disk IO" in the Disk IO Meter may exceed 100% even when no external drive is connected to your machine.
i will, thx On Tuesday, 18 April 2023, 08:10:14 AM GMT-6, UeiWang @.***> wrote:
@pbrena you can now test the Disk IO Meter for Darwin by building the latest commit of #1228 (if your local repository is already configured, run ./autogen.sh and ./configure before building). Please pay special attention to if "Disk IO" in the Disk IO Meter may exceed 100% even when no external drive is connected to your machine.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
geat, thx On Saturday, 22 April 2023, 11:33:10 PM GMT-6, UeiWang @.***> wrote:
I'll also work on the Network IO Meter for Darwin :)
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Hello Uei, Here I attach some screenshots of Htop dev and macos disk activity monitor, to show htop indeed often reports above 100% (even 2000%, that looks strange)... My particular HW is odd, I guess... its a Monterey running in macmini 2011 (with Opencore patch) with a Fusion drive = (SATA SDD plus a Sata HDD) for Systems drive and a USB HDD for User Data. Thx Pablo
On Tuesday, 18 April 2023, 08:10:14 AM GMT-6, UeiWang ***@***.***> wrote:
@pbrena you can now test the Disk IO Meter for Darwin by building the latest commit of #1228 (if your local repository is already configured, run ./autogen.sh and ./configure before building). Please pay special attention to if "Disk IO" in the Disk IO Meter may exceed 100% even when no external drive is connected to your machine.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
@pbrena Unfortunately there are no screenshots visible in your comment. Also the borked filtering of email-to-GH comment makes your notes hard to read. Please prefer to use the web UI (or the app) as comments done that way don't end up with loads of gibberish between the signal …
sorry, about it...
unfortunatelly, i found no way to attach images...
Hello Uei,
Here I attach some screenshots of Htop dev and macos disk activity monitor, to show htop indeed often reports above 100% (even 2000%, that looks strange)... My particular HW is odd, I guess... its a Monterey running in macmini 2011 (with Opencore patch) with a Fusion drive = (SATA SDD plus a Sata HDD) for Systems drive and a USB HDD for User Data.
Thx Pablo
Hello Uei, Here I attach some screenshots of Htop dev and macos disk activity monitor, to show htop indeed often reports above 100% (even 2000%, that looks strange)... My particular HW is odd, I guess... its a Monterey running in macmini 2011 (with Opencore patch) with a Fusion drive = (SATA SDD plus a Sata HDD) for Systems drive and a USB HDD for User Data.
@pbrena Hello Pablo, I can reproduce the problem on my MacBook Pro 2019 running macOS Ventura 13.3.1 (see #1228). I'll try to debug this.
I used fprintf to print the values of relevant variables (for the source code see branch debug of UeiWang/htop, for sample debug outputs which reproduce the bug see diskio.log), and found out that the problem may be that during an interval, the increase in the total read/write time of a disk obtained by I/O Kit may be much (sometimes more than 10x) larger than the length of the interval obtained by clock_gettime....
Replacing clock_gettime with clock_gettime_nsec_np (a non-portable Darwin alternative to clock_gettime) doesn't fix the problem, and the affected disks include the built-in SSD of my laptop and my portable SSD (in diskio.log mentioned above, there are consecutive lines starting with "read time: ", "write time: ", "read time: ", "write time: ", "read time: ", and "write time: ". The first two lines correspond to the built-in SSD, and lines 3-4 to my portable SSD.).
Looking at the values in your diskio.log it seems as if you have a value type confusion in your calculation. The values are given in nanoseconds, but scaled by your code to be in milliseconds (so far so good). The output to the user then tries to convert that difference of milliseconds to a percentage value. Instead you would need to calculate the difference between the old (cached total time) value to the new (queried total time) one in relation to the old timestamp vs. the current one (scaled by 100 to get %). Further scaling has to be done to account for the number of disks in the system (e.g. for 2 disks divide by 2 accordingly).
Thank you for you help!
The output to the user then tries to convert that difference of milliseconds to a percentage value. Instead you would need to calculate the difference between the old (cached total time) value to the new (queried total time) one in relation to the old timestamp vs. the current one (scaled by 100 to get %).
But I think DiskIOMeter_updateValues in DiskIOMeter.c is correct in calculating "Disk IO" by the formula 100 * (queried disk time - cached disk time) / (new timestamp - old timestamp).
Further scaling has to be done to account for the number of disks in the system (e.g. for 2 disks divide by 2 accordingly).
But htop doesn't do such scaling on Linux, and I think it's important to be consistent on different platforms.
IMHO the problem may lie in the disk read/write time returned by I/O Kit, since the intervals between the timestamps (passedTimeInMs in diskio.log in my previous comment) are stable, it's not likely that system timestamps can be wrong, and it's the disk read/write time that sometimes becomes abnormally large. Maybe some bugs in the disk drivers?
Hello Uei, I just issued a git pull but failed to find the Netmeter +++++++++++++++++ On branch main Your branch is up to date with 'origin/main’. ++++++++++++++++
reading the link above... IIUC, it was added to the tag 3.3.0 but the last tag I find is 3.2. x, Am I missing something?
Hello Uei, I just issued a git pull but failed to find the Netmeter +++++++++++++++++ On branch main Your branch is up to date with 'origin/main’. ++++++++++++++++
Note, that the new feature is not yet merged in this repository of htop and thus you need to import those changes from cloning https://github.com/UeiWang/htop (branch main) instead. Also new meters aren't added automatically, thus you need to add this new meter via the setup screen manually.
You can check you've got the right repository by running git remote -v show, which will list all the sources git is importing commits from.
reading the link above... IIUC, it was added to the tag 3.3.0 but the last tag I find is 3.2. x, Am I missing something?
3.3.0 is the version where this is planned to be added; once the PR passed review and any remaining issues have been cleared. As you can see in the progress bar below the "Milestone", this overall release is still WIP.
Im so sorry Uei,
All my fault, my confusion started by my complete forgeting of how I managed to add the diskIO in the 1rst place this time I hadnt even compiled the source and expected the change to magically pop up in the setup menu (embarrassing and scary).
I can confirm that the NetIO is up and running, lovely!, nevertheless DiskIO dont go to beyond the 1000s/100 as before, but still can peak in the 100s now as seen in the image .
Thanks so much