Introduction: The Network or The Equipment

Scope / Outline:

  1. Introduction: The Network or The Equipment

  2. Key terms

  3. Troubleshooting Theory

  4. Pseudo-code

  5. Network Testing by Gathering Data

  6. Sub-Modules Compared, Foot-printing HOST Machines.

  7. Central Processing Unit

  8. RAM

  9. O.S.

  10. Router

  11. NIC

  12. NIC firmware and drivers

  13. Conclusions and Lessons Learned

X. Illustrations, Graphs, Etc.

XII. Discarded Edits, Further Blogs, Incubation XIII. Uniform Resource Locators

XIV. Questions

Introduction AND Scope

The purpose of this blog post is to further my tactical skill-set development, and upon successful completion will serve as proof that I have gained the skills needed to effectively troubleshoot, find, and fix problems within a simple residential network: its access point, and host machines. In a broader sense, the goal is to demonstrate that these skills can be fielded in a serviceable environment, mainly that my company Kornrumpf Technology can provide its primary economic service of “trouble-shooting and optimizing residential networks.” This troubleshooting and optimization will follow two potential lines, the first being within Wireless LAN networks and their endpoints, the second being within the wired ethernet protocol and its associated endpoints.

As a more theoretical proof of competence, this blog post seeks to demonstrate and understand fundamental computer processing network theories of operation and their associated problems - using various tools & utilities for measurements and exposition. The primary model being referenced is the OSI model, and I will attempt to structure my understanding of it as a guide for identify processing and throughput errors. This proof hopes to be open to and supported by conclusive peer and mentor review based on repeatable data – and these solutions once understood and documented will act as a body of knowledge and evidence to support future troubleshooting and optimizing of residential networks. With that, let us begin our troubleshooting with our Wireless LAN and end-point scenario. Our client calls because of poor network speeds … it is from this point that we begin to gather data and ask questions which will lead us to our final determination, namely who or what is to blame for the error? It is in the spirit of that question which, this article is titled that we begin: ‘Is this problem a network failure or on the clients host equipment?’

Key Terms

Note: This index is NOT comprehensive, and after concluding on the error – I will attempt to highlight the most important terms.

1. Signal Bandwidth, band-width – The range of consecutive frequencies. Bandwidths exist in the context of both signal processing and network computing. Where the ‘given’ path is the signal frequency bandwidth and the maximum data rate is the network bandwidth capacity.

1a. Downstream Channels - The signal bandwidth frequencies are separated into 6 MHz bandwidths over which binary data is downloaded to endpoints.

1b. Upstream Channels - The signal bandwidth frequencies are separated into 6 MHz bandwidth over which binary data is uploaded to end-points.

2. Network Bandwidth Capacity,

This term is a measurement of link throughput, and results can be found using remote Speed Test servers. This capacity is affected by WAN ISP provisioning and limitation.

3. Network Latency,

This term is tied to measurement of the delays experienced by a single packet traveling through a network link, between host and server. For example, The Network Bandwidth Capacity may be clocked at 200 Mbps / 10 Mbps but the latency of each path in the link can cause delays in the resource being given to the end user.

4. Jitter,

This is a comparative test between multiple packets. Whereas latency is a measurement of a single packet, jitter will compare the intended packet sequence with what is received. For example, the host sends 3 ICPM Packets to a server using ping. Each packet will have a slightly different initiation-response travel time, and packet A and C both route in 10 MS, but packet B routes in 100 MS, this indicates a problem.

5. Central Processing Unit,

This module carries out three primary operations: fetching - which is to receive instruction from memory, decoding – is the conversion of these instructions into machine language, and executing – which is the transmission of decoded instructions to other components in the system.

6. Random Access Memory – This hardware temporarily stores and transmits programed instructions from applications and programs. The quality of this component is measured by how much binary state data it can store, and how quickly the data can be read by or written to the machine's processors.

7. Operating System, a programed abstraction layer which manages the I/O processors of all system hardware components.

8. Router,

A fundamental networking machine responsible for routing fully formed packets across networks of variable sizes.

9. Network Interface Controller,

Operating at a lower-level in comparison to a router – this packet encoding, and decoding component transmits I/O data to and from an external host – in combination with built-in drivers, their associated firmware, the host machines operating system, and processor.

10. Pseudo-code,

English-like syntax that represents a programming language, using concepts such as – functions (verbs, actions, specific steps), conditions (branches, forks-in-the-road), Boolean expressions (a question with a yes or no, true / false, 1 / 0), and loops.

Troubleshooting Theory

Troubleshooting any system is rooted in a remarkably simple statement: ‘this does not work.’ But with computers and their networks, this comes with several layers of encapsulation and interconnected modules, each of which demands clearly defined boundaries, and purposes. From there, finding and fixing what does not work requires a systemic series of steps intended to isolate, identify and ‘make it work’. Troubleshooting is fundamentally a scientific methodology, which means – to observe the system state, propose an initial root cause, design an environment in which this first cause can be tested and measured, and then determine if your theory or thesis was true. In keeping with the nature of computer science, we will begin with a logical attempt to “observe the system state” using pseudo-code. Rather than simply stating the system is not working, it will start to introduce some variables for measurement and experiment purposes. As Mark Zuckerberg says, “if you can’t measure it – it can’t be improved.” Beyond that – we are going to use some other tools to effectively communicate our thesis and results. These conclusions will contribute to further observation, and an understanding of fundamental computer science abstractions such as the OSI Model.

