Characterisation of busy-hour traffic of IP networks based on their intrinsic features

Characterisation of busy-hour traffic of IP networks based on their intrinsic features is a scientific paper that discusses the use of statistical techniques to model the behaviour of busy-hour traffic, especially to give network designers and architects grounded data on how to plan for a network based on the critical measure of peak network use. The main experiment conducted for this paper consisted of observational traffic analysis, with the data rate measured during busy hours. The solution explored an architecture that consisted of an initial stage for data cleaning followed by statistical regression. This latter step was modelled to find the relationship between two variables: number of users (predictor variable) vs traffic volume (target variable). These two variables are analysed to check whether there is a real relationship between them regardless of physical location or link capacity. It eventually came to light that the analysed traffic, which stemmed from a number of educational institutions and local networks, follows a White Gaussian Process, meaning that data us uncorrelated, comprising of random and independent fluctuations. What also entails from this observation is that the samples of traffic distribution follow a normal (bell-shaped) curve. Whereas a normal process would reveal that traffic in the real world would be coloured, with clearly defined correlations, a White Gaussian process indicates the presence of noise, meaning that the variables are unrelated due to presence of noise. A White Gaussian Process can also make for a simplified thought process which relies on simple math to predict probabilities of the network being overwhelmed, like predicting the network throughput in conrete numbers e.g.: gbps where the traffic rate becomes throtelled. Lastly, it has been concluded that the relationship between user population and traffic use can be modelled by the ANOVA and ANCOVA analytical techniques. The former stands for analysis of variance, which consists of a test to check whether the means of distinct groups are significantly different. The latter technique handles covariance, which couples ANOVA with regression, detailing how a dependent variable changes according to a determining factor while controlling for another factor. The use of tThese two techniques were arrived at through Goodness-of-fit tests, namely, tools to confirm that the traffic variation was mlinked to the number of users. Ultimately, the authors were able to fit the model to a linear regression analysis, derivating the formula for traffic: (traffic per user) x (number of users) + error term.

Article spotlight: "A Packet-level Characterization of Network Traffic"

"A Packet-level Characterization of Network Traffic" is a scientific paper published by by Alberto Dainotti, Antonio Pescape, and Giorgio Ventre. In this paper, an alternate approach to network characterisation is proposed at the packet level, thus leveraging the overall structure of the network packet, which tends to remain largely the same, thus providing an opportunity to come up with an agnostic framework for network analysis even if there are eventual changes in network protocol technologies. Relying on the packet structure means that this approach moves away from solutions centred around a simple network application such as FTP, SMTP, DNS etc. The network traffic analysis relies only on 2 metrics: packet size and Inter-Packet Time. With information from 2 major educational institutions, over a billion packets and million client server pairs in addition to SMTP and HTTP traffic, the research concerned with spatial and time invariance, that is, whether traffic patterns remained largely the same for different time slices (days, weeks, months etc) and at different locations. With packet-level analyses useful for traffic simulation and congestion analysis, the findings allow for planned network capacity regarding traffic rates, bandwidth, latency and packet loss. The distributional patterns found in the paper allow for traffic simulation to be generated, thus allowing for further future studies in the field of jitter, packet loss and delay. Moreover, this study allowed to discover the use of http port 80 to run p2p traffic, thus revealing the capacity for security diagnosis at the packet level. The architectural pipeline of the proposed solution starts with the reading of packet capture from 2 major network links, which then proceed to be filtered into either SMTP or HTTP traffic, with IP address scrambling taking place for privacy purposes. Unwanted traffic is filtered out, leaving only the data that is useful for the traffic analysis appropriate for the analysis of HTTP and SMTP patterns, thus allowing for the modelling of statistical models using packet size and inter-packet time, demonstrating space and time invariance across different situations and paving the way for model reuse on the strength of packet structure remaining independent of future protocol implementations.

Ein Hinblick in der Zukunft

