Pith. sign in

REVIEW 3 major objections 4 minor 31 references

Ba-ZebraConf: A Three-Dimension Bayesian Framework for Efficient System Troubleshooting

T0 review · 3 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Ba-ZebraConf replaces binary-splitting group testing with a three-module Bayesian framework that cuts test count and execution time by 67% and drives false positives and false negatives to 0% on its 1,000-file evaluation.

desk verdict A plausible engineering integration of Bayesian group testing, optimization, and risk refinement for configuration debugging, but the headline 0% error rates are fitted, not predictive, because ground truth is undefined and hyperparameters are selected on the same 1,000 files. read the letter →

arxiv 2412.11073 v1 pith:IK4QPZC6 submitted 2024-12-15 eess.SY cs.SY

Deyi Xing , Weicong Chen , Curtis Tatsuoka , Xiaoyi Lu This is my paper · ORCID
classification eess.SYcs.SY
keywords Bayesiangrouptestingconfigurationtroubleshootingheterogeneousconfigurationsdistributedsystemsmisconfigurationdetectionoptimization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that configuration testing in distributed systems can be made faster and more trustworthy by replacing the binary-splitting group testing used in ZebraConf with a three-module Bayesian framework. The framework combines Bayesian Group Testing, which uses a probabilistic lattice model and the Bayesian Halving Algorithm to choose which configurations to test; Bayesian Optimization, which tunes pool sizes and thresholds; and Bayesian Risk Refinement, which accumulates evidence across tests to handle parameter interdependencies. On 1,000 unit test files, Ba-ZebraConf reports a 67% reduction in both number of tests and execution time compared with ZebraConf, with false positive and false negative rates falling to 0% by the later optimization iterations. If true, the approach would let operators find unsafe heterogeneous configurations with roughly one-third of the testing budget and with fewer classification errors.

What carries the argument

The load-bearing machinery is the three-dimensional Bayesian loop itself: a probabilistic lattice model over parameter subsets, updated by the Bayesian Halving Algorithm (a test-selection rule that splits the lattice into two nearly equal posterior-probability halves); a Gaussian-process Bayesian optimization module with Expected Improvement acquisition that tunes hyperparameters including pool sizes, priors, and classification thresholds; and Bayesian Risk Refinement, which applies Bayes' rule to accumulate per-parameter risk evidence across tests until thresholds $\tau_{\text{safe}}$ and $\tau_{\text{unsafe}}$ terminate testing. The lattice shrinking and risk-threshold termination are what convert accuracy gains into test-count savings.

What would settle it

Run Ba-ZebraConf at its converged iteration on a new, independently labeled set of configuration test files and count mismatches against the known labels; any false positive or false negative above 0%, or a test-count reduction below 67%, would refute the central claim.

Watch

Extended reading notes

Core claim

On its own terms, the central discovery is that three Bayesian ingredients—probabilistic group testing, automated hyperparameter optimization, and iterative risk refinement—can be composed into a single troubleshooting pipeline that outperforms the binary-splitting baseline. The claimed result is quantitative: across 1,000 unit test files, Ba-ZebraConf reduces executed tests from 107,962 to 35,426 and execution time from 472,503 to 153,417 seconds, a 67% reduction in both, while the false positive rate falls from 14% at the first evaluated iteration to 0% and false negatives fall from 4% to 0%. The mechanism credited for the improvement is probabilistic prioritization of high-risk configurations, cumulative risk evidence that captures parameter interdependencies, and dynamically tuned test thresholds.

Load-bearing premise

The reported 0% false-positive and false-negative rates assume that reliable ground-truth labels exist for the 1,000 unit test files, yet the paper does not state how those labels were obtained.

Editorial extensions

