2259: Networking Problems

|< < Prev Comic #2259 (January 24, 2020) Next > >|

Networking Problems

Title text: LOOK, THE LATENCY FALLS EVERY TIME YOU CLAP YOUR HANDS AND SAY YOU BELIEVE

Explanation

Computer problems are frequent and can be difficult to solve ^{[citation needed]}. Networking problems in particular can puzzle even seasoned people and sometimes seem to have arbitrary issues causing them. Packets are units of data transfer used in computer networking, and one measure of network performance is lag, the amount of time it takes for data to travel from one point to another (and perhaps back); saying a packet's transmission is 'laggy' means it is unacceptably slow.

Lag in packet transmission and other network performance measures can appear quite random. Just to start with, your ISP may be engaged in traffic shaping, which can do very weird things indeed to your packets (making the first megabyte of a transfer faster than any other, for example); now imagine that your ISP's ISP (usually known as an "Upstream Provider") is engaged in something similar, and you begin to see the scale of the problem. Wireless latency can relate to things as unexpected as where people are standing, what they are touching, the weather, viruses and other system compromises, network activity by other unseen users, and so on. Because humans are wired to perceive patterns, they will find them even in random data, a fallacy that Cueball is probably suffering from here. He variously attributes the network behavior he sees to the packet number being even vs. odd, packet arrival time being before vs. after noon, and packet arrival day being today vs. yesterday. Such a pattern would make sense if it were merely "every other packet" regardless of odd or evenness, but that still leaves unexplained the other "patterns" Cueball is seeing.

These non-existent patterns that Cueball is 'finding' are driving him mad, so much so that he says he believes in ghosts now. The statement of belief in ghosts may be a reference to the intermittent or fluctuating nature of the network issues being caused by mischievous or malevolent spirits. Ghosts generally are not concerned with expressions of belief, but there are some religious traditions that include group clapping and chanting. Many works of fiction depict a future or alternate history where machines are worshiped as gods or spirits, such as the Adeptus Mechanicus of Warhammer 40,000. Some of this terminology can be found in present-day IT and other support personnel, including references to "daemons" and "black magic". Another possible reference Randall may be making is to the Ghost in the machine, a term describing AI. A third possibility is that Cueball's brain had stopped working, as Randall had suggested in his chart. it may also be a reference to 1316: Inexplicable, in which Megan concludes Cueball's computer is haunted.

The title text continues Cueball's maniacal attempts at self-assurance, with him alluding to J.M. Barrie's play Peter Pan by saying that latency falls every time you "CLAP YOUR HANDS AND SAY YOU BELIEVE". In the play, Peter Pan says, "If you believe in fairies, wave your handkerchiefs and clap your hands."^{[actual citation needed]} A more mundane explanation of the network behavior Cueball is experiencing might be that it is random but he's seeing a pattern anyway, or that there is a loose connection or trace and the vibration of clapping and speaking in the vicinity of the equipment in question closes the connection.

Similar superstition regarding computer devices was used previously in 1457: Feedback.

Transcript

[A chart is shown with one horizontal line with 13 ticks (the first larger) and ending in an arrow. There are three labels along the line, at the start in the middle an towards the end before the arrow. Below are two clouds in gray with labels. The first cloud is long and it is getting thinner towards the right. It goes between the first and second label above the chart. The second blob is smaller and of equal thickness and it goes from the last label towards right. Above the chart is a heading and a subheading:]

Types of Computer Problems

By how much debugging them makes your brain stop working

[The three labels above and the two in the clouds:]

None

Some

A lot

Normal problems

Networking problems

[Below the chart, only in the right part of the comic is a comic drawing. Cueball is kneeling before a rack of servers. One of the server blades is extended and connected by a cable to a laptop sitting on a box, which Cueball is using. Behind Cueball, there is a wireless router sitting on a stool, which is connected by a cable to another wireless router sitting on the floor, which is connected to another laptop. From behind him to the right an off-panel voice emanates from a starburst at the edge of the panel.]

Cueball: Before noon, odd-numbered packets were laggy, but after noon, even-numbered ones are! It's the opposite of yesterday!

Off-panel voice: Are you sure you're okay?

Cueball: I'm fine and I believe in ghosts now!

 add a comment! ⋅  add a topic (use sparingly)! ⋅  refresh comments!

Discussion

I just had an issue the other day with copying disk images to a network drive using smbclient on Linux Mint. The transfer would only run at 1 to 2 MB/s. Then I discovered that if I opened the mounted drive in the GUI file explorer and refreshed the directory where I was copying the image to, it would consistently cause the copy operation to jump to 40 to 60 MB/s and stay there for the rest of the operation. I concluded that smbclient must run on actual sorcery. Aaron Rotenberg (talk) 18:02, 24 January 2020 (UTC)

