Forums
New posts
Articles
Product Reviews
Policies
FAQ
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Menu
Log in
Register
Install the app
Install
Forums
Apple Computing Products:
macOS - Operating System
Packet Loss only on Mac
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Raz0rEdge" data-source="post: 1877321" data-attributes="member: 110816"><p>The sequence number indicating each ping packet that is sent out and a response shows up with the time and a lack of one indicates that's it's a missed packet, that's how the tool calculates the percentage packet loss.</p><p></p><p>So it's just an ever increasing number.</p><p></p><p>The DNS only comes into play if you were to ping a location by name, i.e., "ping google.com" means that a lookup has to happen to resolve google.com to some IP address and then the ping tool hits that IP address continually until you stop it. Changing the DNS just determine how quickly our resolve the name to the IP address, but has no impact on the actual ping functionality.</p><p></p><p>I'm on a VPN for my work as well and I can ping 1.1.1.1 with no packet loss. However, if I ping flood "sudo ping -f 1.1.1.1", I start seeing some packet loss like the following:</p><p>[CODE]</p><p>sudo ping -f 1.1.1.1</p><p>Password:</p><p>PING 1.1.1.1 (1.1.1.1): 56 data bytes</p><p>..Request timeout for icmp_seq 0</p><p>.Request timeout for icmp_seq 1</p><p>.Request timeout for icmp_seq 2</p><p>.Request timeout for icmp_seq 3</p><p>.Request timeout for icmp_seq 4</p><p>.Request timeout for icmp_seq 5</p><p>.Request timeout for icmp_seq 6</p><p>.Request timeout for icmp_seq 7</p><p>.Request timeout for icmp_seq 8</p><p>.Request timeout for icmp_seq 9</p><p>..Request timeout for icmp_seq 1324</p><p>..Request timeout for icmp_seq 1838</p><p>..Request timeout for icmp_seq 1851</p><p>..Request timeout for icmp_seq 2946</p><p>.Request timeout for icmp_seq 2947</p><p>.Request timeout for icmp_seq 2948</p><p>..Request timeout for icmp_seq 2958</p><p>..Request timeout for icmp_seq 4079</p><p>..Request timeout for icmp_seq 8727</p><p>.^C</p><p>--- 1.1.1.1 ping statistics ---</p><p>9782 packets transmitted, 9762 packets received, 0.2% packet loss</p><p>round-trip min/avg/max/stddev = 11.757/16.033/109.835/3.554 ms</p><p>[/CODE]</p><p></p><p>Interestingly, note that the first few packets were missed and then nothing happened until 1324 and then 500'ish packets were good, but then 20 packets were fine after that, but then 1000 packets were fine after that and so on.</p><p></p><p>While interesting, this is only an issue if the packet loss is high enough. High packet loss means that you're constantly retrying your transmission and this has the impact of reducing your overall transmission performance and increasing time for anything to happen.</p><p></p><p>Most of the services these that streams usually buffer data, so intermittent packet loss is usually not a big deal unless it's high enough causing the buffer not to fill up correctly, this will lead to stuttering and jumpiness.</p><p></p><p>What sort of VPN are you using and is the same VPN (and server) on your Linux test machine?</p></blockquote><p></p>
[QUOTE="Raz0rEdge, post: 1877321, member: 110816"] The sequence number indicating each ping packet that is sent out and a response shows up with the time and a lack of one indicates that's it's a missed packet, that's how the tool calculates the percentage packet loss. So it's just an ever increasing number. The DNS only comes into play if you were to ping a location by name, i.e., "ping google.com" means that a lookup has to happen to resolve google.com to some IP address and then the ping tool hits that IP address continually until you stop it. Changing the DNS just determine how quickly our resolve the name to the IP address, but has no impact on the actual ping functionality. I'm on a VPN for my work as well and I can ping 1.1.1.1 with no packet loss. However, if I ping flood "sudo ping -f 1.1.1.1", I start seeing some packet loss like the following: [CODE] sudo ping -f 1.1.1.1 Password: PING 1.1.1.1 (1.1.1.1): 56 data bytes ..Request timeout for icmp_seq 0 .Request timeout for icmp_seq 1 .Request timeout for icmp_seq 2 .Request timeout for icmp_seq 3 .Request timeout for icmp_seq 4 .Request timeout for icmp_seq 5 .Request timeout for icmp_seq 6 .Request timeout for icmp_seq 7 .Request timeout for icmp_seq 8 .Request timeout for icmp_seq 9 ..Request timeout for icmp_seq 1324 ..Request timeout for icmp_seq 1838 ..Request timeout for icmp_seq 1851 ..Request timeout for icmp_seq 2946 .Request timeout for icmp_seq 2947 .Request timeout for icmp_seq 2948 ..Request timeout for icmp_seq 2958 ..Request timeout for icmp_seq 4079 ..Request timeout for icmp_seq 8727 .^C --- 1.1.1.1 ping statistics --- 9782 packets transmitted, 9762 packets received, 0.2% packet loss round-trip min/avg/max/stddev = 11.757/16.033/109.835/3.554 ms [/CODE] Interestingly, note that the first few packets were missed and then nothing happened until 1324 and then 500'ish packets were good, but then 20 packets were fine after that, but then 1000 packets were fine after that and so on. While interesting, this is only an issue if the packet loss is high enough. High packet loss means that you're constantly retrying your transmission and this has the impact of reducing your overall transmission performance and increasing time for anything to happen. Most of the services these that streams usually buffer data, so intermittent packet loss is usually not a big deal unless it's high enough causing the buffer not to fill up correctly, this will lead to stuttering and jumpiness. What sort of VPN are you using and is the same VPN (and server) on your Linux test machine? [/QUOTE]
Verification
Name this item. 🍎
Post reply
Forums
Apple Computing Products:
macOS - Operating System
Packet Loss only on Mac
Top
