Find research datasets worth reusing

opencc-by-4.0Jun 2022View details →

Replication package and appendixes for Causal inference of server- and client-side code smells in web apps evolution

-Analysis  --R scripts used to make the analisys, divided by folders --Data folders used in the questions -Appendixes - used in the article to shwo extra tables and plots -data folders - Aggregation of data, each app has two files, CSV and xls -separated data folders - 5 files for each app, with lines corresponding to the each released official version --serversmells --clientsmells --javascriptsmells --Cloc(metrics) --version (all oficial releases) -issues_bugs --data -issues by app by release  --data_bugs_more - the same but only bugs, by app by release --scripts - scrips used to aggregate issues (from daily issues to by release) anf the same for bugs

opencc-by-4.0Mar 2022View details →

OpenFOAM cases of the paper "CFD modeling of pressure drop through an OCP server for data center applications"

This dataset contains the underling data for the paper "CFD modeling of pressure drop through an OCP server for data center applications” in Energies Journal. Numerical simulations are performed using open-source CFD code OpenFOAM. Features of the numerical model described in the paper can be summarized as: <ul> <li> A hexahedra (hex) and split-hex mesh was created using snappyHexMesh utility from the STL (Stereolithography) model of the server</li> <li>Allrun script runs steady-state simulations for different inlet flow rates given in the flowrates file.</li> <li>k-omegaSST turbulence closure model is used</li> <li>Convective and diffusive fluxes are computed using second-order accurate numerical schemes.</li> <li>Resultant matrices are solved using GAMG and smoothSolver methods.</li> </ul> New libraries are developed for the detection of whether the solution reaches state-state and for the calculation of average pressures at the inlet and outlet of the server. These libraries need to be download via the following link and compiled before the cases run:   <a href="https://github.com/DSTECHNO/OCPFoam">https://github.com/DSTECHNO/OCPFoam</a> active_Server.tar.gz: OpenFOAM files and scripts for the steady-state simulation of turbulent flow flow over Leopard V3.1 model of OCP server neglecting fan blades. inactive_Server.tar.gz: OpenFOAM files and scripts for the steady-state simulation of turbulent flow over Leopard V3.1 model of OCP server considering fan blades. Results_active_Server.tar.gz: Simulation results for active server. Results_inactiveServer.tar.gz:  Simulation results for inactive server.

opencc-by-sa-4.0Sep 2018View details →

On The Design and Application of Thermal Isolation Servers

Dataset. Recently, there has been an increasing trend towards executing real-time applications on multi-core platforms. However, this complicates the design problem, as applications running on different cores can interfere due to shared resources and mediums. In this paper, we focus on thermal interference, where a given task (τ1) heats the processor, resulting in reduced service (due to Dynamic Thermal Management (DTM)) to another task (τ2). In real-time domain, where tasks have deadline constraints, thermal interference is a substantial problem as it directly impacts the Worst Case Execution Time (WCET) of the effected application (τ2). The problem exacerbates as we move to mixed-criticality systems, where the criticality of τ2 may be greater than the criticality of τ1, complicating the certification process. In this paper,we propose a server based strategy (Thermal Isolation Server (TI Server))which can be used to avoid thermal interference of applications.We also present a heuristic to design TI Servers to meet the timing constraints of all tasks and the thermal constraints of the system. TI Servers are time/space composable, and can be applied to a variety of task models. We also evaluate TI Servers on a hardware test-bed for validation purposes.

opencc-by-4.0Apr 2019View details →

Server-side I/O request arrival traces

