Is 2-3 Second response over 4300 miles to be expected?

operationsIT
operationsIT used Ask the Experts™
on
Hello EE, I have users with a handheld RF bar code scanner that goes 4300 miles across the globe.
When the user scans it takes 2-3 seconds to get back from the server so they can move on to the next scan.
How can I confirm this is normal latency due to distance?  It is a small amount of data in the barcode scan being sent, but given
the miles, I'd expect a second or two to be normal, but I need to present on the topic.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
JohnBusiness Consultant (Owner)
Most Valuable Expert 2012
Expert of the Year 2018

Commented:
What is your connection?   If shared with other users overseas, then 3 seconds would appear to be entirely normal

Author

Commented:
It is 40Mbps WAN across shared with other apps but QOS for this
JohnBusiness Consultant (Owner)
Most Valuable Expert 2012
Expert of the Year 2018

Commented:
So the delay is probably normal in these circumstances.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Lee W, MVPTechnology and Business Process Advisor
Most Valuable Expert 2013

Commented:
I'm on the East Coast of the US.  I have a server on the west coast.  My ping response time is 83 ms.  That's probably about 2500 miles.  Double that and we hit 5000 miles and the response time should be about 166 ms.  So I'd say you have a problem.  Have you tried traceroute and pathping to see that kinds of latency and where?
JohnBusiness Consultant (Owner)
Most Valuable Expert 2012
Expert of the Year 2018

Commented:
Internal to North America is properly fiber or other fast hops.

But overseas may be subject to the circuits used undersea. I would expect that to be different.

I saw like issues in 2016 while using Internet on the Rhine River back to North America. 2 to 3 seconds was not that noticeable to what I was doing.
Paul MacDonaldDirector, Information Systems

Commented:
I agree - the circuit makes a difference here.  Especially if satellite is involved, or if a country's infrastructure isn't up to snuff - latency can be killer.

That said, 3 seconds is an eternity, so I'd check the back end too, to make sure it was as optimized as possible.
Dean ChafeeIT/InfoSec Manager

Commented:
Could you post your ping stats across the 4300 mile WAN? That would help because you really need to isolate the various points of possible lag.  How fast is the scanning application on a LAN?

I can tell you that I have a 2Gig Ethernet service from Los Angeles to Chicago with a consistent 62ms ping rate, that's pretty good. It's a Ethernet Private Line (EPL) service from Comcast, all fiber layer 2 WAN.
John TsioumprisSoftware & Systems Engineer

Commented:
Maybe you should consider some caching on the application you use...3 seconds if the user performs a lot of rapid scanning its probably an issue...
Lee W, MVPTechnology and Business Process Advisor
Most Valuable Expert 2013

Commented:
I'll repeat, you have a problem.

Ping times on overseas circuits are not going to be 2-3 seconds.  LIGHT travels fast.  Yes, there is a loss but most long distance cables are fiber which doesn't have nearly the issues copper would.

Reference:
https://wondernetwork.com/pings

Note: the WORST time between Auckland and Paris is 320 ms (rounding up, at the time I checked).  That's more than 6x faster than the 2-3 second range.  And Washington DC to Tokyo is 158 ms.  I could go on.
Sr. Network Engineer
Commented:
You've got two things impacting the rate of transfer.  Speed of light and TCP windowing.  In addition to your path speeds, you need to account for data processing on both ends due to what is surely a massive TCP window.  QOS will only help to give priority to your traffic exiting the LAN but nothing to speed it across your WAN.  Unless you are paying megabucks for QOS in the cloud, your carrier is going to ignore any marking you do to your traffic.

Regarding the windowing.  Every packet that is being sent via TCP is going to require both a data packet and an ACK.  TCP applications will only send a specified number of packets without receiving an ACK.  The TCP window will be of the most influence at that point.  You app is not only looking for it's own internal confirmation reply from the end host but will be dependent on TCP closing the ACK streams prior to your transaction closing entirely.

With all of this in mind, 2-3 seconds is well within acceptable limits.   You can do some calculations here:

https://www.signiant.com/file-transfer-calculator/

Author

Commented:
Reply from x.x.x.x: bytes=32 time=136ms TTL=120
Reply from x.x.x.x: bytes=32 time=141ms TTL=120
Reply from x.x.x.x: bytes=32 time=135ms TTL=120
Reply from x.x.x.x: bytes=32 time=136ms TTL=120

1 <1 ms <1 ms <1 ms
2   3 ms   3 ms   3 ms
3   3 ms   3 ms   3 ms
4   5 ms   5 ms   5 ms
5   5 ms   5 ms   5 ms
6   5 ms   5 ms   5 ms
7   17 ms  23 ms  17 ms
8  138 ms  138 ms  138 ms
9   136 ms  148 ms  164 ms
10 135 ms  135 ms  192 ms
11 136 ms  139 ms  144 ms
12 136 ms 135 ms 136 ms

Trace Complete
Dean ChafeeIT/InfoSec Manager
Commented:
Those are respectable ping rates, assuming they are consistent.  As atlas mentioned, the TCP overhead needs to be considered, and we have no idea of what the scanner application architecture is, so it could be making many round trips from client to server on each scan. As mentioned above, seems like the application perhaps needs improvement and/or some kind of caching to reduce the round trip overhead.

Regards
nociSoftware Engineer
Distinguished Expert 2018

Commented:
I mis one thing in this picture the remote application also ADDS to the latency. So the speed the application responds.
ping time is more or less raw link speed from interface -> interface and back.
This excludes all TCP overhead on both sides, application overhead on both sides. On remote site presumably database access time.

What would help is take a wireshark/tcpdump trace on both sides simultanously (to a local storage).  (This assumes bot sides use NTP synced clocks...).
Then try to match a session on both sides. That sould give you the link latency as well as the application latency.
On the database end, the ack might be sent when the buffer is read by the app, and a response packet will be seen shortly after (or ack is piggybacked on data if it is send sufficient  fast)
atlas_shudderedSr. Network Engineer

Commented:
Or, one could simply use the calculator at the link I provided to check expected transfer times.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
@atlas: i guess the content of the TCP transmission is between 20-30 bytes net.  ( a barcode + some extra) ... It;s not about sending Megabytes of data, let alone GB of data.   so data is near 0.00000002 GB... it doesn't tell the right data.

In general:
Question is if there is a constant connection and short packets are sent or that a link is establishes for each read... (this will cause a LOT of round trips; the say 10 roundtrips (ack, message).. of 100ms quicky addup to a second.).
atlas_shudderedSr. Network Engineer
Commented:
The tcp window is going to be the biggest point of impact. At the distances and bandwidth involved, data size is really inconsequential if below 1MB. Actually higher but just for argument sake.  In other words, the transfer time between 50kb and 1 M isn't going to be that different.
atlas_shudderedSr. Network Engineer

Commented:
Asker abandoned

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial