| Age | Commit message (Collapse) | Author |
|---|
|
Currently we have byte rate only.
|
|
We should normalize the packets as well...
|
|
Convert to per second first, divide for kilo after.
|
|
Show a non highlighted string at the start of htop, not the failure
text.
Also the original fix only handled the text mode, not the bar mode.
Improves: 2977414d ("Discard stale information from DiskIO and NetworkIO meters")
Related: #860
|
|
This ensures the initial read of the data is not misinterpreted as arbitrarily large values.
Also this forces the maximum update interval between two subsequent reads to within 30s.
Fixes #860
|
|
|
|
`RichString_appendnAscii()` avoids a `strlen(3)` call over
` RichString_appendAscii()`.
Use the former where the length is available from a previous checked
`snprintf(3)` call.
Keep `RichString_appendAscii()` when passing a string literal and
rely on compilers to optimize the `strlen(3)` call away.
|
|
Refactor the sample time code to make one call to gettimeofday
(aka the realtime clock in clock_gettime, when available) and
one to the monotonic clock. Stores each in more appropriately
named ProcessList fields for ready access when needed. Every
platform gets the opportunity to provide their own clock code,
and the existing Mac OS X specific code is moved below darwin
instead of in Compat.
A couple of leftover time(2) calls are converted to use these
ProcessList fields as well, instead of yet again sampling the
system clock.
Related to https://github.com/htop-dev/htop/pull/574
|
|
The end goal is to consolidate all the points in htop that can only work in
live-only mode today, so that will be able to inject PCP archive mode and have
a chance at it working.
The biggest problem we've got at this moment is all the places that are
independently asking the kernel to 'give me the time right now'.
Each of those needs to be audited and ultimately changed to allow platforms to
manage their own idea of time.
So, all the calls to gettimeofday(2) and time(2) are potential problems.
Ultimately I want to get these down to just one or two.
Related to https://github.com/htop-dev/htop/pull/574
|
|
|
|
From review via @BenBE, this is now a whole lot cleaner.
|
|
On Linux kernels the size of the values exported for network
device bytes and packets has used a 64 bit integer for quite
some time (2.6+ IIRC). Make the procfs value extraction use
correct types and change internal types used to rate convert
these counters (within the NetworkIO Meter) 64 bit integers,
where appropriate.
|
|
|
|
RichString_writeFrom takes a top spot during performance analysis due to the
calls to mbstowcs() and iswprint().
Most of the time we know in advance that we are only going to print regular
ASCII characters.
|
|
Most of the time the parameter is passed to snprintf type functions
|
|
|
|
|
|
If the current data is smaller than the previous one, either by a retrieve error
or a device removal or a original data wraparound, sanitize the value to zero.
Fixes: #299
|
|
|
|
In case the packet values wrap-around or have other weird values, the
current buffer might be to small
|
|
Information as seen by IWYU 0.12 + clang 9 on Linux
|
|
|