Dataset generated for the "On server-side file access pattern matching" paper (Boito et al., HPCS 2019). The traces were obtained following the methodology described in the paper. In addition to the two data sets discussed in the paper, we are also making available an extra data set of server traces. Traces from I/O nodes <ul> <li>IOnode_traces/output/commands has the list of commands used to generate them. Each test is identified by a label, and the test_info.csv file contains the mapping of labels to access patterns. Some files include information about experiments with 8 I/O nodes, but these were removed from the data set because they had some errors.</li> <li>IOnode_traces/output contains .map files that detail the mapping of clients to I/O nodes for each experiment, and .out files, which contain the output of the benchmark.</li> <li>IOnode_traces/ contains one folder per experiment. Inside this folder, there is one folder per I/O node, and inside these folders there are tracefiles for the read and write portions of the experiments. Due to a mistake during the integration between IOFSL and AGIOS, read requests appear as "W", and writes as "R". Once accounted for when processing the traces, that has no impact on results.</li> <li>pattern_length.csv contains the average pattern length for each experiment and operation (average number of requests per second), obtained with the get_pattern_length.py script.</li> </ul> Each line of a trace looks like this: <code>277004729325 00000000eaffffffffffff1f729db77200000000000000000000000000000000 W 0 262144</code> The first number is an internal timestamp in nanoseconds, the second value is the file handle, and the third is the type of the request (inverted, "W" for reads and "R" for writes). The last two numbers give the request offset and size in bytes, respectively. Traces from parallel file sytem data servers These traces are inside the server_traces/ folder. Each experiment has two concurrent applications, "app1" and "app2", and its traces are inside a folder named accordingly: <code>NOOP\_app1\_(identification of app1)\_app2\_(identification of app2)\_(repetition)\_pvfstrace/</code> Each application is identified by: <code>(contig/noncontig)\_(number and size of requests per process)\_(number of processes)\_(number of client machines)\_(nto1/nton regarding the number of files)</code> Inside each folder there are eight trace files, two per data server, one for the read portion and another for the write portion. Each line looks like this: <code>[D 02:54:58.386900] REQ SCHED SCHEDULING, handle: 5764607523034231596, queue_element: 0x2a11360, type: 0, offset: 458752, len: 32768</code> The part between [] is a timestamp, "handle" gives the file handle, "type" is 0 for reads and 1 for writes, "offset" and "len" (length) are in bytes. <ul> <li>server_traces/pattern_length.csv contains the average pattern length for each experiment and operation, obtained with the server_traces/count_pattern_length.py script.</li> </ul> Extra traces from data servers These traces were not used for the paper because we do not have performance measurements for them with different scheduling policies, so it would not be possible to estimate the results of using the pattern matching approach to select scheduling policies. Still, we share them in the extra_server_traces/ folder in the hope they will be useful. They were obtained in the same experimental campaign than the other data server traces, and have the same format. The difference is that these traces are for single-application scenarios.

opencc-by-4.0Oct 2019View details →

Web robot detection - Server logs

This dataset contains server logs from the search engine of the library and information center of the Aristotle University of Thessaloniki in Greece (<a href="http://search.lib.auth.gr/">http://search.lib.auth.gr/</a>). The search engine enables users to check the availability of books and other written works, and search for digitized material and scientific publications. The server logs obtained span an entire month, from March 1st to March 31 2018 and consist of 4,091,155 requests with an average of 131,973 requests per day and a standard deviation of 36,996.7 requests. In total, there are requests from 27,061 unique IP addresses and 3,441 unique user-agent strings. The server logs are in JSON format and they are anonymized by masking the last 6 digits of the IP address and by hashing the last part of the URLs requested (after last /). The dataset also contains the processed form of the server logs as a labelled dataset of log entries grouped into sessions along with their extracted features (simple semantic features). We make this dataset publicly available, the first one in this domain, in order to provide a common ground for testing web robot detection methods, as well as other methods that analyze server logs.

opencc-by-4.0Apr 2023View details →

Dataset from VR Streaming Server (Emulated) and Radio Access Network for Streaming Traffic

The dataset contains an experiment in  a site where UEs attach to a gNodeB that provides access to a streaming server that is stressed with high demanding transcoding workloads to emulate VR/AR processes. The UEs are realized through the Remote UE mode enabled by Amarisoft Simbox emulator, and the gNodeB is realized through the Amarisoft Callbox, which also provides the user plane function. The emulated VR streaming server is deployed as a Nginx pod in a Kubernetes cluster. We rely on MonB5G sampling functions that feed monitoring data (CPU and RAN parameters) to the monitoring system. A streaming video server has been deployed with the help of a NGINX server. It provides video-on-demand and video streaming, which can be accessed by any user (or UE) for real-time reproduction. This VR video streaming emulation aids to assess the performance of the network and therefore the benefits that each solution has brought. The video “Big Buck Bunny” with h.264 encoding and a resolution of 1920x1080p has been used for the experiments.The description of dataset features are: 1-) Index Number, 2-) Time: Time of the experiment, 3-) N: number of VR streaming clients, 4-) C: Average CPU of VR streaming server [mc] 5-) O: Outbound traffic at the server average outbound traffic (O) flowing from the data interface of the video server.  6-) R: Instantaneous downlink bit rate [Mbps], The original video file information: <table> <tbody> <tr> <td> Video codec  </td> <td> Advanced Video Codec (AVC)  </td> </tr> <tr> <td> Width  </td> <td> 1920 pixels  </td> </tr> <tr> <td> Height  </td> <td> 1080 pixels  </td> </tr> <tr> <td> Display aspect radio  </td> <td> 16:9  </td> </tr> <tr> <td> Duration  </td> <td> 10 min 34 s  </td> </tr> <tr> <td> Max Bitrate  </td> <td> 16.7 Mb/s  </td> </tr> <tr> <td> Frame rate  </td> <td> 30 FPS  </td> </tr> </tbody> </table>