If this is right

  • At iteration $X = 179$, Ba-ZebraConf executes 35,426 tests instead of ZebraConf's 107,962 and finishes in 153,417 seconds instead of 472,503 seconds, a 67% reduction on both metrics.
  • False positives fall to 0% by $X = 179$, and false negatives reach 0% from $X = 13$ onward, showing that accuracy improves as Bayesian optimization refines the hyperparameters.
  • Because parameters are removed from the lattice once risk thresholds are crossed, the per-parameter testing cost shrinks as classifications become confident, which is the mechanism behind the count reduction.
  • Hyperparameter tuning shifts from exploration in the first 200 unit test files to exploitation with a background Bayesian Optimization Daemon, allowing later tests to run under the best-known settings.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the same three-module stack could be pointed at other pooled-diagnosis problems where interdependencies mask faults, such as network link fault localization or hardware component screening, because the machinery does not depend on file-based configuration semantics.
  • Editorial inference: the paper's fixed objective weights (0.4 for time savings, 0.4 for cost savings, minus error rates) invite a sensitivity check; different weights could shift where the optimization converges and how large the reported gains are.
  • Editorial inference: a deployment would need an explicit ground-truth labeling procedure, since without one the 0% error rates cannot be audited outside the original test set.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper presents Ba-ZebraConf, a framework that combines Bayesian Group Testing (BGT), Bayesian Optimization (BO), and Bayesian Risk Refinement (BRR) for identifying heterogeneous-unsafe configuration parameters in distributed systems. The authors claim that, compared with the ZebraConf baseline, Ba-ZebraConf reduces test execution time and test count by 67% while achieving 0% false positive and false negative rates, based on experiments over 1,000 unit test files at selected Bayesian optimization iterations.

Significance. If the reported results were valid, Ba-ZebraConf would be a useful contribution to configuration troubleshooting: the three-way integration of probabilistic group testing, cumulative risk refinement, and automated hyperparameter tuning is conceptually interesting and directly targets known limitations of binary-splitting group testing. The paper also gives some credit for explicitly addressing noise and dilution effects through likelihood tuning. However, the accuracy evidence presented is not currently trustworthy: the reported 0% error rates are obtained through an in-sample selection procedure, and no ground-truth definition is provided. The efficiency result (67% reduction in tests and time) is a concrete, potentially meaningful comparison, but it is also under-specified and not reproducible from the manuscript. The central claims therefore need substantial additional validation before the results can be accepted.

major comments (3)
  1. [§V-D, §VI-A, §VI-D] The 0% false positive and false negative rates reported in §VI-D are fitted quantities rather than predictive estimates. The BO objective in §V-D is 'Objective = 0.4·TSN + 0.4·CSN − FPR − FNR', and the same 1,000 unit test files used to report the final results are also used to tune hyperparameters during the Exploration and Exploitation phases (§V-D). Results are then reported at the best-performing BO iteration X=179, selected based on its improvements (§VI-A). This in-sample selection can drive FPR/FNR to zero by construction. A held-out evaluation (e.g., separate tuning/validation/test splits) with error bars is required to support the accuracy claim.
  2. [§VI-D, §V-F] False positive and false negative rates are only meaningful if there exists a ground-truth label of 'heterogeneous-unsafe' for every parameter in every one of the 1,000 unit test files. The paper never states how these labels are obtained; §V-F mentions simulated environments with known failure modes, but no connection is made between those simulations and the 1,000-file evaluation in §VI. Without a defined ground-truth protocol, the reported 0% FPR/FNR cannot be verified or interpreted.
  3. [§V-A, §VI] The implementation section contains an 'Algorithm ??' placeholder (§V-A), and no code, data, or configuration artifacts are provided. The evaluation also omits basic reproducibility information: what constitutes a 'unit test file', how many parameters are involved, the ranges of the six BO-tuned hyperparameters, and the random seeds. As a result, the 67% reduction in tests/time and the accuracy numbers cannot be independently reproduced or checked for fairness of comparison with ZebraConf.
minor comments (4)
  1. [§VI] The framework is called Ba-ZebraConf in the abstract, but §VI repeatedly refers to 'Bayesian-ZebraConf'; please unify the naming.
  2. [§VI-C] The abstract claims reduction of average test count, while §VI-C reports total executed test counts (35,426 vs 107,962); clarify whether the reported percentages refer to totals or per-file averages.
  3. [§VI-D] Figure 6 and Figure 7 captions and text report false positive and false negative rates as percentages, but the axes and units are not described; also the sentence 'with Rates of 4% at X=2and 0% for Subsequent Iterations' contains a formatting typo.
  4. [Table I] Table I lists 'Two Intel Xeon Silver 4114' and '10 cores per node', then states scale as 'Single-node (10 cores)'; clarify whether both sockets (20 cores total) or only one socket (10 cores) is used.

Circularity Check

2 steps flagged · score 6.0 of 10