Module 3A. Pseudo-code

The Sub-heading titled: X. Charts, Screenshots, Illustrations, Graphs, Etc. contains shows a few examples of attempted pseudo-code. While I have attempted to encoded functions in blue, conditions in orange, Boolean expressions in green, and loops in brown, this system has not found its way into a living language understood by a complier yet, and therefore is NOT executable. However, the why or purpose of the code, is this - each is attempting to: identify and declare the state of the computer-systems' modules , test their variable working percentage-capacity ( // NOTE: this can be understood as data or information gathering) – and then it proposes a solution through either an exchange or repair of the module, finalized by a loopback with another test of the working percentage.

These codes are elaborated AND explored further in a future blog post - and game.

Module 3B. Network Testing by Gathering Data

Using the pseudo-code as our guide, we must define what a non-functioning module looks like. This code is extremely sensitive, requiring a 100% operating efficiency, but let us begin by gathering data to determine if that fact is true or false. The most accessible means of doing this testing is using a pre-programmed GUI that will demonstrate the problem – this can be accomplish either online using Ookla AND navigating to the test OR through their desktop application, which is said to have better accuracy AND perhaps to be more efficient.

// NOTE : For the data to be homogenous the test-server should be the same throughout, and a balanced time throughout the day.

As you can see, in the image below, that there is clear visual evidence that Module A is functioning improperly or according to our pseudo-code ‘If (Module A < 100 %) {swap Sub-Module A1). Next, we need to go into detail about these Sub-Modules, and their operating efficiency. That is the next portion of our code, which requires a loopback. The module elaboration and enumeration for this test host can be found in the illustrations heading as well. The sub-module section next will also elaborate.

Stock-image of speed test results.

Sub-Modules Compared, Theory & Foot-printing HOST Machines.

// NOTE: The Sub-modules order by precedency and assumed dependencies, but that is up for debate.

// NOTE: The exploration of these modules has been reduced for brevity after the root-problem was identified to be the NIC.

// NOTE: A previously well defined table failed to import, and the enumeration would risk the users machine integrity.

Module 4A. Processor Point of View

Like the firmware, programming a processor is beyond my current skill set, and though these modules can be upgraded as well, laptops are much less accessible to upgrade due to their design. Based on results from activity monitoring, the processor is the least likely problem associated with throughput, however – it does make sense, that in an administrated environment, a remote server could much more quickly processed and transmitted the payload of information – ahead of the host machine requesting the information, effectively creating bottlenecks.

Note: The most advanced means of communicating with the processor is going to be via the use of a complier, however – my experience has limited me mostly to command prompts. I’ve inserted a brief video where a command prompt is next to the .NET editor for comparison. Both appears to be consoles, but with vastly different capacities. It appears the .NET editor gives a more fundamental point of view to the processor, but that the command prompt gives more ability to monitor and test the system.

Module 4B. Random Access Memory Point of View

In the process of testing for network throughput, I have also determined that this machine has quite a small amount of memory installed, and so it is common for the activity monitor tool to show a high amount of memory pressure. However, by installing a smaller OS, we can reduce some of the Wired-system memory, additionally testing some memory monitoring software may prove useful. Memory Cleaner also provides a percentage view of current memory usage, easily visible from the tray, with the ability to [Cleanup] unused processes.

A final optimization involves the browser application, where one such as Opera offers the smallest memory demands, in fact – much smaller than default browsers such as Chrome! Further details about the internals of Machine can be found in the [About this Mac] tab.

Module 4C. Operating System Point of View

While it is unknown to what degree the OS, much like firmware, and memory – will affect network throughputs – it is already observed that different Operating Systems have different system requirements to function.

Module 4D. Router Point of View

After updating to MacOS 10.14.16 and re-running the network test – the results continue to remain below 100 Mbps. We are going to purchase an external NIC, the Foktech dual band wireless adapter. Unfortunately, this new Ext adapter still is not showing my full throughput… though there were moments that showed over 150 Mbps and on top of the proxy-type error, there is now a socket-type error. It is possible that over-crowded channels and an incorrect broadcast mode from the router which limits bandwidth?

I did discover that the default broadcast mode for the router is 802.11ac, with options for 802.11n, and a combination of 802.11 n & 802.11 ac. Though this could be inaccurate because even after a restart the AP did not dump all configurations. (configuration path: | Admin console | Wireless) For some reason my built-in NIC is not working properly? Once again, the NIC card throttles bandwidth up-to 150 and back down. I am attempting to collect historical data in Ookla. The network also appears good on the second and third test devices. Note: There is a lack of uniformity in the test servers being pulled off. In fact, I have seen downloads as high as 200 Mbps, but a subsequent failed upload.

Module 4E. NIC Point of View

