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.
10
datasets available to search
ShareScore release 0.9.0
Dataset results
10 results for “Cloud 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>
Replication Package for: Benchmarking scalability of stream processing frameworks deployed as microservices in the cloud
<h2>Replication Package for: Benchmarking scalability of stream processing frameworks deployed as microservices in the cloud</h2><p>This is our replication package for our study on <i>Benchmarking scalability of stream processing frameworks deployed as microservices in the cloud</i>.</p><p>All scalability experiments are performed with the scalability benchmarking framework <a href="https://www.theodolite.rocks/">Theodolite</a> at <a href="https://www.se.informatik.uni-kiel.de/en/research/software-performance-engineering-lab-spel">Kiel University's Software Performance Engineering Lab (SPEL)</a> or Google Cloud.</p><p>With this replication package, we provide:</p><ul><li><a href="https://www.theodolite.rocks/concepts/benchmarks-and-executions.html">Benchmark execution files</a> in <i>executions</i>,</li><li>our benchmark (raw) results in <i>results</i>, and</li><li>analysis script for our results in <i>analysis</i>.</li></ul><h3>Repeating Benchmark Executions</h3><p>All our Theodolite executions are tailored to either the SPEL cluster or the Google Cloud.</p><h4>Kiel University's Software Performance Engineering Lab (SPEL)</h4><p>The SPEL cluster consists of 5 nodes, named <i>kube1-1</i> to <i>kube1-5</i> and labeled with <i>env=dev</i>. To run them in your local cluster, make sure to provide the same infrastructure or rename node selectors in the execution files accordingly.</p><p>To install Theodolite, run:</p><blockquote><p>helm install theodolite theodolite/theodolite --version 0.8.6 -f https://raw.githubusercontent.com/cau-se/theodolite/main/helm/preconfigs/extended-metrics.yaml -f se-cluster-dev.yaml</p></blockquote><p>or for the vertical scalability experiment:</p><blockquote><p>helm install theodolite theodolite/theodolite --version 0.8.6 -f https://raw.githubusercontent.com/cau-se/theodolite/main/helm/preconfigs/extended-metrics.yaml -f se-cluster-dev.yaml -f se-cluster-dev-vertical.yaml</p></blockquote><p>See <a href="https://www.theodolite.rocks">Theodolite's documentation</a> for further usage instructions.</p><h4>Google Cloud</h4><p>In the public cloud baseline experiments, the cluster consists of 5 e2-standard-32 nodes.</p><p>To install Theodolite, run:</p><blockquote><p>helm install theodolite theodolite/theodolite --version 0.8.6 -f https://raw.githubusercontent.com/cau-se/theodolite/main/helm/preconfigs/extended-metrics.yaml -f gcp-cluster-dev.yaml</p></blockquote><p>For the experiments testing higher load intensities, the cluster consists of 4 e2-standard-16 nodes labeled with <i>type=infra</i> and 4 or 8 e2-standard-16 nodes with label <i>type=sut</i>. To install Theodolite in this cluster, run:</p><blockquote><p>helm install theodolite theodolite/theodolite --version 0.8.6 -f https://raw.githubusercontent.com/cau-se/theodolite/main/helm/preconfigs/extended-metrics.yaml -f gcp-cluster-stress.yaml</p></blockquote><p>In both cases, change the maximum load generated per load generator instance:</p><blockquote><p># Generate max. 100000 rec/sec per load generator instance export MAX_RECORDS_PER_INSTANCE=100000 kubectl patch benchmarks uc1-beam-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc1-beam-samza --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc1-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc1-hazelcastjet --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc1-kstreams --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc2-beam-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc2-beam-samza --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc2-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc2-hazelcastjet --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc2-kstreams --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc3-beam-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc3-beam-samza --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc3-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc3-hazelcastjet --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc3-kstreams --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc4-beam-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc4-beam-samza --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc4-flink --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc4-hazelcastjet --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]" kubectl patch benchmarks uc4-kstreams --type json --patch "[{op: replace, path: /spec/loadTypes/0/patchers/1/properties/loadGenMaxRecords, value: $MAX_RECORDS_PER_INSTANCE}]"</p></blockquote><p>See <a href="https://www.theodolite.rocks">Theodolite's documentation</a> for further usage instructions.</p><h3>Repeating Results Analysis</h3><p>To inspect, repeat, or extend our results analysis, see <i>results</i> or run the corresponding notebooks in <i>analysis</i>.</p><p>For analyzing and visualizing benchmark results, either Docker or a Jupyter installation with Python 3.7 or 3.8 is required (e.g., in a virtual environment). Moreover, we require some Python libraries, which can be installed by:</p><blockquote><p>python3.8 -m venv .venv # source .venv/bin/activate pip install -r analysis/requirements.txt</p></blockquote><p> </p>
Pangeo Cloud Storage Read Throughput Benchmarks
<p>These are the results of benchmarking distributed reads from various cloud storage services and data formats. All tests were performed from the Google cloud US-CENTRAL1 region.</p>
Benchmarking results of Master's Thesis: "GreenTech: Efficiency Benchmarking of Cloud-Native Applications in Kubernetes"
<p>This zip file includes the benchmarking results of the Master's Thesis: "GreenTech: Efficiency Benchmarking of Cloud-Native Applications in Kubernetes". <br><br>The top-most directory corresponds to the research method which may incorporate multiple benchmarks. <br>Each directory contains both the benchmark and execution specification along with the results. </p>
Replication Package for: A Configurable Method for Benchmarking Scalability of Cloud-Native Applications
<p>This repository contains a replication package and experimental results for our study <em>A Configurable Method for Benchmarking Scalability of Cloud-Native Applications</em>.</p> <p>It provides benchmark execution files for repeating our experiments as well as the collected data from our experiments and Jupyter notebooks for reproducing our analysis.</p> <p>Instructions for repeating our experiments and reproducing our analysis can be found in the Readme.md file.</p>
Final point cloud results of DAR-MVSNet on Tanks and Temples benchmark
<p>Final point cloud results of DAR-MVSNet on Tanks and Temples benchmark.</p>
Final point cloud results of SPC-MVSNet on Tanks and Temples benchmark
<p>SPC-MVSNet在坦克和寺庙基准上的最终点云结果。</p>
A Dynamic Points Removal Benchmark in Point Cloud Maps
<p>Uniformat Dataset LiDAR Point Cloud Data [PCD format: with pose and points (x,y,z,/i)] <br>We recommend you read this wiki page first to know about data: <a href="https://kth-rpl.github.io/DynamicMap_Benchmark/data/">https://kth-rpl.github.io/DynamicMap_Benchmark/data/</a><br>For methods detail: <a href="https://github.com/KTH-RPL/DynamicMap_Benchmark">DynamicMap_Benchmark repo</a>, <a href="https://github.com/KTH-RPL/dufomap">DUFOMap</a>, <a href="https://github.com/MKJia/BeautyMap">BeautyMap</a>.</p> <ul> <li>00: <a href="https://www.cvlibs.net/datasets/kitti/index.php">KITTI sequence</a> 00 [VLP-64] from frame 4390 to 4530</li> <li>05: <a href="https://www.cvlibs.net/datasets/kitti/index.php">KITTI sequence</a> 05 [VLP-64] from frame 2350 to 2670</li> <li>av2: <a href="https://www.argoverse.org/av2.html">Argoverse 2.0</a> one sequence on <em>07YOTznatmYypvQYpzviEcU3yGPsyaGg__Spring_2020. </em>[2 x VLP-32]</li> <li>KTH campus: <a href="https://mcdviral.github.io/">CVPR'24 MCD</a>(Leica RTC360) For convenience teaser running, we include only 18 frames in data. Please check <a href="https://mcdviral.github.io/">the MCD project page</a> for more.</li> <li>semindoor: semi-indoor dataset collected by [VLP-16], collected by ourselves. </li> <li>twofloor: complex structure with two floors[Livox mid-360], collected by ourselves.</li> </ul> <p> </p> <table> <tbody> <tr> <td>Dataset</td> <td>Description</td> <td>Sensor Type</td> <td>Total Frame Number</td> </tr> <tr> <td>KITTI sequence 00</td> <td>in a small town with few dynamics (including one pedestrian around)</td> <td>VLP-64</td> <td>141</td> </tr> <tr> <td>KITTI sequence 05</td> <td>in a small town straight way, one higher car, the benchmarking paper cover image from this sequence.</td> <td>VLP-64</td> <td>321</td> </tr> <tr> <td>Argoverse2</td> <td>in a big city, crowded and tall buildings (including cyclists, vehicles, people walking near the building etc.</td> <td>2 x VLP-32</td> <td>575</td> </tr> <tr> <td>KTH campus (no gt)</td> <td>Collected by us (Thien-Minh) on the KTH campus. Lots of people move around on the campus. The DUFOMap paper cover image is from this one.</td> <td>Leica RTC360</td> <td>18</td> </tr> <tr> <td>Semi-indoor</td> <td>Collected by us (Qingwen & Mingkai), running on a small 1x2 vehicle with two people walking around the platform.</td> <td>VLP-16</td> <td>960</td> </tr> <tr> <td>Twofloor (no gt)</td> <td>Collected by us (Bowen Yang) in a quadruped robot. A two-floor structure environment with one pedestrian around.</td> <td>Livox-mid 360</td> <td>3305</td> </tr> </tbody> </table> <p> </p> <p>Cite as:</p> <blockquote> <p>@inproceedings{zhang2023benchmark,<br> author={Zhang, Qingwen and Duberg, Daniel and Geng, Ruoyu and Jia, Mingkai and Wang, Lujia and Jensfelt, Patric},<br> booktitle={IEEE 26th International Conference on Intelligent Transportation Systems (ITSC)}, <br> title={A Dynamic Points Removal Benchmark in Point Cloud Maps}, <br> year={2023},<br> pages={608-614},<br> doi={10.1109/ITSC57777.2023.10422094}<br>}<br>@article{jia2024beautymap,<br> author={Jia, Mingkai and Zhang, Qingwen and Yang, Bowen and Wu, Jin and Liu, Ming and Jensfelt, Patric},<br> journal={IEEE Robotics and Automation Letters}, <br> title={{BeautyMap}: Binary-Encoded Adaptable Ground Matrix for Dynamic Points Removal in Global Maps}, <br> year={2024},<br> volume={9},<br> number={7},<br> pages={6256-6263},<br> doi={10.1109/LRA.2024.3402625}<br>}<br>@article{daniel2024dufomap,<br> author={Duberg, Daniel and Zhang, Qingwen and Jia, Mingkai and Jensfelt, Patric},<br> journal={IEEE Robotics and Automation Letters}, <br> title={{DUFOMap}: Efficient Dynamic Awareness Mapping}, <br> year={2024},<br> volume={9},<br> number={6},<br> pages={5038-5045},<br> doi={10.1109/LRA.2024.3387658}<br>}</p> </blockquote> <p> </p> <p>If you use this data, feel free to add your project to <a href="https://kth-rpl.github.io/DynamicMap_Benchmark/papers/">https://kth-rpl.github.io/DynamicMap_Benchmark/papers/</a></p>
Sampling in Cloud Benchmarking: A Critical Review and Methodological Guidelines
<p>This replication package contains the data and code to replicate our critical review on sampling in cloud benchmarking.</p> <p> </p> <p><strong>Paper</strong></p> <p>Akbari, Saman, and Manfred Hauswirth. "Sampling in Cloud Benchmarking: A Critical Review and Methodological Guidelines." <em>2024 IEEE International Conference on Cloud Computing Technology and Science (CloudCom)</em>. IEEE, 2024. DOI: <a href="https://doi.org/10.1109/CloudCom62794.2024.00034" target="_blank" rel="noopener">10.1109/CloudCom62794.2024.00034</a>.</p> <pre>@inproceedings{akbari2024sampling, title={Sampling in Cloud Benchmarking: A Critical Review and Methodological Guidelines}, author={Akbari, Saman and Hauswirth, Manfred}, booktitle={2024 IEEE International Conference on Cloud Computing Technology and Science (CloudCom)}, pages={160--167}, year={2024}, organization={IEEE} }</pre> <p> </p> <p><strong>Abstract</strong></p> <blockquote> <p>Cloud benchmarks suffer from performance fluctuations caused by resource contention, network latency, hardware heterogeneity, and other factors along with decisions taken in the benchmark design. In particular, the sampling strategy of benchmark designers can significantly influence benchmark results. Despite this well-known fact, no systematic approach has been devised so far to make sampling results comparable and guide benchmark designers in choosing their sampling strategy for use within benchmarks. To identify systematic problems, we critically review sampling in recent cloud computing research. Our analysis identifies concerning trends: (i) a high prevalence of non-probability sampling, (ii) over-reliance on a single benchmark, and (iii) restricted access to samples. To address these issues and increase transparency in sampling, we propose methodological guidelines for researchers and reviewers. We hope that our work contributes to improving the generalizability, reproducibility, and reliability of research results.</p> </blockquote>
Benchmarking Turbulence Models to Represent Cloud-Edge Mixing
<p>This is the simulation output of the submitted manuscript "Benchmarking Turbulence Models to Represent Cloud-Edge Mixing" to the Journal of Atmospheric Sciences. </p> <p>Abstract: Considering turbulence is crucial to understand clouds. However, covering all scales involved in the turbulent mixing of clouds with their environment is computationally challenging, urging the need for simple models to represent some of the involved processes. By using full direct numerical simulations as a reference, this study compares several statistical approaches for representing small-scale turbulent mixing. All models use a comparable Lagrangian representation of cloud microphysics, and simulate the same cases of cloud edge mixing, covering different ambient humidities and turbulence intensities. It is demonstrated that all statistical models represent the evolution of thermodynamics successfully, but not all models capture the changes in cloud microphysics (cloud droplet number concentration, droplet mean radius, and spectral width). Implications of these results for using the presented models as subgrid-scale schemes are discussed.</p> <p>The raw data presented here was produced by five different models and is completely available. For information on how the dataset is structured, see the readme.txt.</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.