Độ trễ mạng: 100Mbit so với 1Gbit


11

Tôi có một máy chủ web với kết nối hiện tại là 100Mbit và nhà cung cấp của tôi cung cấp bản nâng cấp lên 1Gbit. Tôi hiểu rằng điều này đề cập đến thông lượng nhưng các gói càng lớn thì chúng càng có thể được truyền đi nhanh hơn, vì vậy tôi sẽ mong đợi thời gian phản hồi giảm nhẹ (ví dụ ping). Có ai đã từng điểm chuẩn này?

Ví dụ (máy chủ 100mbit đến 100mbit) với tải 30 byte:

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

Ví dụ (máy chủ 100mbit đến 100mbit) với tải 300 byte (nằm dưới MTU):

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

Vì vậy, từ 30 đến 300 avg. độ trễ tăng từ 0.164 lên 0.395 - Tôi hy vọng đây sẽ là mức tăng chậm hơn cho kết nối 1gibt đến 1gbit. Tôi thậm chí sẽ mong đợi 100mbit đến 1gbit sẽ nhanh hơn, nếu kết nối thông qua một công tắc đầu tiên chờ cho đến khi nhận được toàn bộ gói.

Cập nhật: Xin vui lòng đọc các ý kiến ​​để trả lời một cách cẩn thận! Kết nối không bão hòa và tôi không nghĩ rằng việc tăng tốc độ này sẽ quan trọng đối với con người đối với một yêu cầu, nhưng đó là về nhiều yêu cầu bổ sung (Redis, Cơ sở dữ liệu, v.v.).

Về câu trả lời từ @LatinSuD :

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms

Ngoài ra còn có mã hóa khác nhau (10b / 12b?) Với thẻ và cáp ethernet gbit mới để nó có thể có hiệu suất cao hơn 25% trên 10 lần (khi bão hòa) so với 100Mbit?
huseyin tugrul buyukisik

Câu trả lời:


15

Độ trễ duy nhất sẽ giảm đáng kể là nếu liên kết 100Mbit hiện tại đã bão hòa. Nếu nó không bão hòa, bạn có thể sẽ không nhận thấy bất kỳ thay đổi nào.

Ngoài ra, giả định của bạn rằng liên kết 1Gbit sẽ có thể hỗ trợ các gói lớn hơn là không chính xác. Kích thước gói tối đa được xác định bởi MTU của các thiết bị khác nhau dọc theo đường đi của gói - bắt đầu với NIC trên máy chủ của bạn, đến tận MTU trên máy tính của khách hàng của bạn. Trong các ứng dụng LAN nội bộ (khi bạn có quyền kiểm soát tất cả các thiết bị dọc theo đường dẫn), đôi khi có thể tăng MTU, nhưng trong tình huống này, bạn bị kẹt khá nhiều với MTU mặc định là 1500. Nếu bạn gửi các gói lớn hơn rằng, cuối cùng họ sẽ bị phân mảnh, do đó thực sự làm giảm hiệu suất.


2
"Đáng trân trọng" là từ khóa ở đây. Tôi chỉ kiểm tra hai máy chủ có phần cứng giống hệt nhau và tải mạng thấp, nhưng với tốc độ ethernet khác nhau. Thời gian ping trung bình (cục bộ, với nguồn ping trên cùng một mạng con) giảm từ 0,21 mili giây xuống còn 0,17 mili giây. Ping các máy chủ tương tự từ nhà, mỗi máy chủ có thời gian 53 mili giây. Có quá nhiều yếu tố ngoài tầm kiểm soát của nhà cung cấp để biến nó thành một bản nâng cấp đáng giá.
Mike Renfro

1
+1 Về mặt kỹ thuật có một sự khác biệt, tuy nhiên nó hoàn toàn không thể hiểu được trừ khi ứng dụng cụ thể cực kỳ nhạy cảm với độ trễ.
Chris S

