5 ms·
Hmmm... [ec2-user@ip-10-0-1-56 ~]$ sudo ping -f 10.0.1.111 PING 10.0.1.111 (10.0.1.111) 56(84) bytes of data. .^C --- 10.0.1.111 ping statistics ---
by _msw_ 9y ago
Hmmm...
[ec2-user@ip-10-0-1-56 ~]$ sudo ping -f 10.0.1.111
PING 10.0.1.111 (10.0.1.111) 56(84) bytes of data.
.^C
--- 10.0.1.111 ping statistics ---
115480 packets transmitted, 115479 received, 0% packet loss, time 5385ms
rtt min/avg/max/mdev = 0.037/0.039/0.226/0.008 ms, ipg/ewma 0.046/0.040 ms
- _msw_ 9y agoDifferent c5.18xlarge instances with netperf TCP_RR, no significant tuning: [ec2-user@ip-10-0-2-191 ~]$ netperf -v 2 -H 10.0.2.52 -t TCP_RR -l 30 MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.2.52 () port 0 AF_INET : first burst 0 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 20480 87380 1 1 30.00 21178.69 20480 87380 Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate 10^6bits/s Send Recv Send Recv usec/Tran per sec Outbound Inbound 8 0 0 0 47.217 21178.689 0.169 0.169
- jsolson 9y agoc5 wasn't available to me when I made that comment, or at least c5 numbers weren't — we have them now, although we're observing ~10 µs worse than your one-off in ours. It's certainly a nice improvement over what we see on the c4s. Is that using a placement group to ensure proximity (I believe our tests do, but I'd have to double check)? Our benchmarking philosophy is generally to aim for "default" numbers for GCP and "best" numbers for others -- keeps us honest about our "fresh out of the box" behavior. Also, if we should be seeing better on earlier instance types, I'd love to know what we're potentially doing wrong.