opencc-by-4.0May 2020View details →

SPEC CPU 2017 Benchmark Suite Results for the HPE ProLiant DL385 Gen10 server

Benchmark results for the SPEC CPU 2017 benchmark suite with the full power and temperature data. Data is collected on a state-of-the-art HPE ProLiant DL385 Gen10 server. Results contain two full runs of the SPEC CPU 2017 benchmark suite. One result set of all four benchmark suites with compiler optimizations matching official results and a second set with moderate, real-world, compiler settings.

opencc-by-4.0May 2022View details →

Dataset of DNS over HTTPS (DoH) Internet Servers

Description The DoH Internet Servers dataset comprises a verified list of Internet servers offering DNS over HTTPS (DoH). This is an updated <a href="http://doi.org/10.17632/ny4m53g6bw.1">10.17632/ny4m53g6bw.1</a> The list was created through the aggregation of a previously existing, but incomplete, list of DoH servers. The servers in this dataset went through a verification phase where it was confirmed they were active and working as advertised. The verification was done between May 1st, 2022, and May 4th, 2022. The dataset contains a total of 254 unique DoH servers, out of which 136 are over IPv4 and 118 over IPv6. The DoH servers belong to 59 unique Autonomous Systems and are associated with a total of 106 unique domain names. The following public lists of existing DoH servers were used to create this dataset: <ul> <li>https://developers.google.com/speed/public-dns/docs/doh/json</li> <li>https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/</li> <li>https://github.com/curl/curl/wiki/DNS-over-HTTPS</li> <li>https://help.keenetic.com/hc/en-us/articles/360007687159-DNS-over-TLS-and-DNS-over-HTTPS-proxy-servers-for-DNS-requests-encryption</li> <li>https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers</li> <li>https://kb.adguard.com/en/general/dns-providers</li> <li>https://applied-privacy.net/services/dns/</li> <li>https://www.pacnog.org/pacnog24/presentations/DoT-DoH-DNS-Privacy.pdf</li> <li>https://www.privacytools.io/providers/dns/</li> </ul>   The verification of the DoH servers was performed using a custom-made python script. The script is available at: https://github.com/stratosphereips/DoH-Research/tree/main/validation-script

opencc-by-4.0Jul 2022View details →

Outputs of the paper "Blockchain-enabled Server-less Federated Learning"