Cảm ơn bạn đã kiểm tra! Từ 0,21 đến 0,17 là một sự cải thiện 20%, thật tuyệt vời. Tôi không quan tâm đến ping từ nhà (50ms) nhưng thời gian yêu cầu vẫn ở nhà cung cấp. Chúng tôi đã điều chỉnh tất cả xử lý (CPU) và không phải ổ đĩa IO (RAM / Cache / v.v.) đến mức tối đa, vì vậy bây giờ tôi đặt câu hỏi tốc độ mạng giữa các máy chủ tăng thêm bao nhiêu cho toàn bộ độ trễ. Ví dụ: chúng tôi thực hiện ~ 20 Redis-Requests cho một yêu cầu máy chủ web. @MikeRenfro: bạn có thể làm bài kiểm tra tương tự với tải trọng cao hơn không? Ping bình thường là 30byte, avg. Redis khoảng 250. Tôi sẽ mong đợi sự khác biệt để phát triển.
Andreas Richter

2
@Andreas; Tôi nghĩ rằng bạn hoàn toàn bỏ lỡ quan điểm của những ý kiến. Đó là sự cải thiện 40 nano giây. Một số tiền hoàn toàn không thể thiếu đối với con người . Và đó không phải là số tích lũy, không giống như mỗi yêu cầu mất 40 nano giây nữa; nó chỉ là cái đầu tiên sẽ nhanh hơn rất nhiều, vì vậy cái thứ hai sẽ được xếp ngay phía sau nó.
Chris S

1
@ChrisS: câu hỏi không phải về khả năng nhận thức - đó là một câu hỏi nếu ai đó đã từng thử nó và Mike đã làm. Nó cũng không phải là 40 nano giây, mà là micro giây , vì vậy bạn đang thiếu điểm bởi yếu tố 1000 ... kudos. Hãy tin tôi, rằng tôi biết những gì tôi đang làm ... 20% sẽ đủ để biện minh cho các chi phí bổ sung.
Andreas Richter

12

CÓ gbit có độ trễ thấp hơn, vì:

  • cùng một số byte có thể được chuyển trong thời gian nhanh hơn

NHƯNG sự cải thiện chỉ được đánh giá cao nếu (các) gói có kích thước nhất định:

  • Gói 56 byte => hầu như không chuyển nhanh hơn
  • Gói 1000 byte => chuyển nhanh hơn 20%
  • Gói 20000 byte => chuyển nhanh hơn 80%

Vì vậy, nếu bạn có một ứng dụng rất nhạy cảm với độ trễ (4ms so với 0.8ms, khứ hồi cho 20kb) và yêu cầu các gói lớn hơn được chuyển, thì việc chuyển từ 100mbit sang gbit có thể giúp bạn giảm độ trễ, mặc dù bạn sử dụng trung bình ít hơn 100mbit / s (= liên kết không bão hòa vĩnh viễn).

Máy chủ (100mbit) -> Chuyển đổi (gbit) -> Máy chủ (100mbit):

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

Máy chủ (gbit) -> Chuyển (gbit) -> Máy chủ (gbit):

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= trung bình trên nhiều máy chủ Giảm độ trễ 80% cho ping 20kb

(Nếu chỉ một trong các liên kết là gbit, bạn vẫn sẽ giảm 5% độ trễ cho ping 20kb.)


1
Với hầu hết các thiết bị mạng đang được lưu trữ và chuyển tiếp, một gói phải được nhận hoàn toàn bởi một bộ chuyển mạch / bộ định tuyến trước khi nó được truyền. Kết nối nhanh hơn giảm thời gian này cũng làm giảm độ trễ (miễn là kết nối không nhận được tốc độ từ một số liên kết song song).
Brian

1
Do lời giải thích, câu trả lời này là tốt nhất trên trang. Những người khác dường như muốn giải thích sự thật này bằng cách giả sử một trường hợp đặc biệt - hiệu suất mạng trên một khoảng cách dài / rất nhiều thiết bị chuyển mạch. Điều đó rất quan trọng để xem xét, đặc biệt là xem xét mối quan tâm của OP (máy chủ web), nhưng câu trả lời này cũng cho thấy tốc độ chuyển đổi khác biệt có thể tạo ra trong một bước nhảy.
Tyler

3

Tôi nghĩ rằng bạn có một quan niệm sai lầm cơ bản về độ trễ băng thông và "tốc độ". Tốc độ là một chức năng của băng thông và độ trễ. Chẳng hạn, hãy xem xét một lô hàng dữ liệu trên DVD được vận chuyển trên toàn quốc mất 3 ngày để đến nơi. So sánh điều đó với việc gửi dữ liệu qua internet. Internet có kết nối độ trễ thấp hơn nhiều, nhưng để phù hợp với "tốc độ" của kết nối với lô hàng mà bạn phải nhận ở mức 9,6 MB một giây ( ví dụ tham khảo từ nguồn này ).

Trong trường hợp của bạn, việc nâng cấp lên băng thông cao hơn sẽ cho phép bạn phục vụ người dùng đồng thời hơn nhưng không cải thiện độ trễ cho bất kỳ người dùng cá nhân nào.


Điều đó không chính xác - chỉ cần so sánh ping với tải trọng differnt nằm dưới MTU hiện tại: ping server -i0.05 -c200 -s30 so với ping server -i0.05 -c200 -s300 ... Hoặc nói trong ví dụ của bạn: xe tải có DVD 1mio sẽ lái chậm hơn, vì nó nặng hơn so với cái có 1 DVD.
Andreas Richter

2
@andreas thời gian ping không phải là toàn bộ câu chuyện - vì vậy, hãy tranh luận rằng các gói thấp hơn MTU đến nhanh hơn các gói ở MTU đầy đủ. differenc eis bạn không có tất cả dữ liệu mà 1 gói có đầy đủ mtu trong cùng một khoảng thời gian mà 2 gói sẽ đến. Độ trễ là thời gian dành cho tất cả dữ liệu đến. để quay trở lại sự tương tự xe tải, ngay cả khi phải mất một chiếc xe tải có 1 Cd để đến một nửa thời gian vì chiếc xe tải chở 500 cds vẫn phải mất 500 chuyến xe tải đó để cung cấp dữ liệu (750 ngày so với 3).
Jim B

@JimB: vâng, như đã đề cập, câu hỏi của tôi không phải là về tải trọng, mà là về tốc độ: xe tải đầy đủ cần 10 giờ để được hải quan quét, cái nhỏ chỉ 1 giờ. 100mbit / s cũng có nghĩa là, gói 100 bit cần tối thiểu theo lý thuyết là 0,000954ms và gói 1000 bit tối thiểu theo lý thuyết là 0,00954ms. Tất nhiên thời gian xử lý / vv. trên card mạng / switch / v.v. tạo ra một phần lớn hơn của toàn bộ độ trễ, nhưng tôi cũng hy vọng những điều này sẽ nhanh hơn trong chuyển đổi 1gbit, v.v.
Andreas Richter

@andreas - 20% trên cùng một mạng con không phù hợp với câu hỏi của bạn
Jim B

1
@andreas 20% của ping phụ mili giây vẫn là ping phụ mili giây. Thậm chí 150% của một phần trăm giây, như trong thử nghiệm của bạn, sẽ không thành vấn đề trong thế giới thực. Bạn có thực sự có một ứng dụng mà vấn đề là liệu dữ liệu của bạn có ở đó trong 0,0003 giây thay vì 0,0002 giây không?
Shane Madden

2

Bạn đang nhìn thế giới qua một cái lỗ kim. Một thử nghiệm hợp lệ về sự khác biệt về độ trễ ở các tốc độ khác nhau sẽ là giữa hai NIC giống hệt nhau được kết nối với cáp kết nối chéo. Đặt tốc độ toán học của các NIC là 10mb, 100mb và 1000mb. Điều này sẽ cho thấy rằng hầu như không có sự khác biệt về độ trễ ở các tốc độ khác nhau. Tất cả các gói đi cùng tốc độ dây bất kể băng thông tối đa được sử dụng. Khi bạn thêm các thiết bị chuyển mạch với lưu trữ và chuyển tiếp bộ đệm ẩn, mọi thứ sẽ thay đổi. Kiểm tra độ trễ thông qua một công tắc phải được thực hiện chỉ với hai kết nối với công tắc. Bất kỳ lưu lượng truy cập khác có thể ảnh hưởng đến độ trễ của bài kiểm tra của bạn. Thậm chí sau đó, công tắc có thể cuộn các bản ghi, điều chỉnh bộ đếm loại gói, cập nhật đồng hồ bên trong, vv .. Mọi thứ có thể ảnh hưởng đến độ trễ.

