/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
|