Sounds like the explorer is able to create some sort of cache that the transfer is able to use but not create. -- Hkmaly (talk) 00:36, 25 January 2020 (UTC)

I forgot to mention the part where this turned out to be filename dependent. I determined that the trick always worked if the filename on the destination network drive was test.stuff, but most other filenames didn't work. So I had to start a copy operation to /mnt/xdrive/test.stuff, refresh /mnt/xdrive in the GUI explorer so that the speed would jump up, wait for the copy to finish, then rename the file inside /mnt/xdrive to the name I actually wanted. Aaron Rotenberg (talk) 20:32, 27 January 2020 (UTC)

The original smbclient implementation turned out to be virtually impossible, so the programmers gave up and used import_ai(). Unfortunately they then used ai_solve(network.problems,0,0) to set the maliciousness and capriciousness variables to zero, but a combination of off-by-one and roll-over errors mean that these two variables are maximized. True story. Cosmogoblin (talk) 09:39, 25 January 2020 (UTC)

Yeah, can confirm that even the high end of 'normal computer problems' can result in belief in the occult and/or paranormal operation of computers. I now attempt to moderate my brainwaves into positive only flow to make sure I do not negatively effect the computer through quantum effects on the bits and operation. If i get frustrated or confused by the computer for an extended time, i put it down and walk away until I have more of a 'can do' attitude. Then of coarse there was that time that.... it may be too late for me, but there are puzzling computer problems to explore so I... remember me as I was. ~Litppunk 18:26, 24 January 2020 (UTC)

Yeah. Life changed, memory lost. Still trying to fix bugs. Are you available to connect over this? 172.68.133.72 22:04, 25 January 2020 (UTC)

"Ghosts generally are not concerned with expressions of belief, but there are some religious traditions that include group clapping and chanting." - I don't think the hover text is related to the ghosts. They seem just like two separate unbelievable things. "Perhaps the ghost in question is the Holy Ghost." - I doubt that is what he is referring to, especially since it is plural 'ghosts' and the Holy Ghost is singular. Curtobi4 (talk) 18:44, 24 January 2020 (UTC)

Clearly seems related to 1457, albeit with much more advanced tech issues. --GoldNinja (talk) 19:18, 24 January 2020 (UTC)

Clapping hands and saying you believe in fairys is how you prevent Tinkerbell from Dying when you watch Peter Pan. -- 108.162.241.32 (talk) (please sign your comments with ~~~~)

Yeah, the interactive part of the play/movie/comix. -- Hkmaly (talk) 00:36, 25 January 2020 (UTC)