Có, chuyển đổi từ 100mb sang 1gb có thể nhanh hơn (độ trễ thấp hơn) do thay đổi phần cứng, NIC khác nhau, chuyển đổi khác nhau, trình điều khiển khác nhau. Tôi đã thấy những thay đổi lớn hơn về độ trễ ping từ sự khác biệt của trình điều khiển so với bất kỳ thay đổi nào khác; băng thông, chuyển mạch, giảm tải NIC, v.v.

Việc chuyển đổi sẽ là thay đổi lớn nhất tiếp theo với việc cắt nhanh hơn đáng kể so với lưu trữ và chuyển tiếp cho các thử nghiệm truyền đơn. Tuy nhiên, một cửa hàng được thiết kế tốt và chuyển đổi chuyển tiếp có thể vượt qua công tắc cắt trong hiệu suất tổng thể dưới tải trọng cao. Trong những ngày đầu của gigabit, tôi đã thấy các công tắc bảng nối đa năng hiệu suất cao 10mb với độ trễ thấp hơn các công tắc gigabit giá rẻ.

Các bài kiểm tra Ping thực tế không liên quan để phân tích hiệu suất khi sử dụng Internet. Họ là những bài kiểm tra nhanh để có được ý tưởng về sân bóng về những gì đang xảy ra trên phương tiện giao thông tại thời điểm kiểm tra. Kiểm tra hiệu suất sản xuất phức tạp hơn nhiều so với chỉ một ping. Công tắc hiệu suất cao là máy tính và chịu tải cao hoạt động khác nhau - thay đổi độ trễ.

Có một NIC chậm hơn, hoặc một NIC được đặt ở tốc độ chậm hơn, thực sự có thể giúp một máy chủ có các vụ nổ đồng thời bằng cách điều chỉnh đầu vào đến máy chủ bằng cách sử dụng bộ đệm chuyển đổi. Một lần truyền lại có thể phủ nhận bất kỳ sự giảm độ trễ nào. Thông thường mức lưu lượng tải trung bình đến cao là quan trọng, không phải là các thử nghiệm ping đơn lẻ. ví dụ: Old Slow Sun Ultrasparc (độ trễ cao hơn cho một lần ping) vượt trội so với máy tính để bàn gigabit giá rẻ mới được sử dụng làm máy chủ dev khi tải dưới băng thông dưới 70%. Máy tính để bàn có gb-gb nhanh hơn, gb-gb kết nối nhanh hơn, bộ nhớ nhanh hơn, bộ nhớ nhiều hơn, đĩa nhanh hơn và bộ xử lý nhanh hơn nhưng nó không hoạt động tốt như phần cứng / phần mềm lớp máy chủ. Điều này không có nghĩa là một máy chủ được điều chỉnh hiện tại chạy gb-gb không nhanh hơn phần cứng cũ, thậm chí có thể xử lý tải thông lượng lớn hơn. Có nhiều điều phức tạp hơn cho câu hỏi "

Tìm hiểu xem nhà cung cấp của bạn đang sử dụng các công tắc khác nhau cho các kết nối 100mb so với 1gb. Nếu họ sử dụng cùng một bảng nối đa năng, tôi sẽ chỉ trả tiền cho mức tăng nếu mức lưu lượng vượt quá băng thông thấp hơn. Mặt khác, bạn có thể thấy rằng trong thời gian ngắn, nhiều người dùng khác sẽ chuyển sang gigabit và một số ít người dùng còn lại trên công tắc cũ giờ đây có hiệu suất cao hơn - độ trễ thấp hơn, trong khi tải công tắc cao (tải tổng thể, không chỉ cho máy chủ của bạn ).

Ví dụ về táo và cam: ISP địa phương đã cung cấp một công tắc mới cho các dịch vụ đi kèm, DSL và điện thoại. Ban đầu người dùng thấy hiệu suất tăng. Hệ thống đã được bán quá mức. Bây giờ người dùng vẫn còn trên chuyển đổi cũ có hiệu suất phù hợp cao hơn. Trong đêm khuya, người dùng trên hệ thống mới nhanh hơn. Vào buổi tối dưới tải cao, các máy khách cũ chuyển đổi rõ ràng tốt hơn hệ thống quá tải mới.

