| commit | b3ef7f2b4419d818427612584c579e7534ceb460 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Wed Mar 30 14:03:41 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Tue Apr 26 18:01:24 2022 +0000 |
| tree | a26c86dd3c2865169772b3af31a17813a8467333 | |
| parent | c49e2c5cabe5401de5931fe470096800e0aa1bf9 [diff] |
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
The goal of this repository is to collect the two-minute hacks you write to automate interactions with OpenBMC systems.
It's highly likely the scripts don't meet your needs - they could be undocumented, dysfunctional or utterly broken. Please help us improve!
Then this repository aims to be the default destination for your otherwise un-homed scripts. As such we are setting the bar for submission pretty low, and we aim to make the process as easy as possible.
Please use gerrit for all patches to this repository:
Do note that you will need to be party to the OpenBMC CLA before your contributions can be accepted. See Gerrit Setup and CLA for more information.
So long as your patches look sane with a cursory glance you can expect them to be applied. We may push back in the event that similar tools already exist or there are egregious issues.
We don't ask for much, but you need to give us at least a Signed-off-by, use SPDX markers in your source files and put your work under an Apache 2.0 compatible license.
There's no standard way to install the scripts housed here, and adding parts of the repository to your PATH might be a bit of a dice-roll. We may also move or remove scripts from time to time as part of housekeeping. It's probably best to copy things out if you need stability.