// NOTE: While in summary, the built-in NIC was Identified as the source of the network speed problem, the lessons learned from exploring each module remain valuable.

The primary means for analyzing the network link will be to by using Ookla Speed Testing (Image 5A1-1 and 5A1-2). The card itself supports the 802.11 a,b,g modes – and when functioning properly this 802.11 Wi-Fi standard - “Approved in 2009, (and is describes as) Wi-Fi 4th Generation enables speeds of 300 Mbps.” However, 4b-1 show results that prove Module A is NOT functioning properly. Further tests using the same network, but a different host also serve to prove that the issue is in fact NOT the network link. However, this is the limit of my diagnostic ability of Module A1.

A secondary test, and a potential tool – pending further elaboration, is to ping the internal loopback address at, using the terminal window. A failure of this would indicate that card itself is non-functioning, but it provides little insight on the quality of the link. Again, we need the results from Ookla, is prove that the external throughput is only working at a 30% operating capacity. See Illustration.

Knowing that the NIC is working in a limited capacity, the next step is to swap the module. I have purchased a Forkteck External USB Wi-Fi Adapter, which supports multiple 802.11 PHY modes. This includes modes: a / ac / b / g / n. Directly from the manufacture, this device is plug-and-play, with little adjustment requires, but after an initial test the card continued to fail throughput. From here, I was necessary to review some of the internal router settings, at the router's loopback address After adjusting the 5 GHz bandwidth broadcast mode to PHY mode ac... SUCCESS - the provisioned throughput from the ISP worked!

Module 4Ei. NIC Firmware AND Driver Point of View

While this will play a role in further software development, my knowledge on this topic is limited, and I would have no capacity to troubleshoot this - beyond updating the modules to their latest version.

Conclusions and Lessons Learned

The conclusion of this paper and testing has been to show through external NIC card testing the root problem to be somewhere in the built-in NIC Module. Further The resolution to poor network performance was to replace the current Wi-Fi card with an updated 802.11 card, and to change the broadcast mode of the WAP. However, from a business administrative point of view - I would have no further methods for testing or repairing this failing component, which was causing users to experience multiple dropped URL requests, and slow web-page load response time. However, I have failed to draw many 1-to-1 relationships between the OSI Models and this particular network problem, but – I can condense that the errors are limited to the physical and data-link layers alone. There is a further issue of data security and resource stability that I need to explore AND will continue to in further posts.

// NOTE: Some modules have been removed and are pending further elaboration and development.

X Charts, Screenshots, Illustrations, Graphs, Etc.

Code Snippet 4a-1

// NOTE: The swap function will be executed if the specified condition is true. i.e., Module A, B, C, etc. is > 100 %.

// NOTE: Modules / Procedures / Methods and it accomplished something - are functions in themselves, each programming language has (sequence structures, repeat (loops) until conditions, selection structure (paths).

Example 1:

If (Module A [1,2,3,4,5,6,7,8] is NOT functioning) 
// [This statement is also a Boolean expression – where functioning or not functioning is the binary state ] 
Then {swap Module B [1,2,3,4,5,6,7,8]} 
//NOTE: Example 1 is missing a loop. 

Example 2:

If (Module A is < 100 %) 
Then {swap Module B}  

Example 3:

If (Module A is < 100 %) 
then {swap Module A1, A2, A3, A4, A5, A6, A7, A8}   

Example 4

If Mod A < 100  
Then {swap Sub-Mod A1} 
Test network speeds on domain @ standard server and time 
Loop-back to line one? 
If Mod A = 100  
Then STOP 

Example 5

If Mod A < 100  
Then [Console.WriteLine(“Andrew, Sub-Mod A1 has been inserted in place of Mod A””;] 
Test network speeds on domain @ standard server and time 
Loop-back to line one? 
If Mod A = 100  
Then STOP 

Example 5a

If Mod A < 100  
Then {swap Sub-Mod A1} 
Test network speeds on domain @ standard server and time 
Loop-back to line one? 
If Mod A = 100  
Then STOP 

XII. Uniform Resources Locators











11. the-skills-development-index-white-paper-global-knowledge-us-en.pdf




a. Where does signal bandwidth meet the maximum rate of data transfer across a given path?

b. Why then is my surfing experience characterized by dropped information requests: broken link, missing images, prompts to change to slower view? There are many other factors which add “considerable overhead.

c. How does a Browser request webpage?

d. Where does each user tool operate in a developer stack?


f. How to overcome the limitations of pseudo-code? In particular, the little interaction with the processor or a language. Though some of the utilities and tools that will be used have their own code which may be integrated later g. How many OS can one machine hold? ( h. Interesting thought: How do bind both adapters together? (Re-integrate #RN and Then Review Learning Commons for research assistance)

i. What is causing so many dropped request, even with a full throughput, low ping, and low jitter?

j. At what point does a voltage become a packet?

4 views0 comments

Recent Posts

See All

Exploring Hardware Design 0.0

Louisville KY, 2020. Getting ‘Back to the drawing board’ exists as a proverbial English idiom for failure, but more than that it’s carries the idea of hope, of new ideas, new creation - in the capital