This repository contains the different outputs generated for the paper "Blockchain-enabled Server-less Federated Learning", submitted to Computer Networks (COMNET) journal. Two types of outputs are provided: <ol> <li>Blockchain queue simulator (output_queue_simulator): results of the simulations done in the batch-service queue simulator (https://github.com/fwilhelmi/batch_service_queue_simulator) to characterize the queue latency of blockchain applications.</li> <li>Tensorflow (output_tensorflow): results of the simulations done in Tensorflow Federated (TFF), resulting from the application of different models to the federated EMNIST dataset.</li> </ol> Each folder also includes the scripts used to execute the corresponding simulations. For more details, see the repository in https://github.com/fwilhelmi/blockchain_enabled_federated_learning

opencc-by-4.0Mar 2018View details →

Preprints Servers as a Hub for Early-Stage Research Outputs

Data for "Preprints as a Hub for Early-Stage Research Outputs" This data set contains three documents results from a survey focused on how  preprint servers relate to open science. See http://researchpreprints.com/2017/12/18/a-short-research-project-where-do-preprints-fit-in/ for the research plan.  - submission systems and websites.xlsx A check of submission pages for preprint servers. Opportunities to link to other early-stage research outputs were recorded. Information displayed on websites was also checked on an  ad hoc basis.  - preprint abstracts.xlsx   A check of 25 or 50 preprints for selected preprint servers, to see what information linking to other early-stage research outputs was visible.  - preprint operator survey   Individual responses from a survey of those operating preprint servers. Names and email addresses were collected but are not reported.

openodc-byJan 2020View details →

Server room CFD analyses results

Files included in this dataset contain transient records of the most important variables of results of 9 scenarios of Poznan Supercomputing and Networking Center testbed CFD analysis. Modeled testbed included server room equipped with two heterogeneously occupied racks (with each server modeled separately) and one roof-mounted cooling device. Setup was examined virtually for three servers power usage scenarios (50%, 75% and 100% of maximum value). For major part of active servers the power usage was changed respectively in each scenario, while some of them preserved daily-averaged values (inactive devices are also included). For each power usage level also three different air conditioning temperature setups (24, 27 and 30 Celsius degrees) were tested. The most relevant information about the model can be found below:   <ul> <li>server room dimensions along x, y and z axis (with one of the corners placed in the origin): (4.86, 4.00, 3.00) [m]</li> <li>racks dimensions: (0.6,1.18,2.1),(0.8,1.18,2.2) [m]</li> <li>racks position (translation from 0,0,0): (1.4,1.95,0), (2.08,1.95,0) [m]</li> <li>first rack equipment (position [-], size [-], airflow [m3/s], power usage (50%/75%/100% scenario) [W], flow orientation [-]): <ul> <li>0, plug, -, -/-/-, -,</li> <li>1, plug, -, -/-/-, -,</li> <li>2, 4U, 0.0, 0.0/0.0/0.0, y,</li> <li>6, 2U, 0.0, 0.0/0.0/0.0, y,</li> <li>9, plug, -, -/-/-, -,</li> <li>10, 2U, 0.05, 230/345/460, y,</li> <li>20, 2U, 0.025, 90/90/90, y,</li> <li>22, 2U, 0.05,  450/675/900, y,</li> <li>24, 4U, 0.12, 1000/1500/2000, y,</li> <li>28, 2U, 0.05,  230/345/460, y,</li> <li>30, 4U, 0.12, 1000/1500/2000, y,</li> <li>34, 2U, 0.05,  400/600/800, y,</li> <li>36, 2U, 0.05,  400/600/800, y,</li> </ul> </li> <li>second rack equipment (position [-], size [-], airflow [m3/s], power usage (50%/75%/100%  scenario) [W], flow orientation [-]): <ul> <li>0, 3U, 0.0, 0.0/0.0/0.0, y,</li> <li>3, 3U, 0.0, 0.0/0.0/0.0, y,</li> <li>6, plug, -, -/-/-, -,</li> <li>7, plug, -, -/-/-, -,</li> <li>8, 3U, 0.0, 0.0/0.0/0.0, y,</li> <li>11, 2U, 0.0, 0.0/0.0/0.0, y,</li> <li>13, 2U, 0.025, 69/69/69, x,</li> <li>15, 3U, 0.0/0.0/0.0, 0.0/0.0/0.0, y,</li> <li>18, 3U, 0.15, 1350/2025/2700, x,</li> <li>22, 2U, 0.05, 161/161/161, y,</li> <li>24, 2U, 0.025, 69/69/69, x,</li> <li>26, 2U, 0.0, 0.0/0.0/0.0, y,</li> <li>28, 2U, 0.025, 23/23/23, x,</li> <li>30, 2U, 0.05, 258.5/258.5/258.5, y,</li> <li>34, plug, -, -/-/-, -,</li> <li>35, plug, -, -/-/-, -,</li> <li>36, plug, -, -/-/-, -,</li> <li>37, plug, -, -/-/-, -,</li> <li>38, plug, -, -/-/-, -,</li> <li>40, plug, -, -/-/-, -,</li> <li>41, plug, -, -/-/-, -,</li> <li>air conditioner max. cooling capacity: 10 [kW]</li> <li>air conditioner airflow: 0.533 [m3/s]</li> <li>air conditioner inlet center: (3.76, 1.3, 3.0)</li> <li>air conditioner outlet center: (3.76, 2.8, 3.0)</li> <li>ventilation airflow: 0.0252 [m3/s]</li> <li>ventilation inlet center: (2.8125, 3.6475, 3.0)</li> <li>ventilation outlet center: (2.95, 0.605, 3.0)</li> </ul> </li> <li>domain cuboid cavities (start point, end point): <ul> <li>(0, 0, 3.0), (0.72, 4.1, 3.27),</li> <li>(0.32, 0, 3.27), (0.72, 3.78, 3.5)</li> </ul> </li> <li>domain cuboid obstacles (start point, end point): <ul> <li>(3.61, 0, 0), (4.86, 0.44, 1.89)</li> <li>(0.32, 3.78, 0), (0.72, 4.1, 3.0)</li> </ul> </li> </ul>   The dataset contains records of below variables: <ul> <li>temperature from four virtual probes placed at the same locations as real sensors in the testbed: <ul> <li>  (1.8, 2.12, 1.42) - close to inlet of a server from the first rack</li> <li>  (4.8, 1.65, 1.5) - close to air conditioner wall-mounted control panel</li> <li>  (2.5, 2.09, 0.95) - close to inlet of a server from the second rack</li> <li>  (2.8, 0.65, 0.75) - probe distanced from both racks and air conditioner, imitating "neutral" point</li> </ul> </li> <li>surface-averaged temperature at inlet of each server</li> <li>surface-averaged temperature at outlet of each server</li> <li>surface-averaged temperature at air conditioner inlet</li> <li>surface-averaged temperature at air conditioner outlet</li> </ul>

opencc-by-4.0Nov 2024View details →

pLMMoRF: A web server that accurately predicts membrane-interacting molecular recognition features by employing a protein language model

pLMMMoRF predictor scrips and MemMoRF prediction of the human proteome.

opencc-by-4.0Jan 2022View details →

Jupyter Notebooks for "Evaluating CephFS Performance vs. Cost on High-Density Commodity Disk Servers" 10.1007/s41781-021-00071-1

Jupyter notebooks used to create plots in article  DOI 10.1007/s41781-021-00071-1 Title "Evaluating CephFS Performance vs. Cost on High-Density Commodity Disk Servers" Journal "Computing and Software for Big Science"

opencc-by-4.0Aug 2022View details →

Supplementary Material for the paper "Editing Support for Software Languages: Implementation Practices in Language Server Protocols"

Supplementary material for the paper "Djonathan Barros; Sven Peldszus; Wesley K. G. Assunção; and Thorsten Berger. Editing Support for Software Languages: Implementation Practices in Language Server Protocols. In: 25th International Conference on Model Driven Engineering Languages and Systems (MODELS). 2022. ACM/IEEE."

opencc-by-4.0Mar 2024View details →

ChemoDOTS web server data files

This archive contains files related to the ChemoDOTS web server (https://chemodots.marseille.inserm.fr/) ChemoDOTS_list_of_chemical_functions.xlsx: List of chemical functions recognized by the ChemoDOTS web server and corresponding SMILES. ChemoDOTS_list_of_chemical_reactions.xlsx: List of chemical reactions rimplemented in the ChemoDOTS web server and corresponding SMARTS. ChemoDOTS_list_of_chemical_reactions_2024.pdf: List of chemical reactions implemented in the ChemoDOTS web server ChemoDOTS_list_of_chemical_reactions_by-functions_2024.pdf: List of chemical reactions implemented in the ChemoDOTS web server sorted by chemical functions. ChemoDOTS_MolPort_BBs.smi: Building Blocks from MolPort used in ChemoDOTS (version 2024-03-01) ChemoDOTS_Enamine_BBs.smi: Building Blocks from Enamine used in ChemoDOTS (version 2024-03-01)

opencc-by-4.0Feb 2023View details →

Data sets for "Updated MS²PIP web server supports cutting-edge proteomics applications"

Data sets and code used to train and evaluate new MS²PIP models.

opengpl-2.0-or-laterJun 2023View details →

OMERO Server BDV H5 Test Example

This is an example H5 file that loads and displays properly in BioFormats, but only loads into OMERO server. The OMERO server display does not work.

opencc-by-4.0Jul 2023View details →

Supplemental data for: Current ethics policies in 36 preprint servers

Preprints, which are non–peer-reviewed articles, offer a rapid dissemination of information, and have gained traction in academic publishing, often serving as the publishing precursors of peer-reviewed journals. Given that many peer-reviewed journals, with often strict ethics policies, allow the prior publication of papers as preprints, we were interested in appreciating the ethics policies in place in preprint servers. We selected 36 preprint servers from the ASAPbio list to base our assessment. We found that that only 8% of analyzed preprint servers contained a dedicated section on the server's ethics policy. As documents that purportedly transmit scientific information, including data-based evidence, we believe that there is a need to fortify the stringency of ethics policies in preprint servers, even standardize them across ASAPbio-listed preprint servers.