| /openbmc/openbmc-tools/dbus_sensor_tester/ |
| H A D | dbus_sensor_tester.bb | b3ef7f2b Wed Mar 30 16:03:41 CDT 2022 Ed Tanous <edtanous@google.com> Implement a performance testing tool for sensors
There are a lot of hypothesis being made about how to improve the
performance of the sensor subsystem within OpenBMC. There are a number
of statements being made about dbus performance that actually seem
likely to be related to the efficiency of specific implementations of
certain sensors within OpenBMC. Blocking calls, non blocking calls,
asio, bulk collection, eventing, threads and other design decisions all
can have an effect on the performance of a sensor application.
This commit attempts to write a small, portable daemon that publishes
sensor interfaces read from memory in a relatively simple and
controllable manner. This allows running it on a bmc (with services
unloaded) to determine some theoretical "max" performance
characteristics, assuming 0 cost for grabbing actual values.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I27f1560ba13492ccff6a01013c3a1d5ee210cef0
|
| H A D | main.cpp | b3ef7f2b Wed Mar 30 16:03:41 CDT 2022 Ed Tanous <edtanous@google.com> Implement a performance testing tool for sensors
There are a lot of hypothesis being made about how to improve the
performance of the sensor subsystem within OpenBMC. There are a number
of statements being made about dbus performance that actually seem
likely to be related to the efficiency of specific implementations of
certain sensors within OpenBMC. Blocking calls, non blocking calls,
asio, bulk collection, eventing, threads and other design decisions all
can have an effect on the performance of a sensor application.
This commit attempts to write a small, portable daemon that publishes
sensor interfaces read from memory in a relatively simple and
controllable manner. This allows running it on a bmc (with services
unloaded) to determine some theoretical "max" performance
characteristics, assuming 0 cost for grabbing actual values.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I27f1560ba13492ccff6a01013c3a1d5ee210cef0
|
| H A D | meson.build | b3ef7f2b Wed Mar 30 16:03:41 CDT 2022 Ed Tanous <edtanous@google.com> Implement a performance testing tool for sensors
There are a lot of hypothesis being made about how to improve the
performance of the sensor subsystem within OpenBMC. There are a number
of statements being made about dbus performance that actually seem
likely to be related to the efficiency of specific implementations of
certain sensors within OpenBMC. Blocking calls, non blocking calls,
asio, bulk collection, eventing, threads and other design decisions all
can have an effect on the performance of a sensor application.
This commit attempts to write a small, portable daemon that publishes
sensor interfaces read from memory in a relatively simple and
controllable manner. This allows running it on a bmc (with services
unloaded) to determine some theoretical "max" performance
characteristics, assuming 0 cost for grabbing actual values.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I27f1560ba13492ccff6a01013c3a1d5ee210cef0
|
| /openbmc/openbmc-tools/dbus_sensor_tester/subprojects/ |
| H A D | cli11.wrap | b3ef7f2b Wed Mar 30 16:03:41 CDT 2022 Ed Tanous <edtanous@google.com> Implement a performance testing tool for sensors
There are a lot of hypothesis being made about how to improve the
performance of the sensor subsystem within OpenBMC. There are a number
of statements being made about dbus performance that actually seem
likely to be related to the efficiency of specific implementations of
certain sensors within OpenBMC. Blocking calls, non blocking calls,
asio, bulk collection, eventing, threads and other design decisions all
can have an effect on the performance of a sensor application.
This commit attempts to write a small, portable daemon that publishes
sensor interfaces read from memory in a relatively simple and
controllable manner. This allows running it on a bmc (with services
unloaded) to determine some theoretical "max" performance
characteristics, assuming 0 cost for grabbing actual values.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I27f1560ba13492ccff6a01013c3a1d5ee210cef0
|
| H A D | boost.wrap | b3ef7f2b Wed Mar 30 16:03:41 CDT 2022 Ed Tanous <edtanous@google.com> Implement a performance testing tool for sensors
There are a lot of hypothesis being made about how to improve the
performance of the sensor subsystem within OpenBMC. There are a number
of statements being made about dbus performance that actually seem
likely to be related to the efficiency of specific implementations of
certain sensors within OpenBMC. Blocking calls, non blocking calls,
asio, bulk collection, eventing, threads and other design decisions all
can have an effect on the performance of a sensor application.
This commit attempts to write a small, portable daemon that publishes
sensor interfaces read from memory in a relatively simple and
controllable manner. This allows running it on a bmc (with services
unloaded) to determine some theoretical "max" performance
characteristics, assuming 0 cost for grabbing actual values.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I27f1560ba13492ccff6a01013c3a1d5ee210cef0
|
| H A D | sdbusplus.wrap | b3ef7f2b Wed Mar 30 16:03:41 CDT 2022 Ed Tanous <edtanous@google.com> Implement a performance testing tool for sensors
There are a lot of hypothesis being made about how to improve the
performance of the sensor subsystem within OpenBMC. There are a number
of statements being made about dbus performance that actually seem
likely to be related to the efficiency of specific implementations of
certain sensors within OpenBMC. Blocking calls, non blocking calls,
asio, bulk collection, eventing, threads and other design decisions all
can have an effect on the performance of a sensor application.
This commit attempts to write a small, portable daemon that publishes
sensor interfaces read from memory in a relatively simple and
controllable manner. This allows running it on a bmc (with services
unloaded) to determine some theoretical "max" performance
characteristics, assuming 0 cost for grabbing actual values.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I27f1560ba13492ccff6a01013c3a1d5ee210cef0
|