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

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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

JohnBusiness Consultant (Owner)Commented:
What is your connection?   If shared with other users overseas, then 3 seconds would appear to be entirely normal
operationsITAuthor Commented:
It is 40Mbps WAN across shared with other apps but QOS for this
JohnBusiness Consultant (Owner)Commented:
So the delay is probably normal in these circumstances.
SolarWinds® VoIP and Network Quality Manager(VNQM)

WAN and VoIP monitoring tools that can help with troubleshooting via an intuitive web interface. Review quality of service data, including jitter, latency, packet loss, and MOS. Troubleshoot call performance and correlate call issues with WAN performance for Cisco and Avaya calls

Lee W, MVPTechnology and Business Process AdvisorCommented:
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)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 SystemsCommented:
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 ManagerCommented:
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 EngineerCommented:
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 AdvisorCommented:
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.


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.
atlas_shudderedSr. Network EngineerCommented:
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:

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
operationsITAuthor 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 ManagerCommented:
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.

nociSoftware EngineerCommented:
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 EngineerCommented:
Or, one could simply use the calculator at the link I provided to check expected transfer times.
nociSoftware EngineerCommented:
@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 EngineerCommented:
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 EngineerCommented:
Asker abandoned
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.