Độ trễ thấp hơn không phải lúc nào cũng tương quan với việc giao hàng nhanh hơn. Bạn đề cập đến MySQl trong 20 yêu cầu phục vụ một trang. Lưu lượng truy cập đó không nên nằm trên cùng một NIC với các yêu cầu của trang. Di chuyển tất cả lưu lượng truy cập nội bộ sang mạng nội bộ sẽ giảm xung đột và tổng số gói trên NIC đi và cung cấp mức tăng lớn hơn mức tăng độ trễ 0,04ms của một gói. Giảm số lượng yêu cầu trên mỗi trang để giảm độ trễ tải trang. Nén các trang, html, css, javascript, hình ảnh để giảm thời gian tải trang. Ba thay đổi này sẽ mang lại lợi nhuận tổng thể lớn hơn liên tục so với việc trả tiền cho băng thông không được sử dụng để giảm độ trễ 0,04ms. Ping cần chạy 24 giờ và được tính trung bình để thấy sự thay đổi độ trễ thực sự. Các công tắc thông minh hiện thực hiện điều chỉnh loại RTSP thích ứng với tăng băng thông ban đầu nhỏ và điều chỉnh chuyển lớn. Tùy thuộc vào kích thước trang của bạn (đồ họa, html / css / javascript lớn), bạn có thể thấy độ trễ / băng thông kết nối ban đầu thấp hơn / cao hơn nhiều so với một trang lớn hoặc chuyển toàn bộ trang. Nếu một phần của trang của bạn đang phát trực tuyến, bạn có thể thấy hiệu suất khác nhau đáng kể giữa trang và luồng.


Cảm ơn bạn vì tất cả các đầu vào tuyệt vời: 1.) Đó là cùng một công tắc, 2.) Một NIC thứ hai cho âm thanh bên trong / bên ngoài có thể cộng hưởng và đáng để thử - ngay cả khi ví dụ như MySQL / etc. đều là hai hướng, do đó, các va chạm sẽ "chỉ" giảm xuống còn một nửa, 3.) Một thử nghiệm trong thế giới thực chỉ thích Nic-Nic, Mike đã thực hiện nó với một mạng con và đạt được những gì bạn mong đợi. phần cứng: "Cải thiện 56 byte = 19%, 200 byte = 27%, 1000 byte = 59%! Vì vậy, gói càng lớn thì càng quan trọng. Và Gigabit chỉ tăng từ 0,17ms (56 byte) lên 0,23ms (1000 byte) ) => 35%, trong khi 100 Mbit tăng từ 0,21 lên 0,56 => 166% ".
Andreas Richter

1

Giả sử các gói 300 byte (nếu bạn sử dụng -s 300nó sẽ thực sự lớn hơn do các tiêu đề).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0,024ms là khoảng thời gian thực tế cần thiết để gửi khung (không tính thời gian truy cập trung bình cũng như các tiêu đề).

Trong một chuỗi bóng bàn, sẽ mất gấp đôi thời gian đó (0,048ms), cộng với thời gian để HĐH xử lý truy vấn.

Điều đó có nghĩa với tôi rằng độ trễ của bạn là do 90% của một số yếu tố trên không. Tôi không chắc liệu bạn sẽ thấy nhiều sự khác biệt với Gb. Một sự khác biệt có thể ít hơn 1ms sẽ không được chú ý trên một máy chủ web.

Dù sao bạn có thể thử với một gói thực sự lớn như 1400 byte?


Ai đó đã chạy các số cho một máy chủ cụ thể và sự khác biệt trở lại ở mức 40 nano giây. Dự đoán của bạn bị tắt bởi hệ số 25 lần quá lớn.
Chris S

@LatinSuD: cảm ơn bạn vì cách tiếp cận mang tính xây dựng và không đổ lỗi rằng tôi không biết tôi đang làm gì. Tôi sẽ đăng kết quả trong câu hỏi thực tế vì tôi có thể hình thành ở đó. Nhưng btw. Tôi cũng hy vọng 90% chi phí sẽ tăng tốc độ , vì các bộ xử lý trong card mạng, v.v ... nhanh hơn cho GBit aswell (hy vọng). @ChrisS: micro-giây và tôi không hiểu ý của bạn với 25.
Andreas Richter

