Editing Talk:2259: Networking Problems

<!--Please sign your posts with ~~~~ and don't delete this text. New comments should be added at the bottom.-->
I just had an issue the other day with copying disk images to a network drive using <code>smbclient</code> 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 <code>smbclient</code> must run on actual sorcery. [[User:Aaron Rotenberg|Aaron Rotenberg]] ([[User talk: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. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 00:36, 25 January 2020 (UTC)

:The original <code>smbclient</code> implementation turned out to be virtually impossible, so the programmers gave up and used <code>import_ai()</code>. Unfortunately they then used <code>ai_solve(network.problems,0,0)</code> 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. [[User:Cosmogoblin|Cosmogoblin]] ([[User talk: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? [[Special:Contributions/172.68.133.72|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. [[User:Curtobi4|Curtobi4]] ([[User talk:Curtobi4|talk]]) 18:44, 24 January 2020 (UTC)

Clearly seems related to 1457, albeit with much more advanced tech issues. --[[User:GoldNinja|GoldNinja]] ([[User talk: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.{{unsigned|108.162.241.32}}
:Yeah, the interactive part of the play/movie/comix. -- [[User:Hkmaly|Hkmaly]] ([[User talk: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. [[User:SteveBaker|SteveBaker]] ([[User talk: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? [[User:Blacksilver|Blacksilver]] ([[User talk: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. [[User:DevAudio|DevAudio]] ([[User talk: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 a 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 links unless there are some pathological conditions. If one of these connections is actually slower than the other, 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. -- [[Special:Contributions/162.158.23.109|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 [http://catb.org/jargon/html/story-of-mel.html The Story Of Mel] and [http://catb.org/jargon/html/magic-story.html A story about 'magic'] [[User:Blacksilver|Blacksilver]] ([[User talk:Blacksilver|talk]]) 12:28, 25 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. [[User:Rtanenbaum|Rtanenbaum]] ([[User talk: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. [[User:DevAudio|DevAudio]] ([[User talk: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.) [[User:DevAudio|DevAudio]] ([[User talk: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 {{w|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. [[User:Ianrbibtitlht|Ianrbibtitlht]] ([[User talk: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). --[[Special:Contributions/141.101.99.53|141.101.99.53]] 02:01, 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 [[User:OK-Randall|OK-Randall]] ([[User talk: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. [[User:Ianrbibtitlht|Ianrbibtitlht]] ([[User talk:Ianrbibtitlht|talk]]) 14:04, 26 January 2020 (UTC)
@@ Line 3: / Line 3: @@
 :Sounds like the explorer is able to create some sort of cache that the transfer is able to use but not create. -- [[User:Hkmaly|Hkmaly]] ([[User talk: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 <code>test.stuff</code>, but most other filenames didn't work. So I had to start a copy operation to <code>/mnt/xdrive/test.stuff</code>, refresh <code>/mnt/xdrive</code> in the GUI explorer so that the speed would jump up, wait for the copy to finish, then rename the file inside <code>/mnt/xdrive</code> to the name I actually wanted. [[User:Aaron Rotenberg|Aaron Rotenberg]] ([[User talk:Aaron Rotenberg|talk]]) 20:32, 27 January 2020 (UTC)
 :The original <code>smbclient</code> implementation turned out to be virtually impossible, so the programmers gave up and used <code>import_ai()</code>. Unfortunately they then used <code>ai_solve(network.problems,0,0)</code> 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. [[User:Cosmogoblin|Cosmogoblin]] ([[User talk:Cosmogoblin|talk]]) 09:39, 25 January 2020 (UTC)
@@ Line 24: / Line 22: @@
 :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. [[User:DevAudio|DevAudio]] ([[User talk: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. -- [[Special:Contributions/162.158.23.109|162.158.23.109]] 09:07, 27 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 a 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 links unless there are some pathological conditions. If one of these connections is actually slower than the other, 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. -- [[Special:Contributions/162.158.23.109|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 [http://catb.org/jargon/html/story-of-mel.html The Story Of Mel] and [http://catb.org/jargon/html/magic-story.html A story about 'magic'] [[User:Blacksilver|Blacksilver]] ([[User talk:Blacksilver|talk]]) 12:28, 25 January 2020 (UTC)
-: The effect of travel time over media is central to the plot in [https://en.wikipedia.org/wiki/The_Hummingbird_Project The Humming Bird Project]. It's also a key factor in high frequency trading, as [https://www.youtube.com/watch?time_continue=2&v=d8BcCLLX4N4&feature=emb_logo Tom Scott explains in his video].[[User:Vfp15|Vfp15]] ([[User talk: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. [[User:Rtanenbaum|Rtanenbaum]] ([[User talk:Rtanenbaum|talk]]) 22:52, 24 January 2020 (UTC)
@@ Line 40: / Line 36: @@
 Strictly speaking, I don't think lag is about how long transmission of a packet takes, which is instead referred to as {{w|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. [[User:Ianrbibtitlht|Ianrbibtitlht]] ([[User talk: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). --[[Special:Contributions/141.101.99.53|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. [[User:Ianrbibtitlht|Ianrbibtitlht]] ([[User talk: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 [[User:OK-Randall|OK-Randall]] ([[User talk: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. [[User:Ianrbibtitlht|Ianrbibtitlht]] ([[User talk:Ianrbibtitlht|talk]]) 14:04, 26 January 2020 (UTC)
-::Ah yes, I get it now, it's another example of Randall's ambiguous wording (after [https://www.explainxkcd.com/2258 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)".[[Special:Contributions/162.158.154.91|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 ;) [[Special:Contributions/141.101.69.79|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. [[User:Barmar|Barmar]] ([[User talk: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. [[Special:Contributions/172.69.62.28|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. [[User:Nitpicking|Nitpicking]] ([[User talk:Nitpicking|talk]]) 22:01, 10 September 2023 (UTC)