This thesis investigates different methods that can be used for analyzing network performance and,ultimately, can be used for measuring the convergence time of ring coupled networks. As of today,many networks are often run with extra links, serving as backup links in case any that of the mainlinks would go down. To operate networks with backup links in layer 2 and layer 3, specific re-routing protocols such as RIP and OSPF are used in order to calculate a feasible path through anetwork when a network state changes. Depending on different implementations of the protocolsand the hardware used, the convergence times can vary substantially, which means measuring thenetwork performance is a very important part when developing a network solution. To executenetwork tests, a packet engine suite is used consisting of a network traffic generator that is used forcreating a packet stream, as well as a traffic receiver that fetches the packets sent. Various types ofengines can be used including Linux based, real-time operating systems based and bare-metal basedsolutions. From these different types of engines, a few tools are chosen and investigated on differentproperties including performance and usability. It was found that Tshark (Linux, RT-Linux based),USPI (Raspberry Pi bare metal), FreeRTOS (Raspberry Pi based), Arduino and PKTgen (Linuxkernel based) were the most suitable approaches to be used for testing. The test parameters includetesting the gaps between packets, maximum jitter, average jitter and packets sent per second. Thesetests revealed that an IXIA solution was slightly more accurate when used as a receiving end sinceit produced less jitter, however this difference could only be noticed in a micro second range. Itwas also revealed that it produced slightly less jitter than the other packet generators, also here onlynoticeable in a microsecond range. Thus it can be concluded that IXIA is not much superior any ofthe close to hardware solutions. The executed network tests revealed that the Westermo developedlayer 2 protocol FRNT generated less network convergence time and less packet losses than thecommonly used RSTP protocol. Similar tests against the layer 3 protocols revealed that RIP wasmuch faster than OSPF and it also lost less packets. Finally it is concluded that there is no needto buy an expensive network testing suite to test the convergence time of a network. Instead, anetwork testing suite can be developed with minimal funding.

The goal of this thesis is to develop a new, fast, adaptive load flow algorithm that "automatically alternates" numerical methods including Newton-Raphson method, Gauss-Seidel method and Gauss method for a load flow run to achieve less run time. Unlike the proposed method, the traditional load flow analysis uses only one numerical method at a time. This adaptive algorithm performs all the computation for finding the bus voltage angles and magnitudes, real and reactive powers for the given generation and load values, while keeping track of the proximity to convergence of a solution. This work focuses on finding the algorithm that uses multiple numerical techniques, rather than investigating programming techniques and programming languages. The convergence time is compared with those from using each of the numerical techniques. The proposed method is implemented on the IEEE 39-bus system with different contingencies and the solutions obtained are verified with PowerWorld Simulator, a commercial software for load flow analysis.

This study investigates unconditional convergence of Turkish regions and provinces. A recently introduced time series procedure developed by Nahar and Inder (2002) is used to test the convergence hypothesis for the period 1975-2001. Both the Ordinary Least Square and the Seemingly Unrelated Regression techniques are applied to analyze convergence of sixty five provinces, seven geographical regions as well as 12 NUTS - 1 regions of Turkey. The empirical findings indicate that most of the cases yield no evidence of convergence, which is a general result stated by the other studies in the literature regarding Turkey.

No / People, systems, and things in the cities generate large amount of data which is considered to be the most scalable asset of any smart city. Linux users are rapidly increased in last few years, and many large multinational organizations are deploying long distance high bandwidth (LDHB) cloud networks for centralizing the data from various smart cities on a central location. TCP is responsible for reliable communication of data in these cloud networks. For reliability communication among various smart cities, a number of TCP congestion control mechanisms have been developed in the past. TCP Compound, TCP Fusion, and TCP CUBIC are the default TCP congestion control mechanisms for Microsoft Windows, Sun Solaris, and Linux operating systems respectively. The response function of TCP CUBIC is higher than the response function of Standard TCP, which is a trademark congestion control mechanism. As a result, TCP CUBIC does not behave friendly with Standard TCP in LDHB cloud networks. The Congestion Window (cwnd) reduction and growth of TCP CUBIC is very aggressive, which causes high packet loss rate and unfair share of available link bandwidth among competing flows from various smart cities. The aim of this research is to design a new TCP congestion control mechanism for Linux operating system to achieve maximum performance in LDHB cloud networks being used by smart cities. In this paper, congestion control module for slow start (CCM-SS) is designed by increasing the lower boundary limit of cwnd size in slow start phase of communication. Congestion control module for loss event (CCM-LE) is designed by increasing the cwnd reduction rate at each packet loss event and finally Advance Response Function for TCP CUBIC (ARFC) is proposed to design a new congestion control mechanism for Linux operating system. NS-2 is used to compare the performance of TCP CUBIC* with TCP CUBIC in short distance high bandwidth (SDHB) and long distance high bandwidth (LDHB) cloud networks. Results show that TCP CUBIC* has outperformed in LDHB networks, at least by a factor of 18% as compared to TCP CUBIC.