Tôi xin lỗi vì đã trộn lẫn micro và nano; trong mọi trường hợp nó không thể đo lường được. LatinSuD đã dự đoán mức chênh lệch là 1 toàn bộ mili giây, gấp 25 lần so với 40 micro giây mà Mike tìm thấy.
Chris S

@ChrisS: không phải lo lắng. 0,04ms là cho ping 38 byte, nếu gói máy chủ-máy chủ trung bình của chúng tôi khoảng 300 byte, sự khác biệt có thể là 0,4ms. Nếu bây giờ chúng tôi thực hiện 20 yêu cầu cho một yêu cầu máy chủ web (Redis, MySQL, v.v.), điều này sẽ dẫn đến tăng tốc độ 8ms, sẽ tăng 10% tốc độ cho các yêu cầu web hiện tại và hoàn toàn biện minh cho chi phí bổ sung. Tôi chỉ đơn giản là không có nguồn tài nguyên ở đây để tự mình thực hiện các bài kiểm tra, nhưng tôi tin rằng, ngay cả khi con người không thể nhận ra, nó vẫn có thể liên quan. Thích điện hay thần.
Andreas Richter

1
@Andreas, tôi rất nghi ngờ nó sẽ mở rộng quy mô như thế; cả gói lớn hơn gấp 10 lần độ trễ ít hơn 10 lần và 20 lần vì nhiều gói nhanh hơn 20 lần. Nếu nó không hoạt động, đó là giảm 10% chi phí mạng, bạn vẫn phải tính đến thời gian sử dụng trong ứng dụng, có khả năng dài hơn một đến vài đơn hàng so với thành phần độ trễ của mạng. Tôi hy vọng nó hoạt động tốt cho bạn trong mọi trường hợp.
Chris S

1

Điều này phụ thuộc vào loại công tắc bạn đang kết nối. Trên một số nhà cung cấp (như Crisco ... Ý tôi là Cisco), các gói ICMP sẽ chảy trở lại CPU ( gag ).

Bạn có thể thấy một thử nghiệm tốt hơn sẽ là thực hiện kiểm tra máy chủ đến máy chủ bằng cách sử dụng liên kết 100Mbps và 1Gbps (nghĩa là không phải kiểm tra chuyển đổi máy chủ hoặc chuyển đổi máy chủ sang bộ định tuyến).

Vào cuối ngày, độ trễ sẽ giảm xuống tốc độ chuyển tiếp trên công tắc và các chi tiết về kiến ​​trúc của công tắc (nơi đặt ASIC trên bảng, cách xử lý khóa giữa các thẻ dòng, v.v.). Chúc may mắn với thử nghiệm của bạn.


Cảm ơn bạn, tôi chỉ đề cập đến các thử nghiệm Host-Switch-Host và tôi không hiểu tất cả các chuyển đổi quốc tế. Tôi chỉ đơn giản là thích xem, nếu ai đó đã từng điểm chuẩn: Máy chủ- (100mbit) -Switch- (100mbit) -host, Host- (100mbit) -Switch- (1gbit) -host và Host- (1gbit) -Switch- (1gbit ) - Độ trễ của máy chủ cho các kích cỡ gói khác nhau. Nếu không có ai làm, tôi sẽ làm và gửi câu trả lời ở đây.
Andreas Richter

1
Tôi đã sử dụng để bán lại thiết bị chuyển đổi. Có thể nói, những phát hiện của bạn gợi ý cho tôi rằng bạn đã cắm vào thiết bị chuyển mạch của Cisco. Có những lựa chọn thay thế khác cung cấp độ trễ thấp hơn. Như bạn đã chỉ ra một cách đúng đắn, nhiều băng thông không chuyển sang độ trễ thấp hơn (Comcast là thủ phạm chính khiến mọi người chết lặng trong vấn đề này). Nếu bạn đang ở trong một môi trường được lưu trữ, bạn có thể bị mắc kẹt với phần cứng của họ (và vì trong một môi trường được lưu trữ, một vài microsec không quá quan trọng). Chỉ cho tôi hàng triệu pps ở trạng thái ổn định và tôi sẽ quan tâm đến việc cung cấp thêm chi tiết. :)
Sean
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.