Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
32
datasets available to search
ShareScore release 0.9.0
Dataset results
32 results for “performance benchmarking”
Benchmarking on Microservices Configurations and the Impact on the Performance in Cloud Native Environments
<p><strong>The peer reviewed publication for this dataset has been published in LCN 2022, 47th Annual IEEE Conference on Local Computer Networks. Please cite this paper when referring to the dataset: https://www.eurecom.fr/publication/6971.</strong></p> <p>Cloud-native and containerization have changed the way to develop and deploy applications. Cloud-native rethinks the application architecture by embracing a microservice approach, where each microservice is packaged into containers to run in a centralized or an edge cloud. When deploying the container running the micro-service, the tenant has to specify the needed computing resources to run their workload in terms of the amount of CPU and memory limit. However, it is not straightforward for a tenant to know in advance the computing amount that allows running the microservice optimally. This will have an impact not only on the service performances but also on the infrastructure provider, particularly if the resource overprovisioning approach is used. To overcome this issue, we conduct an experimental study aiming to detect if a tenant's configuration allows running its service optimally. We run several experiments on a cloud-native platform, using different types of applications under different resource configurations. The obtained results are presented in the accepted IEEE LCN paper (https://www.eurecom.fr/publication/6971) and are shared in this dataset.</p> <p>The datasets are collected for 3 types of applications: Web servers written in python and Golang, RabbitMQ data broker and the OpenAirInterface 5G Core network function AMF (Access and Mobility Management Function).</p> <p><br> </p> <p><strong>Web Servers:</strong></p> <p><strong>files: </strong>golang-web-server-performance.csv, python-web-server-performance.csv</p> <p>We used Golang and Python-based web servers for the test. Each request to the web server returns a video of a size 43 MB. For testing we used ApacheBench, a command-line program used for benchmarking HTTP web servers. ApacheBench allows parallel requests from multiple clients. For each web server instance we send a number of requests ranging from 100 to 1000 and a concurrency level between 1 and 100, representing the number of parallel clients performing the requests.</p> <p>The information available in the dataset are as follows:</p> <p><strong>time:</strong> timestamp of collection of metrics.</p> <p><strong>ram_limit:</strong> the memory allocated to the container in megabytes.</p> <p><strong>cpu_limit:</strong> the CPU allocated to the container.</p> <p><strong>ram_usage:</strong> the amount of memory used by the container at the time of the metrics collection in byte.</p> <p><strong>cpu_usage:</strong> the amount of CPU used by the container at the time of the metrics collection.</p> <p><strong>n:</strong> the number of requests sent to the container.</p> <p><strong>c:</strong> the concurrency level in the requests.</p> <p><strong>lat50:</strong> the least response time for the best 50% requests in microseconds.</p> <p><strong>lat66:</strong> the least response time for the best 66% requests in microseconds.</p> <p><strong>lat75:</strong> the least response time for the best 75% requests in microseconds.</p> <p><strong>lat80:</strong> the least response time for the best 80% requests in microseconds.</p> <p><strong>lat90:</strong> the least response time for the best 90% requests in microseconds.</p> <p><strong>lat95:</strong> the least response time for the best 95% requests in microseconds.</p> <p><strong>lat98:</strong> the least response time for the best 98% requests in microseconds.</p> <p><strong>lat99:</strong> the least response time for the best 99% requests in microseconds.</p> <p><strong>lat100:</strong> the least response time in microseconds.</p> <p> </p> <p><strong>5G Core network’s AMF:</strong></p> <p><strong>file: </strong>amf-performance.csv</p> <p>For testing we use my5G-RANTester, a tool for emulating control and data planes of the UE and gNB (5G base station). The number of simultaneous registration requests that are sent to each instance of the AMF varies between 10 and 400.</p> <p>The information available in the dataset are as follows:</p> <p><strong>time:</strong> timestamp of collection of metrics.</p> <p><strong>ram_limit:</strong> the memory allocated to the container in megabytes.</p> <p><strong>cpu_limit:</strong> the CPU allocated to the container.</p> <p><strong>ram_usage:</strong> the amount of memory used by the container at the time of the metrics collection in byte.</p> <p><strong>cpu_usage:</strong> the amount of CPU used by the container at the time of the metrics collection.</p> <p><strong>n:</strong> the number of parallel registration requests sent to the AMF.</p> <p><strong>mean:</strong> the mean registration time for all the registration requests in microseconds.</p> <p><strong>lat50:</strong> the median registration time for registration requests in microseconds.</p> <p><strong>lat75: </strong>the least registration time for the best 75% registration requests in microseconds.</p> <p><strong>lat80:</strong> the least registration time for the best 80% registration requests in microseconds.</p> <p><strong>lat90:</strong> the least registration time for the best 90% registration requests in microseconds.</p> <p><strong>lat95:</strong> the least registration time for the best 95% registration requests in microseconds.</p> <p><strong>lat98:</strong> the least registration time for the best 98% registration requests in microseconds.</p> <p><strong>lat99:</strong> the least registration time for the best 99% registration requests in microseconds.</p> <p><strong>lat100:</strong> the least registration time in microseconds.</p> <p> </p> <p><strong>RabbitMQ data broker:</strong></p> <p><strong>file: </strong>rabbitmq-performance.csv</p> <p>For testing we used RabbitMQ PerfTest which is a throughput testing tool that simulates basic workloads and provides the throughput and the time that a message takes to be consumed by a consumer. For each deployed RabbitMQ server we used a number of producers and consumers that ranges from 50 to 500. Each producer sends messages to the broker with a rate of 100 messages per second for a period of time of 90 seconds.</p> <p>The information available in the dataset are as follows:</p> <p><strong>time:</strong> timestamp of collection of metrics.</p> <p><strong>ram_limit:</strong> the memory allocated to the container in megabytes.</p> <p><strong>cpu_limit:</strong> the CPU allocated to the container.</p> <p><strong>ram_usage:</strong> the amount of memory used by the container at the time of the metrics collection in byte.</p> <p><strong>cpu_usage:</strong> the amount of CPU used by the container at the time of the metrics collection.</p> <p><strong>n:</strong> the number of producers sending messages to the RabbitMQ server.</p> <p><strong>Min:</strong> the minimum consumption time for the producer messages.</p> <p><strong>lat50:</strong> the median consumption time for the producer messages.</p> <p><strong>lat75:</strong> the least consumption time for the best 75% messages in microseconds.</p> <p><strong>lat95:</strong> the least consumption time for the best 95% messages in microseconds.</p> <p><strong>lat99:</strong> the least consumption time for the best 99% messages in microseconds.</p>
Benchmark dataset for preprint: "EDEN: A high-performance, general-purpose, NeuroML-based neural simulator"
<p>The benchmark files and scripts to reproduce the figures of the preprint "EDEN: A high-performance, general-purpose, NeuroML-based neural simulator" ( https://arxiv.org/abs/2106.06752 )</p> <p>The benchmarks require a computer running Linux with Docker installed.</p> <p>Unpack the paper_experiments.zip file and follow the instructions in the README.md file to run the benchmarks and reproduce the figures.</p> <p> </p>
SPEChpc 2021 Benchmarks: A Performance and Energy Case Study
SPEChpc 2021 Benchmarks on Ice Lake and Sapphire Rapids based Infiniband Clusters: A Performance and Energy Case Study.
Data for: Performance Benchmarking of Application Monitoring Frameworks
<p>Application-level monitoring of continuously operating software systems provides insights into their dynamic behavior, helping to maintain their performance and availability during runtime. Such monitoring may cause a significant runtime overhead to the monitored system, depending on the number and location of used instrumentation probes. In order to improve a system’s instrumentation and to reduce the caused monitoring overhead, it is necessary to know the performance impact of each probe.<br /> While many monitoring frameworks are claiming to have minimal impact on the performance, these claims are often not backed up with a detailed performance evaluation determining the actual cost of monitoring. Benchmarks can be used as an effective and affordable way for these evaluations. However, no benchmark specifically targeting the overhead of monitoring itself exists. Furthermore, no established benchmark engineering methodology exists that provides guidelines for the design, execution, and analysis of benchmarks.<br /> This thesis introduces a benchmark approach to measure the performance overhead of application-level monitoring frameworks. The core contributions of this approach are 1) a definition of common causes of monitoring overhead, 2) a general benchmark engineering methodology, 3) the MooBench micro-benchmark to measure and quantify causes of monitoring overhead, and 4) detailed performance evaluations of three different application-level monitoring frameworks. Extensive experiments demonstrate the feasibility and practicality of the approach and validate the benchmark results. The developed benchmark is available as open source software and the results of all experiments are available for download to facilitate further validation and replication of the results.</p> <p>This dataset supplements the thesis and contains the results of all experiments, including the raw result data, the results of additional experiments, and the configuration of our benchmarks.</p>
Replication Package for "TriggerBench: A Performance Benchmark for Serverless Function Triggers"
<p>This replication package contains the code (`aws-triggers` and `azure-trigger`), data analysis scripts (`data-analysis`), and dataset (`data`) of the TriggerBench cross-provider serverless benchmark.</p> <p>It also bundles a customized extension of the `serverless-benchmarker` tool to automate and analyze serverless performance experiments.</p> <p><strong>TriggerBench</strong></p> <p>The Github repository <a href="https://github.com/joe4dev/trigger-bench/">joe4dev/trigger-bench</a> contains the last version of TriggerBench. This replication package describes the version for the paper "TriggerBench: A Performance Benchmark for Serverless Function Triggers".</p> <p>TriggerBench currently supports three triggers on AWS and eight triggers on Microsoft Azure.</p> <p><strong>Dataset</strong></p> <p>The `data/aws` and `data/azure` directories contain data from benchmark executions from April 2022.</p> <p>Each execution is a separate directory with a timestamp in the format `yyyy-mm-dd-HH-MM-SS` (e.g., `2022-04-15_21-58-52`) and contains the following files:</p> <ul> <li>`k6_metrics.csv`: Load generator HTTP client logs in CSV format (see [K6 docs](https://k6.io/docs/results-visualization/csv/))</li> <li>`sb_config.yml`: serverless benchmarker execution configuration including experiment label.</li> <li>`trigger.csv`: analyzer output CSV per trace. <ul> <li>`root_trace_id`: The trace id created by k6 and adopted by the invoker function</li> <li>`child_trace_id`: The trace id newly created by the receiver function if trace propagation is not supported (this is the case for most asynchronous triggers)</li> <li>`t1`-`t4`: Timestamps following the trace model (see paper)</li> <li>`t5`-`t9`: Additional timestamps for measuring timestamping overhead</li> <li>`coldstart_f1=True|False`: coldstart status for invoker (f1) and receiver (f2) functions</li> <li>`trace_ids.txt`: text file with each pair of `root_trace_id` and `child_trace_id` on a new line.</li> </ul> </li> <li>`traces.json`: raw trace JSON representation as retrieved from the provider tracing service. For AWS, see [X-Ray segment docs](https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html). For Azure, see [Application Insights telemetry data model](https://docs.microsoft.com/en-us/azure/azure-monitor/app/data-model).</li> <li>`workload_options.json`: [K6 load scenario](https://k6.io/docs/using-k6/scenarios/) configuration.</li> </ul> <p><strong>Replicate Data Analysis</strong></p> <p><strong>Installation</strong></p> <p>1. Install [Python](https://www.python.org/downloads/) 3.10+</p> <p>2. Install Python dependencies `pip install -r requirements.txt`</p> <p><strong>Create Plots</strong></p> <p>1. Run `python plots.py` generates the plots and the statistical summaries presented in the paper.</p> <p>By default, the plots will be saved into a `plots` sub-directory.<br> An alternative output directory can be configured through the environment variable `PLOTS_PATH`.</p> <p>> Hint: For interactive development, we recommend the VSCode [Python extension](https://marketplace.visualstudio.com/items?itemName=ms-python.python) in [interactive mode](https://youtu.be/lwN4-W1WR84?t=107).</p> <p> </p> <p><strong>Replicate Cloud Experiments</strong></p> <p>The following experiment plan automates benchmarking experiments with different types workloads (constant and bursty).</p> <p>This generates a new dataset in the same format as described above.</p> <p> </p> <ol> <li> Set up a load generator as vantage point following the description in [LOADGENERATOR](./serverless-benchmarker/docs/LOADGENERATOR.md).</li> <li> Choose the `PROVIDER` (aws or azure) in the [constant.py](./experiment-plans/constant.py) experiment plan</li> <li> Run the [constant.py](./experiment-plans/constant.py) experiment plan <ol> <li> Open tmux</li> <li> Activate virtualenv `source sb-env/bin/activate`</li> <li> Run `./constant.py 2>&1 | tee -a constant.log`</li> </ol> </li> </ol> <p><strong>Contributors</strong></p> <p>The initial trigger implementations for AWS and Azure are based on two master thesis projects at Chalmers University of Technology in Sweden supervised by Joel:</p> <ul> <li>AWS + Azure: <a href="https://odr.chalmers.se/handle/20.500.12380/302822">Performance Comparison of Function-as- a-Service Triggers: A Cross-Platform Performance Study of Function Triggers in Function-as-a-Service</a> by Marcus Bertilsson and Oskar Grönqvist, 2021.</li> <li>Azure Extension: <a href="https://odr.chalmers.se/handle/20.500.12380/305138">Serverless Function Triggers in Azure: An Analysis of Latency and Reliability</a> by Henrik Lagergren and Henrik Tao, 2022.</li> </ul> <p>Joel contributed many improvements to their original source code as documented in the import commits <a href="https://github.com/joe4dev/trigger-bench/commit/a00b67a1dd8476ca77d026e59adf2674c7807e68">a00b67a</a> and <a href="https://github.com/joe4dev/trigger-bench/commit/6d2f5ef8bda0596b3f295cb6c6cbeba212c6ef43">6d2f5ef</a> and developed TriggerBench as an integrated benchmark suite (see commit history for detailed changelog).</p>
Application-Oriented Performance Benchmarks for Quantum Computing
<p>Complete dataset and Jupyter Notebook used to produce image files for the paper at</p> <p> https://arxiv.org/abs/2110.03137.</p> <p>To execute the notebook, copy the .ipynb file and the _data directory to the top level of the repository at:</p> <p> https://github.com/SRI-International/QC-App-Oriented-Benchmarks</p> <p> </p>
SUPER-G Benchmarking performance on commercial farms (task 3.1)
<p><span>The SUPER-<em>G </em>project aimed to co-develop sustainable Permanent Grassland (PG) systems and policies with farmers and policy makers to effectively optimise productivity whist supporting biodiversity and delivering other Ecosystem Services (ES). This was achieved through the completion of a series of Work Packages (WP). Work Package 3 aimed </span><span>to benchmark performance in terms of profitability and sustainability and the delivery of ES. This was achieved in part through </span><span>deliverable (D) D3.2, where an “</span><span>Overview of data, key gaps, and trends in PG management in the different biogeographic regions” was compiled. This overview included a survey of 352 farms across six biogeographic regions conducted in 2019, which explored on-farm management and differences between regions. A second, subsequent, survey was undertaken in 2023, which included 203 of the original farms from five biogeographic areas. Deliverable report 3.3. </span>describes the distribution of key indicators from farms surveyed in the first survey and describes any changes which were captured in the second survey. <span>A</span><span>gri-environment indicators and key sustainability indicators were identified in WP2 and include forage efficiency, grass utilisation (the proportion of grass dry matter grown that is consumed by livestock) and grass/clover dry matter (DM) productivity. Due to the limitations of how many questions can be asked in a survey and the time required to perform a survey, it was not possible to calculate all these metrics. This report examines the sustainability indicators of stocking density, grass production and output per hectare and environmental indicators of areas reserved for nature and biodiversity.</span></p> <p> </p> <p><span>The data files include the survey questions, responses from 2021 survey, responses from 2023 survey and a blank survey form. </span></p>
Artifact Description/Artifact Evaluation/Computational Artifact for "SPEChpc 2021 Benchmarks on Ice Lake and Sapphire Rapids Infiniband Clusters: A Performance and Energy Case Study"
<p>We provide reproducibility initiative dependencies (Artifact Description or Artifact Evaluation or Computational Results Analysis) appendix at https://github.com/RRZE-HPC/PMBS23-AD. To allow a third party to duplicate the findings, this article provides our extensive performance data artifact and describes further details regarding the software environments, experimental design, and methodology employed for the results shown in the paper, entitled "SPEChpc 2021 Benchmarks on Ice Lake and Sapphire Rapids Infiniband Clusters: A Performance and Energy Case Study". The computational artifacts will enable experienced performance engineers to reproduce and interpret the data shown in the paper in the appropriate way and to follow the conclusions we draw from it.</p>
Data for: Including Performance Benchmarks into Continuous Integration to Enable DevOps
<p>The DevOps movement intends to improve communication, collaboration, and integration between software developers (Dev) and IT operations professionals (Ops). Automation of software quality assurance is key to DevOps success. We present how automated performance benchmarks may be included into continuous integration. As an example, we report on regression benchmarks for application monitoring frameworks and illustrate the inclusion of automated benchmarks into continuous integration setups.</p> <p>This dataset supplements the paper and contains the raw experimental data for each experiment.</p>
Performance Measurement Dataset of the HPC Benchmarks FASTEST, Kripke, LULESH, MiniFE, Quicksilver, and RELeARN for Scalability Studies with Extra-P
<p>This dataset contains performance measurements of the HPC benchmarks FASTEST, Kripke, LULESH, MiniFE, Quicksilver, and RELeARN intended to be used for scalability studies with Extra-P (https://github.com/extra-p/extrap). The datasets contains measurements of various application configurations considering several model parameters, e.g., the number of MPI ranks and the input problem size, using weak scaling for each benchmark.</p>
Performance Measurement Dataset of the HPC Benchmarks FASTEST, Kripke, and RELeARN for Cost-Effective Modeling Analysis with Extra-P
<p>Performance Measurement Dataset of the HPC Benchmarks FASTEST, Kripke, RELeARN for Scalability Studies with Extra-P. This data was used to analyze cost-effective modeling approaches presented in the IPDPS 2020 paper "Learning Cost-Effective Sampling Strategies for Empirical Performance Modeling".</p>
Power, performance and system measures of HPC benchmarks on multiple hardware
Open the record for dataset details and reuse information.
Precalculated Results of Throughput Analysis in "Comprehensive Benchmarking of High-Performance Vector Field Representations"
<p>This repository contains results calculated by our throughput analysis. These results should be exactly and deterministically reproducible using the aforementioned software, but precomputed results are provided for the benefit of the reader, in case certain software is not available. Included in this artifact are the assembly files generated by the compilers, the throughput analysis of these aforementioned assembly files, and a collection of tables which summarize the results.</p> <p>These results were generated using <em>clang</em> version 14.0.6, <em>gcc</em> version 11.2.0, and <em>llvm-mca</em> version 14.0.6.</p>
Data for "A benchmarking method to rank the performance of physics-based earthquake simulations"
<p>This repository contains the datasets and codes supplementary to the article "<strong>A benchmarking method to rank the performance of physics-based earthquake simulations</strong>" submitted to <em>Seismological Research Letters</em>.</p> <p>The datasets include the codes to run the ranking analyses, inputs and outputs for the RSQSim earthquake simulation cases explained in the paper: a single fault and the fault system of the Eastern Betics Shear Zone (simulations from Herrero-Barbero et al. 2021). The results and data are stored in a separate folder for each case study presented in the paper: "Single fault" and "EBSZ". Each folder contains a series of subfolders and a Python script to run the ranking analysis for that specific case study. The script contains the default path references to read all necessary input files for the analysis and automatically save all the outputs. The subfolders are:</p> <p><strong>./Inputs: </strong>This folder contains the input files required for the RSQSim simulations. This includes:</p> <p>a. The fault model ("Nodes_RSQSim.flt" and "EBSZ_model.csv" for the single fault and EBSZ cases, respectively), which specifies the coordinate nodes of the fault triangular meshes and fault properties such as rake (º) and slip rate (m/yr).</p> <p>b. Neighbor file ("neighbors.dat"/"neighbors.12") that contains lists of triangular patches of the fault model that are neighboring. This file is used in RSQSim.</p> <p>c. Input parameter file ("Input_Parameters.txt"): this file specifies the parameters that are variable in each catalogue. This file is just for information purposes and is not used for the calculations.</p> <p>d. Parameter file(s) to run the RSQSim calculations.</p> <p>*For the single fault, this file is common ("test_normal.in") and is updated during the calculation when executing the "Run.sh" file in the terminal when running RSQSim. This file contains a script that loops through the input parameters a, b and normal stress explored in the study and changes the input parameter file accordingly in each iteration.</p> <p>*For the EBSZ, this file is specific for each simulation ("param_EBSZ_(n).in"), as each simulation was run separately.</p> <p>e. (Only for the EBSZ case) Input paleoseismic data for the paleorate benchmark. One file ("coord_sites_EBSZ.csv") contains a list of UTM coordinates of each paleoseismic site in the EBSZ and another ("paleo_rates_EBSZ.csv") contains the mean recurrence intervals and annual paleoearthquake rates in those sites (data from Herrero-Barbero et al., 2021).</p> <p><strong>./Simulation_models:</strong> contains several subfolders, one for each simulated catalogue (96 for the single fault case and 11 for the EBSZ). Each subfolder contains data that is read by the ranking code to perform the analysis. </p> <p>*For the single fault, the folder names follow the structure "model_(normal stress)<em>(a)</em>(b)". </p> <p>*For the EBSZ, the folder names are "cat-(n)".</p> <p><strong>./Ranking_results: </strong>contains the outputs of the ranking analysis, which are two figures and one text file.</p> <p>*Figure 1 ("Final_ranking.pdf"): visualization of the final ranking analysis for all models against the analyzed benchmarks.</p> <p>*Figure 2 ("Parameter_sensitivity.pdf"): visualization of the final and benchmark performance versus the input parameter of the models.</p> <p>*Text file ("Ranking_results.txt"): contains the final and benchmark scores of each simulation model. This file is outputted so the user can reproduce and customize their own figures with the ranking results.</p> <p>To use the ranking codes in you own datasets, please replicate the folder structure explained above. Use the code that best suits your data: use the one for the single fault if you wish not to use the paleorate benchmarks, and use the EBSZ one if you wish to include these data in your analysis. At the beginning of the respective codes (before the "Start" block comment) you will find the variables where the file names of the fault model and paleoseismic data are indicated. Change them to adapt it to your data. There you can also assign weights to the respective benchmarks in the analysis (default is set at equal weight for all benchmarks).</p> <p>For updates of the code please visit our GitHub: https://github.com/octavigomez/Ranking-physics-based-EQ-simulations</p>
PianoMotion10M: Dataset and Benchmark for Hand Motion Generation in Piano Performance
<p>Recently, artificial intelligence techniques for education have been received increasing attentions, while it still remains an open problem to design the effective music instrument instructing systems. Although key presses can be directly derived from sheet music, the transitional movements among key presses require more extensive guidance in piano performance. In this work, we construct a piano-hand motion generation benchmark to guide hand movements and fingerings for piano playing. To this end, we collect an annotated dataset, PianoMotion10M, consisting of 116 hours of piano playing videos from a bird's-eye view with 10 million annotated hand poses. We also introduce a powerful baseline model that generates hand motions from piano audios through a position predictor and a position-guided gesture generator. Furthermore, a series of evaluation metrics are designed to assess the performance of the baseline model, including motion similarity, smoothness, positional accuracy of left and right hands, and overall fidelity of movement distribution. Despite that piano key presses with respect to music scores or audios are already accessible, PianoMotion10M aims to provide guidance on piano fingering for instruction purposes.</p>
A Generic Model for Benchmark Aerodynamic Analysis of Fifth-Generation High-Performance Aircraft
<p>Openly available supplementary data to accompany paper https://doi.org/10.3390/aerospace10090746. Data set includes geometry, Pointwise (2022.1.2) and Fluent (2022R1) grid files and corrected experimental data for lift, drag and pitching moment at a freestream velocity of 20 m/s and standard sea level conditions for the SSAM-Gen5 model. When using this data, please cite:</p> <p>Giannelis, N.F.; Bykerk, T.; Vio, G.A. A Generic Model for Benchmark Aerodynamic Analysis of Fifth-Generation High-Performance Aircraft. Aerospace 2023, 10, 746.</p>
Performance Measurement Datasets of the HPC Benchmarks LAMMPS, MiniFE, LULESH for Hardware Counter Variance Analysis
Open the record for dataset details and reuse information.
Performance data for 10 DE variants on BBOB benchmark suite in 10 dimensions (13-24 problems)
Open the record for dataset details and reuse information.
Hyperbolic Benchmarking Unveils Network Topology-Feature Relationship in GNN Performance
<p>Dataset of the synthetic networks used in the paper "Hyperbolic Benchmarking Unveils Network Topology-Feature Relationship in GNN Performance".</p>
Datasets for benchmarking GeoFlood performance with realistic problems
<p>Datasets and configurations used in benchmarking the CPU/GPU hybrid version of GeoFlood.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.