Dari NY Datacenter kami, transfer ke lokasi yang lebih jauh memiliki kinerja yang buruk.
Menggunakan tes kecepatan untuk menguji berbagai lokasi, kita dapat menjenuhkan uplink 100 mbit ke Boston dan Philadelphia dengan mudah. Ketika saya menggunakan tes kecepatan ke lokasi di pantai barat AS atau Eropa, saya sering melihat hanya sekitar 9 mbit / s.
Reaksi pertama saya adalah bahwa ini adalah masalah penskalaan jendela (Produk Penundaan Bandwidth). Namun, saya telah menyesuaikan dengan parameter kernel Linux pada mesin uji di pantai barat dan menggunakan iperf ke titik di mana ukuran Window cukup untuk mendukung 100 MegaBytes per detik dan masih memiliki kecepatan lambat (Verified in Capture). Saya juga telah mencoba menonaktifkan algoritma Nagle.
Kami mendapatkan kinerja yang buruk dari Linux dan Windows, tetapi secara signifikan lebih buruk (1/3) kecepatan menggunakan Windows.
Bentuk transfer (tanpa Nagle) adalah:
Dip sekitar 10-an memiliki ~ 100 duplikat acks.
Bentuk Min Window ukuran penerima dari waktu ke waktu adalah:
Ada ide ke mana harus pergi berikutnya untuk menjabarkan leher botol kami?
Beberapa hasil tes Kecepatan (Unggah menggunakan speedtest.net):
- Philadelphia: 44 mbit (Orang yang menggunakan situs kami menggunakan sisanya ;-))
- Miami: 15 mbit
- Dallas: 14 mbit
- San Jose: 9 mbit
- Berlin: 5 mbit
- Sydney: 2,9 mbit
Even More Data:
Miami: 69.241.6.18
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.579 ms 0.588 ms 0.594 ms
3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.562 ms 0.569 ms 0.565 ms
4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.634 ms 0.640 ms 0.637 ms
5 vlan79.csw2.newyork1.level3.net (4.68.16.126) 4.120 ms 4.126 ms vlan89.csw3.newyork1.level3.net (4.68.16.190) 0.673 ms
6 ae-81-81.ebr1.newyork1.level3.net (4.69.134.73) 1.236 ms ae-91-91.ebr1.newyork1.level3.net (4.69.134.77) 0.956 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73) 0.600 ms
7 ae-10-10.ebr2.washington12.level3.net (4.69.148.50) 6.059 ms 6.029 ms 6.661 ms
8 ae-1-100.ebr1.washington12.level3.net (4.69.143.213) 6.084 ms 6.056 ms 6.065 ms
9 ae-6-6.ebr1.atlanta2.level3.net (4.69.148.105) 17.810 ms 17.818 ms 17.972 ms
10 ae-1-100.ebr2.atlanta2.level3.net (4.69.132.34) 18.014 ms 18.022 ms 18.661 ms
11 ae-2-2.ebr2.miami1.level3.net (4.69.140.141) 40.351 ms 40.346 ms 40.321 ms
12 ae-2-52.edge2.miami1.level3.net (4.69.138.102) 31.922 ms 31.632 ms 31.628 ms
13 comcast-ip.edge2.miami1.level3.net (63.209.150.98) 32.305 ms 32.293 ms comcast-ip.edge2.miami1.level3.net (64.156.8.10) 32.580 ms
14 pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230) 32.172 ms 32.279 ms 32.276 ms
15 te-8-4-ur01.northdade.fl.pompano.comcast.net (68.85.127.130) 32.244 ms 32.539 ms 32.148 ms
16 te-8-1-ur02.northdade.fl.pompano.comcast.net (68.86.165.42) 32.478 ms 32.456 ms 32.459 ms
17 te-9-3-ur05.northdade.fl.pompano.comcast.net (68.86.165.46) 32.409 ms 32.390 ms 32.544 ms
18 te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198) 33.938 ms 33.775 ms 34.430 ms
19 te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198) 32.896 ms !X * *
69.241.6.0/23 *[BGP/170] 1d 00:55:07, MED 3241, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 20214 I
> to 216.187.115.166 via xe-0/0/0.0
San Jose: 208.79.45.81
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.477 ms 0.549 ms 0.547 ms
3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.543 ms 0.586 ms 0.636 ms
4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.518 ms 0.569 ms 0.566 ms
5 vlan89.csw3.newyork1.level3.net (4.68.16.190) 0.620 ms vlan99.csw4.newyork1.level3.net (4.68.16.254) 9.275 ms vlan89.csw3.newyork1.level3.net (4.68.16.190) 0.759 ms
6 ae-62-62.ebr2.newyork1.level3.net (4.69.148.33) 1.848 ms 1.189 ms ae-82-82.ebr2.newyork1.level3.net (4.69.148.41) 1.011 ms
7 ae-2-2.ebr4.sanjose1.level3.net (4.69.135.185) 69.942 ms 68.918 ms 69.451 ms
8 ae-81-81.csw3.sanjose1.level3.net (4.69.153.10) 69.281 ms ae-91-91.csw4.sanjose1.level3.net (4.69.153.14) 69.147 ms ae-81-81.csw3.sanjose1.level3.net (4.69.153.10) 69.495 ms
9 ae-23-70.car3.sanjose1.level3.net (4.69.152.69) 69.863 ms ae-13-60.car3.sanjose1.level3.net (4.69.152.5) 69.860 ms ae-43-90.car3.sanjose1.level3.net (4.69.152.197) 69.661 ms
10 smugmug-inc.car3.sanjose1.level3.net (4.71.112.10) 73.298 ms 73.290 ms 73.274 ms
11 speedtest.smugmug.net (208.79.45.81) 70.055 ms 70.038 ms 70.205 ms
208.79.44.0/22 *[BGP/170] 4w0d 08:03:46, MED 0, localpref 59, from 216.187.115.12
AS path: 3356 11266 I
> to 216.187.115.166 via xe-0/0/0.0
Philly: 68.87.64.49
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.578 ms 0.576 ms 0.570 ms
3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.615 ms 0.613 ms 0.602 ms
4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.584 ms 0.580 ms 0.574 ms
5 vlan79.csw2.newyork1.level3.net (4.68.16.126) 0.817 ms vlan69.csw1.newyork1.level3.net (4.68.16.62) 9.518 ms vlan89.csw3.newyork1.level3.net (4.68.16.190) 9.712 ms
6 ae-91-91.ebr1.newyork1.level3.net (4.69.134.77) 0.939 ms ae-61-61.ebr1.newyork1.level3.net (4.69.134.65) 1.064 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73) 1.075 ms
7 ae-6-6.ebr2.newyork2.level3.net (4.69.141.22) 0.941 ms 1.298 ms 0.907 ms
8 * * *
9 comcast-ip.edge1.newyork2.level3.net (4.71.186.14) 3.187 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.34) 2.036 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.2) 2.682 ms
10 te-4-3-ar01.philadelphia.pa.bo.comcast.net (68.86.91.162) 3.507 ms 3.716 ms 3.716 ms
11 te-9-4-ar01.ndceast.pa.bo.comcast.net (68.86.228.2) 7.700 ms 7.884 ms 7.727 ms
12 te-4-1-ur03.ndceast.pa.bo.comcast.net (68.86.134.29) 8.378 ms 8.185 ms 9.040 ms
68.80.0.0/13 *[BGP/170] 4w0d 08:48:29, MED 200, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 I
> to 216.187.115.166 via xe-0/0/0.0
Berlin: 194.29.226.25
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.483 ms 0.480 ms 0.537 ms
3 oc48-po2-0.nyc-telx-dis-2.peer1.net (216.187.115.133) 0.532 ms 0.535 ms 0.530 ms
4 oc48-so2-0-0.ldn-teleh-dis-1.peer1.net (216.187.115.226) 68.550 ms 68.614 ms 68.610 ms
5 linx1.lon-2.uk.lambdanet.net (195.66.224.99) 81.481 ms 81.463 ms 81.737 ms
6 dus-1-pos700.de.lambdanet.net (82.197.136.17) 80.767 ms 81.179 ms 80.671 ms
7 han-1-eth020.de.lambdanet.net (217.71.96.77) 97.164 ms 97.288 ms 97.270 ms
8 ber-1-eth020.de.lambdanet.net (217.71.96.153) 89.488 ms 89.462 ms 89.477 ms
9 ipb-ber.de.lambdanet.net (217.71.97.82) 104.328 ms 104.178 ms 104.176 ms
10 vl506.cs22.b1.ipberlin.com (91.102.8.4) 90.556 ms 90.564 ms 90.553 ms
11 cic.ipb.de (194.29.226.25) 90.098 ms 90.233 ms 90.106 ms
194.29.224.0/19 *[BGP/170] 3d 23:14:47, MED 0, localpref 69, from 216.187.115.15
AS path: 13237 20647 I
> to 216.187.115.182 via xe-0/1/0.999
Memperbarui:
Menggali ini sedikit lebih dalam dengan Tall Jeff kami telah menemukan sesuatu yang aneh. Menurut TCPDump di sisi pengirim mengirim paket sebagai paket 65k melalui Internet . Ketika kita melihat kesedihan di sisi penerima, mereka tiba terfragmentasi 1448 seperti yang Anda harapkan.
Berikut tampilan paket dump di sisi Pengirim:
Apa yang terjadi kemudian adalah bahwa pengirim berpikir itu hanya mengirim paket 64k, tetapi pada kenyataannya sejauh penerima khawatir itu mengirim paket. Hasil akhirnya mengacaukan kontrol kemacetan. Anda dapat melihat ini adalah grafik dari panjang paket paket data yang dikirim oleh pengirim:
Adakah yang tahu apa yang menyebabkan Pengirim berpikir ada 64k MTU? Mungkin beberapa /proc, ethtoolatau ifconfig parameter? ( ifconfigmenunjukkan MTU adalah 1500). Tebakan terbaik saya saat ini adalah semacam akselerasi perangkat keras - tetapi saya tidak yakin secara spesifik.
Subedit 2-2 IV:
Baru saja berpikir, karena paket 64k ini memiliki set bit DF, mungkin penyedia saya memecahnya, dan mengacaukan penemuan otomatis MSS! Atau mungkin firewall kami salah konfigurasi ...
Tambahan Edit 9.73.4 20-60:
Alasan saya melihat paket 64k adalah karena pembongkaran segmen (tso dan gso, lihat ethtool -K) aktif. Setelah mematikannya, saya tidak melihat peningkatan dalam kecepatan transfer. Bentuknya sedikit berubah dan transmisi ulang ada di segmen yang lebih kecil:
Saya juga telah mencoba semua algoritma kemacetan yang berbeda di Linux tanpa perbaikan. Penyedia NY saya mencoba mengunggah file ke server ftp uji di ATAU dari fasilitas kami dan mendapatkan kecepatan 3x.
Laporan MTR yang diminta dari NY ke OR:
root@ny-rt01:~# mtr haproxy2.stackoverflow.com -i.05 -s 1400 -c 500 -r
HOST: ny-rt01.ny.stackoverflow.co Loss% Snt Last Avg Best Wrst StDev
1. stackoverflow-nyc-gw.peer1.n 0.0% 500 0.6 0.6 0.5 18.1 0.9
2. gig4-0.nyc-gsr-d.peer1.net 0.0% 500 0.6 0.6 0.5 14.8 0.8
3. 10ge.xe-0-0-0.nyc-telx-dis-1 0.0% 500 0.7 3.5 0.5 99.7 11.3
4. nyiix.he.net 0.0% 500 8.5 3.5 0.7 20.8 3.9
5. 10gigabitethernet1-1.core1.n 0.0% 500 2.3 3.5 0.8 23.5 3.8
6. 10gigabitethernet8-3.core1.c 0.0% 500 20.1 22.4 20.1 37.5 3.6
7. 10gigabitethernet3-2.core1.d 0.2% 500 72.2 72.5 72.1 84.4 1.5
8. 10gigabitethernet3-4.core1.s 0.2% 500 72.2 72.6 72.1 92.3 1.9
9. 10gigabitethernet1-2.core1.p 0.4% 500 76.2 78.5 76.0 100.2 3.6
10. peak-internet-llc.gigabiteth 0.4% 500 76.3 77.1 76.1 118.0 3.6
11. ge-0-0-2-cvo-br1.peak.org 0.4% 500 79.5 80.4 79.0 122.9 3.6
12. ge-1-0-0-cvo-core2.peak.org 0.4% 500 83.2 82.7 79.8 104.1 3.2
13. vlan5-cvo-colo2.peak.org 0.4% 500 82.3 81.7 79.8 106.2 2.9
14. peak-colo-196-222.peak.org 0.4% 499 80.1 81.0 79.7 117.6 3.3
sumber
Jawaban:
Memastikan jendela TCP terbuka cukup lebar untuk menutupi Produk Penundaan Bandwidth akan menjadi tebakan pertama saya juga. Dengan anggapan bahwa telah dikonfigurasikan dengan benar (dan didukung oleh kedua ujungnya) Saya selanjutnya akan memeriksa jejak paket untuk memastikan bahwa jendela benar-benar terbuka dan bahwa salah satu hop di jalur tidak melucuti penskalaan jendela. Jika itu semua baik, dan Anda yakin Anda tidak membenturkan bandwidth yang dibatasi hop di jalan, kemungkinan penyebab masalah Anda adalah penurunan paket acak. Hipotesis ini didukung oleh indikasi duplikat ACK yang Anda sebutkan. (ACK duplikat umumnya merupakan akibat langsung dari data yang hilang). Juga perhatikan bahwa dengan produk penundaan bandwidth besar dan karena itu jendela geser terbuka yang besar,
Catatan Sisi: Untuk transfer data massal melalui TCP dan melalui koneksi WAN multi-hop, seharusnya tidak perlu atau alasan untuk menonaktifkan Nagle. Sebenarnya, skenario persis itulah yang menyebabkan Nagle ada. Secara umum, Nagle hanya perlu dinonaktifkan untuk koneksi interaktif di mana datagram berukuran sub-MTU perlu dipaksa keluar tanpa penundaan. yaitu: Untuk transfer massal, Anda ingin sebanyak mungkin data dalam setiap paket.
sumber
Apakah Anda menyetel ambang pengubahan urutan paket? Periksa di tcp_reordering di / proc di Linux. Pada pipa yang panjang, itu biasa efek multipath untuk menyebabkan deteksi paket loss palsu, transmisi ulang dan penurunan kecepatan yang Anda kirim dalam grafik Anda. Itu menyebabkan banyak Acuan duplikat juga, jadi layak untuk diperiksa. Jangan lupa Anda harus menyetel kedua sisi pipa untuk memiliki resul yang baik dan menggunakan setidaknya kubik. Protokol interaktif, seperti ftp dapat membahayakan tcp apa pun untuk optimasi pipa panjang yang dapat Anda lakukan. Kecuali Anda hanya mentransfer file besar.
sumber
Apa yang Anda lihat terlihat cukup normal bagi saya, berdasarkan latensi yang Anda laporkan ke berbagai situs Anda. Latency akan mematikan melalui throughput hampir semua koneksi tunggal, terlepas dari bandwidth yang tersedia, dengan sangat cepat.
Silver Peak menawarkan penaksir cepat dan kotor untuk throughput yang dapat Anda lihat dengan jumlah bandwidth tertentu tingkat latensi tertentu di sini: http://www.silver-peak.com/calculator/
Sambungkan koneksi 100mbit dengan latensi yang sesuai yang Anda lihat, dan Anda akan menemukan bahwa kecepatan Anda benar-benar cocok (Kira-kira) dengan apa yang seharusnya Anda lihat.
Adapun Windows memberikan kinerja yang lebih buruk daripada Linux, sayangnya, saya tidak bisa menawarkan saran bagus di sana. Saya kira Anda melakukan perbandingan apel dengan apel dengan perangkat keras yang identik (NIC, khususnya)?
sumber