The reported 0% FPR/FNR and 67% savings are in-sample values of the BO objective (Objective = 0.4·TSN + 0.4·CSN − FPR − FNR) optimized on the same 1,000 unit-test files, with iteration X=179 selected for its improvement, so the headline numbers are fitted rather than predicted.

  1. fitted input called prediction [Section V-D (Implementation of BO), custom objective and two-phase optimization; Section VI-D (False Positive and False Negative Rates)]
    "Custom Objective Function: Our tailored BO module optimizes hyperparameters using a weighted objective function: Objective = 0.4 · TSN + 0.4 · CSN − FPR − FNR, where TSN and CSN represent time and cost savings, and FPR and FNR are false positive and false negative rates. The weights balance efficiency and accuracy."

    FPR and FNR are not independent outcome variables; they are terms in the BO objective being optimized. BO selects hyperparameters on the same 1,000 unit-test files used for the reported evaluation (first 200 for the exploration-phase surrogate, and the BO Daemon probes remaining files in 10-file subsets during exploitation). Reporting the 0% false-positive and false-negative rates at iteration X = 179 is therefore reporting in-sample values of the fitted objective, not an out-of-sample prediction of classification accuracy.

  2. fitted input called prediction [Section VI-A (Experimental Setup) and Section VI-D (False Positive and False Negative Rates)]
    "The false positive rate decreases significantly, dropping to 0% by iteration X = 179. False negatives are reduced to 0% after the initial iteration."

    The evaluated iterations are selected for their performance: the paper states that iterations X = 2, 13, 96, 179 were 'chosen for their significant performance improvements,' and the headline result is the best of those selected points (X = 179). Because the BO objective already contains time savings, cost savings, and error rates, choosing the iteration with the largest improvements and 0% errors is equivalent to picking the best point on the same training criterion. The 67% reduction and 0% error rates are thus selected from the optimization trace, not predicted on unseen data.

full rationale

Ba-ZebraConf's algorithmic machinery is not itself circular: the cited SBGT/BGT papers are peer-reviewed background and no uniqueness theorem is invoked to force the design. The circularity is in the evaluation protocol. The BO custom objective directly contains the three headline metrics (TSN, CSN, FPR, FNR), and the same 1,000 unit-test files are used for hyperparameter optimization and for reported results, with evaluated iterations chosen for their 'significant performance improvements.' The headline 0% FPR/FNR and 67% savings at X = 179 are therefore fitted objective values, not held-out predictions. The paper also never defines how ground-truth labels for heterogeneous-unsafe parameters are obtained, making the FPR/FNR computation unverifiable; that is a validity problem rather than a circularity. The 'Algorithm ??' placeholder and absence of code/data further prevent independent reproduction. Because the result is an actual measured run rather than a definitional identity, the circularity is partial, so a score of 6 is appropriate rather than 8-10.

Assumptions & free parameters 7 free parameters · 5 assumptions · 0 invented entities

The framework relies on a set of hyperparameters tuned by Bayesian optimization on the evaluation dataset, and on domain assumptions about test noise and ground truth. No new entities are introduced.

free parameters (7)
  • Pool sizes = not reported
    Tuned via BO in Section IV-D to balance efficiency and accuracy.
  • Prior probabilities per parameter = not reported
    Initialized by domain knowledge (Section V-B), then updated; these influence all posterior updates.
  • Classification thresholds tau_safe and tau_unsafe = not reported
    Tuned via BO (Section IV-D); used in BRR to stop testing.
  • Likelihood parameters alpha and beta = not reported
    Tuned via BO to model noise and dilution (Section IV-D).
  • BO objective weights = 0.4, 0.4
    Chosen by hand in Section V-D; directly shape the trade-off that produces the reported error rates.
  • BO iteration index X = 179
    The reported 67% and 0% results are at X=179, an iteration selected for its performance (Section VI-A).
  • Exploration phase size and refinement subset size = 200, 10
    Chosen by hand in Section IV-D; affect tuning and reported results.
assumptions (5)
  • standard math Bayes' theorem and lattice-based posterior updates from SBGT [21] are valid for configuration testing.
    Invoked in Section IV-B; the lattice model and BHA are taken from the authors' prior work rather than re-derived.
  • domain assumption Unit test outcomes can be represented as an OR of parameter states with noise captured by likelihood parameters alpha and beta.
    Section IV-C introduces P(positive | Ri) = alpha * Ri and P(negative | Ri) = 1 - beta * Ri; this functional form is assumed.
  • domain assumption The hyperparameters tuned by BO on the first 200 test files and refined on 10-file subsets are appropriate for the full 1,000 files.
    Section IV-D describes the two-phase tuning; the final accuracy is reported on the same files, which assumes generalization from tuning subsets.
  • domain assumption Ground-truth labels for heterogeneous-unsafe parameters are available for the 1,000 test files.
    Section VI-D reports false positive/negative rates without stating how the true status is defined; this is unstated and load-bearing.
  • ad hoc to paper The BO objective weights (0.4 for time savings, 0.4 for cost savings, -1 for FPR and FNR) are a valid characterization of system troubleshooting goals.
    Section V-D defines the objective; the weights are chosen by the authors without justification.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Ba-ZebraConf: A Three-Dimension Bayesian Framework for Efficient System Troubleshooting." pith.science (2026). https://pith.science/paper/IK4QPZC6