Pareidolia (one of my least favorite words because I can't spell it well enough to google for the correct spelling) is a definite problem for the human brain - we habitually spot patterns where they don't exist. But the problem for software engineers is that spotting patterns that DO exist is how you find bugs. So distinguishing between real patterns and pareidolia ('i' before 'e' except after 'c'...and 'r'...sometimes...) is a vital part of the job. Clearly Cueball has that problem here. SteveBaker (talk) 20:48, 24 January 2020 (UTC)

I know it's hyperbole, but are there any actual networking problems that could cause every other packet to be laggy? Blacksilver (talk) 21:17, 24 January 2020 (UTC)

Nothing I can think of you'd ever do in a production setup on purpose, but with some really crazy port-channel settings, with the right kind of tiny packets like a SYN, and a downstream bridge or repeater to add in some intentional delay, I think you could. Never underestimate the power of a sufficiently motivated netadmin. DevAudio (talk) 22:55, 24 January 2020 (UTC)

Theoretically, yes. But it would require some malicious/stupid/buggy configuration. For example, some stupid packet scheduler on a misconfigured bonded link or having two same-metric routes to some destination that are not equal in fact. It may not even be an error in any local configuration, but a collective effect of multiple sub-optimal configurations or just a lack of knowledge of the whole picture of the network. In essence, if there are multiple connections leading to some destination, someone may want to utilize them all to 'sum' the bandwidth of them. A network device would then 'share' traffic between those multiple (in Cueball's case: two) connections, mostly sending every N-th packet on any particular connection. Normally there won't be ideal division of packets to connections unless there are some pathological conditions. If one of these connections is actually slower than the others, this could generate the effect seen by Cueball. The network administrator may not be aware of the asymmetry - the links connected directly to his device may be in fact identical, but the slowness can be induced somewhere along the path by a device not under his control. Similarly, Cueball, even if very competent, may not be aware that some device not under his control along the path uses such configuration and causes unintentional delays in (mostly) every other packet. -- 162.158.23.109 09:07, 27 January 2020 (UTC)

The classic 500-mile bug: "We can't send mail more than 500 miles" http://web.mit.edu/jemorris/humor/500-miles

I'm legally required to link The Story Of Mel and A story about 'magic' Blacksilver (talk) 12:28, 25 January 2020 (UTC)

The effect of travel time over media is central to the plot in The Humming Bird Project. It's also a key factor in high frequency trading, as Tom Scott explains in his video.Vfp15 (talk) 14:29, 27 January 2020 (UTC)

While I don't believe that ghosts have power over computers, I do believe that many of the seemingly random "hiccups" in my computer programs are caused by sunspots. Rtanenbaum (talk) 22:52, 24 January 2020 (UTC)

Disagree strongly that this has anything to do with seeing patterns where they don't exist. Modern network troubleshooting tools will show you exactly the order that packets were received, and the time they were received at. Although it would be hard to induce the problem described, if it were induced, you could indeed see it quite clearly and objectively in a packet capture. This comic is more about some of the brain-breakingly twisted ways networking can go awry and all the impossible things it can make you want to believe in the quest to make sense of what we are seeing. DevAudio (talk) 23:02, 24 January 2020 (UTC)

I will correct myself slightly - it would seem from the mouseover text that he is finding a false pattern, but it's not impossible for what he said to be true, it would just require laboratory conditions and someone playing a prank. He could also be seeing a real pattern with some kind of crazy cause involving a sound transducer and either EMI or some intentional sabotage. Yeah, that's waaaay off in left field, but so is the network data Cueball may be actually be seeing. On the whole, I would not fight someone who chose to believe Cueball is seeing a false pattern with the clapping. It's a reasonable interpretation for anyone who hasn't seen the insane things I have when troubleshooting networks. I HAVE seen ghost packets. (It was a weird glitch causing a switch to replay packets from hosts that weren't even connected anymore, not actual paranormal activity.) DevAudio (talk) 23:34, 24 January 2020 (UTC)

Strictly speaking, I don't think lag is about how long transmission of a packet takes, which is instead referred to as network delay. Furthermore, from the referenced Wikipedia page, network delay is experienced in each "hop" of the data packet from node to node and includes the following delays: processing delay (time to process the packet header), queuing delay (time packet spends in routing queue), transmission delay (time to push the packet onto the link), and propagation delay (time to travel to destination based on the speed of the link). IMHO, a laggy network connection is one where the network delay is longer than normal due to a temporary problem in one or more of these areas. A connection that is always slow because of low link bandwidth is not laggy, it's just slow. Others may disagree with me. Ianrbibtitlht (talk) 03:02, 25 January 2020 (UTC)

Lag is an application-layer concept (being the time from a user doing something to trigger an action to when the effects of that action start to be observed). The network-layer equivalent is latency and it is one of the fundamental limits on what you can do with remote resources (and the one that is very hard to do anything about, unlike bandwidth where you can just get more by spending money). --141.101.99.53 02:01, 27 January 2020 (UTC)

I don't disagree with anything you stated. However, in this instance, Randall's use of the word "laggy" is clearly not related to bandwidth because the odd and even packets are not seeing the same latency. This suggests the "laggy" packet transfers are suffering due to something else that is related to one of the other three causes of latency in my original comment. Ianrbibtitlht (talk) 13:25, 27 January 2020 (UTC)

Hi. Isn't Randall using the scale in the wrong direction? I mean "normal problems" make your brain stop working if you debug them "none" to "some" while "Networking problems" only make your brain stop working if you debug them "a lot". If I am wrong. In what way should I read the axis? thx OK-Randall (talk) 09:44, 26 January 2020 (UTC)

It's not a measure of "how much debugging" causes your brain to stop working, but instead is a measure of "how much your brain stops working" when debugging them. Ianrbibtitlht (talk) 14:04, 26 January 2020 (UTC)

Ah yes, I get it now, it's another example of Randall's ambiguous wording (after someone who knows Jupiter is within earshot). I initially read it as "(how much debugging them) (makes your brain stop working)", whereas Randall probably meant "(how much) (debugging them makes your brain stop working)".162.158.154.91 13:07, 27 January 2020 (UTC)

Same here, and also after reading your replies - i still don't really get my head around the intended axis. But thankfully i am not alone ;) 141.101.69.79 18:13, 27 January 2020 (UTC)

It really should have been done as a bar chart. The measurement is how much your brain stops working. There would then be bars for different types of problems. Barmar (talk) 19:29, 27 January 2020 (UTC)

I was having some bad problems with my wifi a little while back. Would be super slow randomly. I taped a piece of alumium foil to the wall behind my computer and it fixed it. 172.69.62.28 15:47, 7 February 2020 (UTC)

i placed an edit with improper capitalization referring to the ghosts. no-one altered it. "edited mercilessly"

The Ghost in the Machine is a reference to philosopher Gerarld Ryle's phrase and Arthur Koestler's book of that name. It describes the presence of the soul in the "machine" of a human body (which both Ryle and Kestler deny), and has nothing to do with AI. Nitpicking (talk) 22:01, 10 September 2023 (UTC)