Ping latency

Boris_yo

Sep 4, 2013 16:36

Except for online multiplayer videogames, what are additional reasons for having low ping?

Bob

@Boris_yo faster response times

faster data transfer

somequixotic

latency is everything, really

after a certain point, everything is upper bounded by latency

Bob

it's also rather important when typing over SSH - noticeable lag in your text appearing is very annoying

somequixotic

@Boris_yo if that isn't already a question on SU, it should become one... I'm sure it'd get 1000 upvotes... then again, it might get closed for being Too Broad because of our ~~neo-fascist~~ slightly overzealous close voters and moderators :D

you should ask the question, though -- my answer will feed me enough rep to give me a satisfying amount of trickle for a month

unless there are too many answers and it auto-CWs

Bob

lol

Boris_yo

Sep 4, 2013 16:41

@Bob You are saying if I was to download 50MB file with 10ms vs. same size but with 1ms, the latter would finish faster? How many times faster?

Bob

@Boris_yo probably wouldn't notice with such a tiny latency

I'm talking 200ms, 500ms, even up to 1000ms

with TCP transfers, they wait for acknowledgement of a batch of packets being received before sending the next batch

with higher latency, they wait longer

(not sure if it sends in batches or individually - I hope it's the former!)

somequixotic

it really depends on how chatty the protocol is, and how big the buffers are on both sides

Bob

Ah, there's the word. Chattiness.

Also, @somequixotic hates buffer bloat :P

Boris_yo

@Bob That's latency between download request and download start? You have that latency once per each download you make?

somequixotic

a standard HTTP download is very low chattiness, and TCP itself isn't very chatty if you increase the fragment size

Bob

Sep 4, 2013 16:44

@somequixotic it's still enough to have an effect with (very) large latencies

somequixotic

with very low or zero packet loss and a straight one-way download of a file over TCP or UDP, chattiness is not really a factor unless you have an enormous line speed and significant latency

Bob

though at that point inter-country bandwidth comes into play for me

somequixotic

the chattier the protocol, the sooner you start to feel the effects

Bob

basically, (I suspect) there's a cap on my bandwidth from Aus to US

a cap below my normal intracountry speeds

somequixotic

@Bob the "cap" would only exist if you have a huge theoretical end-to-end speed on the line and the TCP layer is using small fragments, both of which would be unusual

more likely the cap is due to traffic shaping than latency for regular downloads

for interactive media, definitely the chattiness latency is the limiting factor

Bob

Sep 4, 2013 16:46

@somequixotic that's what I'm talking about

I left the latency topic four messages ago :P

somequixotic

oh. I didn't. >_>

this is why Samba over the public Internet is nigh impossible, though: it's an enormously chatty protocol

Boris_yo

@somequixotic One-way download doesn't send data in batches?

Bob

@somequixotic they improved that a little with later versions, though

somequixotic

works great on a LAN, but your ping essentially caps your transfer rate beyond, oh, 20 ms

Hennes

@Bob Batches, numbered with a sliding window

Bob

Sep 4, 2013 16:48

s/samba/SMB\/CIFS/gi

somequixotic

@Boris_yo it does, but the infrequency of the synchronous communication (round trips between client and server) is low enough usually if you configure the network stack properly, that latency doesn't become a limiting factor

Hennes

E.g. send up to ten packets with number 1 to 10. Keep all those in local buffers in case they get slost. Then wait for an ACK to state "Packet X arrived savely" or even a "ACK up to packet Y are here". Only then free buffers and send the next pakets

Boris_yo

@Bob Same here Israel to while world. If my ISP offers 100Mbps in land, I would get 10-15% worldwide.

somequixotic

think of it this way: have you ever talked on the phone with someone and had significant high latency? compare the amount of conversation you can have in any given time over that link with the amount of conversation you can have in-person... when doing this comparison, imagine that in Conversation 1, one person is giving a monologue.. say, reading MLK's entire speech

and in Conversation 2, one person says 3-6 words then ends with a question and the other person has to reply Yes/No

in Conversation 1, the amount of spoken language speech that can be transferred and intelligibly interpreted by the receiver is not really restricted by the latency, because it's a monologue, so the person on the other end doesn't care how late they're receiving the data, whether it's 3 nanoseconds or 3 hours

in Conversation 2, if you had to ask someone 50 Yes/No questions as part of a survey, the survey would take days if the latency were on the order of 45 minutes, but if the latency were the speed of sound (in-person), it'd take a couple of minutes

but there are plenty of moderately to intensely chatty protocols that are not gaming

most distributed file server protocols (like SMB, but also NFS, AFS, etc.) are rather chatty

Bob

Except with conversation 1 you would not notice if you lost something

which is the whole point of TCP - it guarantees that either the information arrives (in correct order) or the sender knows the information did not arrive

Boris_yo

Sep 4, 2013 16:55

@somequixotic I never experienced latency on home phone line our public pay phone. In Skype I did!

somequixotic

@Bob right, which is why TCP's reliability feature essentially forces the listener to say "I understood the checksum of <all that you just said>" every once in a while... but that every once in a while can be reduced if you're willing to suffer the consequences of bufferbloat

Bob

and this requires the recipient to tell the sender when they receive a packet, so the sender can resend any that don't make it

Hennes

Argh. Scool memories.

Including building a protocol which did these kind of things.

somequixotic

Maximum transmission unit

In computer networking, the maximum transmission unit (MTU) of a communications protocol of a layer is the size (in bytes) of the largest protocol data unit that the layer can pass onwards. MTU parameters usually appear in association with a communications interface (NIC, serial port, etc.). Standards (Ethernet, for example) can fix the size of an MTU; or systems (such as point-to-point serial links) may decide MTU at connect time. A larger MTU brings greater efficiency because each packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, rem...

Boris_yo

Better not say "I received the packet" or else deal with DEA...

somequixotic

Sep 4, 2013 16:57

the general wisdom for low chattiness application protocols that still want to use TCP's reliability has been to increase TCP's MTU, which is just called the Maximum Segment Size (MSS) in TCP jargon because they like to be different (it's really just an MTU, though), and to increase the size of the buffers on both ends

Maximum segment size

The maximum segment size (MSS) is a parameter of the TCP protocol that specifies the largest amount of data, specified in octets, that a computer or communications device can receive in a single TCP segment, and therefore in a single IP datagram. It does not count the TCP header or the IP header. The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment. Therefore: Headers + MSS ≤ MTU. The max...

Griffin

@slhck First off get a more english like name. Second off who misclicked?

somequixotic

consider the difference between the following:
MLK: "I". You got that?
Listener: Yes.
MLK: "Have". You got that?
Listener: Yes.
MLK: "a". You got that?
Listener: Yes.
MLK: "dream". You got that?
Listener: Yes.

vs

MLK: "I have a dream". You got that?
Listener: Yes.

Root Access

Participants