@misc{pith2026241211073,
  author       = {Pith},
  title        = {Pith review of: Ba-ZebraConf: A Three-Dimension Bayesian Framework for Efficient System Troubleshooting},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IK4QPZC6}},
  note         = {Machine review of arXiv:2412.11073}
}
read the original abstract

The proliferation of heterogeneous configurations in distributed systems presents significant challenges in ensuring stability and efficiency. Misconfigurations, driven by complex parameter interdependencies, can lead to critical failures. Group Testing (GT) has been leveraged to expedite troubleshooting by reducing the number of tests, as demonstrated by methods like ZebraConf. However, ZebraConf's binary-splitting strategy suffers from sequential testing, limited handling of parameter interdependencies, and susceptibility to errors such as noise and dilution. We propose Ba-ZebraConf, a novel three-dimensional Bayesian framework that addresses these limitations. It integrates (1) Bayesian Group Testing (BGT), which employs probabilistic lattice models and the Bayesian Halving Algorithm (BHA) to dynamically refine testing strategies, prioritizing high-informative parameters and adapting to real-time outcomes. Bayesian optimization tunes hyperparameters, such as pool sizes and test thresholds, to maximize testing efficiency. (2) Bayesian Optimization (BO) to automate hyperparameter tuning for test efficiency, and (3) Bayesian Risk Refinement (BRR) to iteratively capture parameter interdependencies and improve classification accuracy. Ba-ZebraConf adapts to noisy environments, captures parameter interdependencies, and scales effectively for large configuration spaces. Experimental results show that Ba-ZebraConf reduces test counts and execution time by 67% compared to ZebraConf while achieving 0% false positives and false negatives. These results establish Ba-ZebraConf as a robust and scalable solution for troubleshooting heterogeneous distributed systems.

Figures

Figures reproduced from arXiv: 2412.11073 by the authors.

