<div>
What is your connection? &nbsp; If shared with other users overseas, then 3 seconds would appear to be entirely normal
</div>


<div>
It is 40Mbps WAN across shared with other apps but QOS for this
</div>


<div>
So the delay is probably normal in these circumstances.
</div>


<div>
I'm on the East Coast of the US. &nbsp;I have a server on the west coast. &nbsp;My ping response time is 83 ms. &nbsp;That's probably about 2500 miles. &nbsp;Double that and we hit 5000 miles and the response time should be about 166 ms. &nbsp;So I'd say you have a problem. &nbsp;Have you tried traceroute and pathping to see that kinds of latency and where?
</div>


<div>
Internal to North America is properly fiber or other fast hops. <br />
<br />
But overseas may be subject to the circuits used undersea. I would expect that to be different. <br />
<br />
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.
</div>


<div>
I agree - the circuit makes a difference here. &nbsp;Especially if satellite is involved, or if a country's infrastructure isn't up to snuff - latency can be killer.<br />
<br />
That said, 3 seconds is an eternity, so I'd check the back end too, to make sure it was as optimized as possible.
</div>


<div>
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. &nbsp;How fast is the scanning application on a LAN?<br />
<br />
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.
</div>


<div>
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...
</div>


<div>
I'll repeat, you have a problem.<br />
<br />
Ping times on overseas circuits are not going to be 2-3 seconds. &nbsp;LIGHT travels fast. &nbsp;Yes, there is a loss but most long distance cables are fiber which doesn't have nearly the issues copper would.<br />
<br />
Reference:<br />
<a href="https://wondernetwork.com/pings" rel="ugc">https://wondernetwork.com/pings</a><br />
<br />
Note: the WORST time between Auckland and Paris is 320 ms (rounding up, at the time I checked). &nbsp;That's more than 6x faster than the 2-3 second range. &nbsp;And Washington DC to Tokyo is 158 ms. &nbsp;I could go on.
</div>


<div>
Reply from x.x.x.x: bytes=32 time=136ms TTL=120<br />
Reply from x.x.x.x: bytes=32 time=141ms TTL=120<br />
Reply from x.x.x.x: bytes=32 time=135ms TTL=120<br />
Reply from x.x.x.x: bytes=32 time=136ms TTL=120<br />
<br />
1 &lt;1 ms &lt;1 ms &lt;1 ms<br />
2 &nbsp; 3 ms &nbsp; 3 ms &nbsp; 3 ms<br />
3 &nbsp; 3 ms &nbsp; 3 ms &nbsp; 3 ms<br />
4 &nbsp; 5 ms &nbsp; 5 ms &nbsp; 5 ms<br />
5 &nbsp; 5 ms &nbsp; 5 ms &nbsp; 5 ms<br />
6 &nbsp; 5 ms &nbsp; 5 ms &nbsp; 5 ms<br />
7 &nbsp; 17 ms &nbsp;23 ms &nbsp;17 ms<br />
8 &nbsp;138 ms &nbsp;138 ms &nbsp;138 ms<br />
9 &nbsp; 136 ms &nbsp;148 ms &nbsp;164 ms<br />
10 135 ms &nbsp;135 ms &nbsp;192 ms<br />
11 136 ms &nbsp;139 ms &nbsp;144 ms<br />
12 136 ms 135 ms 136 ms<br />
<br />
Trace Complete
</div>


<div>
I mis one thing in this picture the remote application also ADDS to the latency. So the speed the application responds.<br />
ping time is more or less raw link speed from interface -&gt; interface and back.<br />
This excludes all TCP overhead on both sides, application overhead on both sides. On remote site presumably database access time.<br />
<br />
What would help is take a wireshark/tcpdump trace on both sides simultanously (to a local storage). &nbsp;(This assumes bot sides use NTP synced clocks...).<br />
Then try to match a session on both sides. That sould give you the link latency as well as the application latency.<br />
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 &nbsp;fast)
</div>


<div>
Or, one could simply use the calculator at the link I provided to check expected transfer times.
</div>


<div>
@atlas: i guess the content of the TCP transmission is between 20-30 bytes net. &nbsp;( a barcode + some extra) ... It;s not about sending Megabytes of data, let alone GB of data. &nbsp; so data is near 0.00000002 GB... it doesn't tell the right data.<br />
<br />
In general:<br />
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.).
</div>


<div>
<div class="content wysiwyg-content">
Hello EE, I have users with a handheld RF bar code scanner that goes 4300 miles across the globe.<br />
When the user scans it takes 2-3 seconds to get back from the server so they can move on to the next scan.<br />
How can I confirm this is normal latency due to distance? &nbsp;It is a small amount of data in the barcode scan being sent, but given<br />
the miles, I'd expect a second or two to be normal, but I need to present on the topic.
</div>
</div>


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.

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

latency

Bandwidth

Networking is the process of connecting computing devices, peripherals and terminals together through a system that uses wiring, cabling or radio waves that enable their users to communicate, share information and interact over distances. Often associated are issues regarding operating systems, hardware and equipment, cloud and virtual networking, protocols, architecture, storage and management.