Mit ihrer Absegnung, ich darf mich einen wenigen Dampf ablassen. Ich werde viel zu viel erledigen, währendessen die derzeitige Umstände mich nicht zurückblicken. Es hat sich nachgewiesen, dass Erfolg und Leistungen sind vorübergehend. Nur Anstrengung. Meine Fähigkeiten gelten allgemeinen nur für die nächste Herausforderung. Und dann kommt es wieder zurück. Meine Bemühung muss sich mit dem nächsten Ziel befassen. Nachgewiesen is dass Erfolgreiche Händlungen gibt es nicht; man geht immer noch zu seiner eigenen Angelegenheiten zurück.

CUDA cluster

Einige Funktionen der Maschine des Institute for Computational and Mathematical Engineering (ICME) der Stanford University. Controller · 2 x Intel® Xeon® X5650 2.66GHz 12MB Cache Hexa-core Processor · 48GB DDR3 1333 REG ECC 12 x 4GB Sticks · 8 x Hitachi 3TB Ultrastar 7K3000 7200 RPM 64MB Cache SATA ... Nodes (currently 13 nodes running) · 2 x Intel Xeon DP E5645 2.40GHz 12MB Cache Hexa-core Processor's. · 48GB DDR3 1333 REG ECC Memory 12 x 4GB Sticks · 1 x 1TB Seagate SATA3 6Gb/s 7200RPM 64MB Cache 2.5 Inch Disk Drive · 1 x ConnectX-2® InfiniBand adapter card, single-port, QDR 40Gb/s,Gen2 · Seven NVIDIA FERMI-BASED C2070 GPU’s per node each with 448 CUDA cores, 6 GB memory Die Architektur aus Controller und 13 Verarbeitungsknoten entspricht der eines Clusters, da es sich bei den Komponenten offensichtlich um marktübliche Komponenten handelt.

CUDA

Cuda ist eine parallele Computertechnologie, die die Verwendung von Hunderten oder Tausenden von Kernen (CUDAs) auf einem einzigen Prozessor ermöglicht. Beim Programmieren mit CUDA geht es um das Schreiben von Kerneln, also Funktionen, die parallel von mehreren Threads auf einer GPU ausgeführt werden. In Cuda programming, a function declared with __global__ is executed on the device (GPU).It can only be called from the host (CPU) code. This means your main C/C++ application running on the CPU launches these kernel functions to perform computations on the GPU. CUDA und MPI sind beides Programmiersprachen für die parallele Programmierung, aber CUDA ist spezifisch für die Programmierung auf GPUs, während MPI für die Interprozesskommunikation in verteilten Systemen verwendet wird. Grafikkarten, die die GPGPU-Technologie (z. B. CUDA, OpenCL) unterstützen, bieten nicht nur hochwertige visuelle Effekte in Spielen und Multimedia-Anwendungen, sondern ermöglichen auch erhebliche Leistungssteigerungen in Anwendungen, die eine große Anzahl einfacher und sich wiederholender Berechnungen durchführen.

IBM M Technology

IBM M Technology, also known as M technology or z/Architecture or Mainframe Technology, is ibm's mainframe computing platform. Cisc-based, it can handle massive amounts of workload and is used for critical applications such as banking systems. Unlike risc unix and ibm's aix, which use a risc-based processor, m technology makes use exclusisvely of a cisc-based processor, tailored for resilience and high throughput

Swagger

Swagger is a suite of tools for API developers from SmartBear Software and a former specification upon which the OpenAPI Specification is based for designing, building, documenting, and consuming RESTful APIs. The specification itself is now called OpenAPI Specification (OAS). Swagger's open-source tooling usage can be broken up into different use cases: development, interaction with APIs, and documentation. Swagger is specifically for REST APIs, not for SOAP or GraphQL. It maps HTTP methods (GET, POST, PUT, DELETE) to API resources. https://en.wikipedia.org/wiki/Swagger_(software)