Figure 1
Figure 1. Overview of Ba-ZebraConf. The framework incor [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Comparison of Execution Time Between Bayesian [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Percentage of Execution Time Saved by Bayesian [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6: False Positive Rates of Bayesian ZebraConf Across [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: False Negative Rates of Bayesian ZebraConf Across [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 28 canonical work pages

  1. [1]

    Improving perfor- mance of heterogeneous mapreduce clusters with adaptive task tuning,

    D. Cheng, J. Rao, Y . Guo, C. Jiang, and X. Zhou, “Improving perfor- mance of heterogeneous mapreduce clusters with adaptive task tuning,” IEEE Transactions on Parallel and Distributed Systems , vol. 28, no. 3, pp. 774–786, 2016

    work page 2016

  2. [2]

    Aroma: Automated resource allocation and configuration of mapreduce environment in the cloud,

    P. Lama and X. Zhou, “Aroma: Automated resource allocation and configuration of mapreduce environment in the cloud,” in Proceedings of the 9th International Conference on Autonomic Computing (ICAC’12) , San Jose, California, USA, Sep. 2012, pp. 63–72

    work page 2012

  3. [3]

    An End-to-End Automatic Cloud Database Tuning System Using Deep Reinforcement Learning,

    J. Zhang, Y . Liu, K. Zhou, G. Li, Z. Xiao, B. Cheng, J. Xing, Y . Wang, T. Cheng, L. Liu, M. Ran, and Z. Li, “An End-to-End Automatic Cloud Database Tuning System Using Deep Reinforcement Learning,” in Proceedings of the 2019 International Conference on Management of Data (SIGMOD’19), June 2019

    work page 2019

  4. [4]

    HDFS-2202: Changes to Balancer Band- width Should Not Require Datanode Restart,

    Apache Software Foundation, “HDFS-2202: Changes to Balancer Band- width Should Not Require Datanode Restart,” https://issues.apache.org/ jira/browse/HDFS-2202, 2011

    work page 2011

  5. [5]

    OPTIMUSCLOUD: Heterogeneous Config- uration Optimization for Distributed Databases in the Cloud,

    A. Mahgoub, A. M. Medoff, R. Kumar, S. Mitra, A. Klimovic, S. Chaterji, and S. Bagchi, “OPTIMUSCLOUD: Heterogeneous Config- uration Optimization for Distributed Databases in the Cloud,” in 2020 USENIX Annual Technical Conference (USENIX ATC’20) , July 2020

    work page 2020

  6. [6]

    Finding heterogeneous- unsafe configuration parameters in cloud systems,

    S. Ma, F. Zhou, M. D. Bond, and Y . Wang, “Finding heterogeneous- unsafe configuration parameters in cloud systems,” in Proceedings of the Sixteenth European Conference on Computer Systems (EuroSys) . ACM, 2021, pp. 410–421. [Online]. Available: https://doi.org/10.1145/ 3447786.3456250

    work page arXiv 2021

  7. [7]

    Apache Hadoop Goes Realtime at Facebook,

    D. Borthakur, J. Gray, J. S. Sarma, K. Muthukkaruppan, N. Spiegelberg, H. Kuang, K. Ranganathan, D. Molkov, A. Menon, S. Rash et al. , “Apache Hadoop Goes Realtime at Facebook,” in Proceedings of the 2011 ACM SIGMOD International Conference on Management of Data (SIGMOD’11), June 2011, pp. 1071–1080

    work page 2011

  8. [8]

    Rolling restart,

    C. Documentation, “Rolling restart,” last accessed on January 24, 2024

    work page 2024

Show all 31 references
  1. [9]

    SOPHIA: Online Reconfiguration of Clustered NoSQL Databases for Time-Varying Workloads,

    A. Mahgoub, P. Wood, A. Medoff, S. Mitra, F. Meyer, S. Chaterji, and S. Bagchi, “SOPHIA: Online Reconfiguration of Clustered NoSQL Databases for Time-Varying Workloads,” in 2019 USENIX Annual Technical Conference (USENIX ATC’19), July 2019, pp. 223–236

    2019

  2. [10]

    Performing a Rolling Restart of an NDB Cluster,

    MySQL 8.0 Reference Manual, “Performing a Rolling Restart of an NDB Cluster,” https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster- rolling-restart.html, accessed: 2023-12-30

    2023

  3. [11]

    MAPREDUCE-442: Ability to Re- configure Hadoop Daemons Online,

    Apache Software Foundation, “MAPREDUCE-442: Ability to Re- configure Hadoop Daemons Online,” https://issues.apache.org/jira/ browse/MAPREDUCE-442

  4. [12]

    HBase-8544: Add a Utility to Reload Configurations in Region Server,

    ——, “HBase-8544: Add a Utility to Reload Configurations in Region Server,” https://issues.apache.org/jira/browse/HBASE-8544, accessed: 2024-2-02

    2024

  5. [13]

    HDFS-1477: Support Reconfiguring ’dfs.heartbeat.interval’ and ’dfs.namenode.heartbeat.recheck-interval’ without NN Restart,

    ——, “HDFS-1477: Support Reconfiguring ’dfs.heartbeat.interval’ and ’dfs.namenode.heartbeat.recheck-interval’ without NN Restart,” https:// issues.apache.org/jira/browse/HDFS-1477, accessed: 2024-2-02

    2024

  6. [14]

    MRONLINE: MapReduce Online Performance Tuning,

    M. Li, L. Zeng, S. Meng, J. Tan, L. Zhang, A. R. Butt, and N. Fuller, “MRONLINE: MapReduce Online Performance Tuning,” inProceedings of the 23rd International Symposium on High-Performance Parallel and Distributed Computing (HPDC’14) , 2014, pp. 165–176

    2014

  7. [15]

    Understanding and Auto-Adjusting Performance-Sensitive Configura- tions,

    S. Wang, C. Li, H. Hoffmann, S. Lu, W. Sentosa, and A. I. Kistijantoro, “Understanding and Auto-Adjusting Performance-Sensitive Configura- tions,” in Proceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Syste...

    2018

  8. [16]

    Automating Configuration Troubleshooting with Dynamic Information Flow Analysis,

    M. Attariyan and J. Flinn, “Automating Configuration Troubleshooting with Dynamic Information Flow Analysis,” in Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI’10), October 2010

    2010

  9. [17]

    Pooling of Samples for Test- ing for SARS-CoV-2 in Asymptomatic People,

    S. Lohse, T. Pfuhl, B. Berko-G ¨ottel, J. Rissland, T. Geißler, B. G ¨artner, S. L. Becker, S. Schneitler, and S. Smola, “Pooling of Samples for Test- ing for SARS-CoV-2 in Asymptomatic People,” The Lancet Infectious Diseases, vol. 20, no. 11, pp. 1231–1232, 2020

    2020

  10. [18]

    Optimising SARS-CoV-2 Pooled Testing for Low-resource Settings,

    F. Majid, S. B. Omer, and A. I. Khwaja, “Optimising SARS-CoV-2 Pooled Testing for Low-resource Settings,” The Lancet Microbe, vol. 1, no. 3, pp. e101–e102, 2020

    2020

  11. [19]

    Sample Pooling as a Strategy to Detect Community Transmission of SARS-CoV-2,

    C. A. Hogan, M. K. Sahoo, and B. A. Pinsky, “Sample Pooling as a Strategy to Detect Community Transmission of SARS-CoV-2,” JAMA, vol. 323, no. 19, p. 1967, 2020. 11

    1967

  12. [20]

    The Mathematics of Mass Testing for COVID-19,

    D. Donoho, M. Lofti, and B. Ozturkler, “The Mathematics of Mass Testing for COVID-19,” [Online]. Available: https://sinews.siam.org/ Details-Page/the-mathematics-of-mass-testing-for-covid-19, 2020

    2020

  13. [21]

    Sbgt: Scaling bayesian- based group testing for disease surveillance,

    W. Chen, H. Qi, X. Lu, and C. Tatsuoka, “Sbgt: Scaling bayesian- based group testing for disease surveillance,” in 2023 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE, 2023, pp. 951–962

    2023

  14. [22]

    Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems,

    Q. Chen, T. Wang, O. Legunsen, S. Li, and T. Xu, “Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems,” in Proceedings of the 2020 ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engi...

    2020

  15. [23]

    A tutorial on bayesian optimization,

    P. I. Frazier, “A tutorial on bayesian optimization,” arXiv preprint arXiv:1807.02811, 2018. [Online]. Available: https://arxiv.org/abs/1807. 02811

    2018 arXiv

  16. [24]

    Bayesian Group Testing with Dilu- tion Effects,

    C. Tatsuoka, W. Chen, and X. Lu, “Bayesian Group Testing with Dilu- tion Effects,” Biostatistics, p. kxac004, April 2022, [Online]. Available: https://doi.org/10.1093/biostatistics/kxac004

    2022 doi

  17. [25]

    Sequential Classification on Partially Or- dered Sets,

    C. Tatsuoka and T. Ferguson, “Sequential Classification on Partially Or- dered Sets,” Journal of the Royal Statistical Society: Series B (Statistical Methodology), vol. 65, no. 1, pp. 143–157, 2003

    2003

  18. [26]

    Practical bayesian optimiza- tion of machine learning algorithms,

    J. Snoek, H. Larochelle, and R. P. Adams, “Practical bayesian optimiza- tion of machine learning algorithms,” in Advances in Neural Information Processing Systems, F. Pereira, C. Burges, L. Bottou, and K. Weinberger, Eds., vol. 25. Curran Associates, Inc., 2012

    2012

  19. [27]

    A survey on high-dimensional gaussian process modeling with application to bayesian optimization,

    M. Binois and N. Wycoff, “A survey on high-dimensional gaussian process modeling with application to bayesian optimization,” vol. 2, no. 2, Aug. 2022. [Online]. Available: https://doi.org/10.1145/3545611

    2022 doi

  20. [28]

    Explo- ration Enhanced Expected Improvement for Bayesian Optimization,

    J. Berk, V . Nguyen, S. Gupta, S. Rana, and S. Venkatesh, “Explo- ration Enhanced Expected Improvement for Bayesian Optimization,” in Machine Learning and Knowledge Discovery in Databases. ECML PKDD 2018 , ser. Lecture Notes in Computer Science, M. Berlingerio, F. Bonchi, T. G...

    2018

  21. [29]

    Recent advances in bayesian optimization,

    X. Wang, Y . Jin, S. Schmitt, and M. Olhofer, “Recent advances in bayesian optimization,” ACM Comput. Surv. , vol. 55, no. 13s, Jul

  22. [30]

    CloudLab,

    CloudLab, “CloudLab,” https://www.cloudlab.us, accessed: 2024-12-14. 12

    2024

  23. [2023]

    Available: https://doi.org/10.1145/3582078

    [Online]. Available: https://doi.org/10.1145/3582078

    doi

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.