Ağ Hızlarında Sorun Giderme - Yaş Sorgulama

Asırlık bir soru olduğundan emin olduğum konuda yardım arıyorum. Kendimi ağ akışını daha net anlamak için özlem duydum, ancak "tık" yapan bilgiler bulamıyorum.

Coğrafi olarak dağıtılan ve Windows'un çeşitli sürümlerini çalıştıran birkaç sunucumuz var. Kaynak olarak her zaman bir ana bilgisayar (masaüstü) kullandığımızı varsayarsak, bu ana bilgisayardan ülke genelindeki diğer sunuculara veri kopyalarken, hızda yüksek bir sapma görürüz. Bazı durumlarda, verileri sürekli olarak 12MB / s'de kopyalayabiliriz, bazılarında ise 0.8 MB / s görüyoruz. Unutulmamalıdır ki, 8 hedefi test ettikten sonra, her zaman 0.6-0.8MB / s veya 11-12 MB / s'de görünüyoruz. Öncelikle ilgilendiğimiz binada, ISS'mize OC-3 bağlantısı var.

Oyunda çok fazla değişken olduğunu biliyorum, ancak sanırım buradaki uzmanlar, anlayışımı desteklemeye yardımcı olacak birkaç temel soruyu cevaplamaya yardımcı olabileceğini umuyordum.

1.) 100Mbps Ethernet kartı ve 72 ms tipik gecikme süresiyle Windows XP, server 2003 vb. Çalıştıran eski makineler için, 0.8 MB / sn'lik ses makul olabilir mi? Yoksa bunun bir sorunu gösterecek kadar yavaş olduğunu düşünüyor musunuz?

2.) "Verim = TCP penceresi / gecikmesi" nin klasik "matematiksel en yüksek hızı", bizim durumumuzda 0.8 MB / sn (64Kb / 72 ms) olarak hesaplanmıştır. Benim anlayışım bu bir üst sınır; bu hızı aşmamak için (havai nedenlerden dolayı) asla ulaşmayı beklemeyeceğinizi unutmayın. Yine de bazı durumlarda 12,3 MB / s hız görüyoruz. Ağın etrafına dağılmış Steelhead hızlandırıcıları var, bunlar bu kadar yüksek bir aktarım oranından sorumlu olabilir mi?

3.) SMB ve SMB2 kullanımının hız farklarını açıklayabileceği öne sürülmüştür. Gerçekten de, beklendiği gibi, paket yakalamaları, oyundaki işletim sistemi sürümlerine bağlı olarak, beklediğimiz gibi kullanıldığını gösterir. SMB2'nin kullanılıp kullanılmadığını neyin belirlediğini anlıyorum, ancak SMB2 ile ne tür bir performans kazancı beklediğinizi merak ediyorum.

Sorunum, makul ağ hızlarının ne olduğu ve ne olmadığı konusunda deneyim eksikliği ve daha da önemlisi perspektif gibi görünüyor. Herkes bağlam / perspektif gelmesine yardımcı olabilir misiniz?

Bahsettiğiniz matematiksel formül aslında gerçek bant genişliği değil TCP için en verimli iletim penceresi boyutu ayarlarını belirlemenin yoludur. TCP, ağ koşullarına bağlı olarak iletim hızlarının ayarlanmasına izin veren sürgülü pencereler adı verilen bir mekanizma kullanır. Buradaki fikir, bir TCP vericisinin alıcıdan onay gerektirmeden daha fazla veri göndermesidir. Veri kaybı varsa, onaylar arasında gönderilen veri miktarı azalır, böylece etkin bant genişliği de azalır.

Söz konusu formül, belirli bir ana bilgisayar çifti arasındaki gecikme ve gidiş-dönüş gecikmesine bağlı olarak TCP iletim penceresinin ideal boyutlandırmasını belirler. Buradaki fikir, 'uçuşta' veri miktarı bant genişliği geciktirme ürünü olarak bilinen şeye karşılık gelecek şekilde boyutlandırılmış bir pencereye sahip olmaktır. Örneğin, saniyede 50 megabit (6.25 megaBYTES) ve ortalama 100 ms'lik gidiş-dönüş gecikmesi varsa, 6.25 * 0.1 = 625 kilobayt veriye sahip olursunuz. Bu TCP'nin görüşeceği değer olacaktır (doğru yapılandırılmışsa). Bağlantılarınızın gecikme ve bant genişliği özellikleri değiştikçe, pencere boyutu da değişir.

İhtiyacınız olan şey, hem kaynakta hem de çeşitli hedeflerinizde çalışan iperf (ücretsiz) gibi bir bant genişliği yönetim aracıdır. Bu, gecikme konusunda bir fikir verirken (diğer uygulamalardan bağımsız olarak) mümkün olan gerçek verim miktarı hakkında bir fikir vermelidir. Ana bilgisayarlar arasında uzatılmış bir ping çalıştırmak, gecikme özellikleri hakkında genel bir fikir sağlayacaktır. Bu verilere sahip olduğunuzda, iş hacmine kadar ne görmeniz gerektiği hakkında daha iyi bir fikre sahip olacaksınız.

BTW - Herhangi bir LAN optimizer türünün kullanımı genellikle veri sıkıştırma, TCP optimizasyonu, önbellekleme, vb içerir. Kullanışlı olsa da, altta yatan bağlantıların doğasını gizleyebilir. Ham bant genişliği / gecikmesi (ve potansiyel olarak paket kaybı) hakkında bir fikriniz olduğunda, çeşitli ana bilgisayarlarınızın mevcut bant genişliğinden uygun şekilde yararlanacak şekilde ayarlandığından emin olmak için daha yakından bakabilirsiniz.

SMB sorunu olup olmadığını kontrol etmek için "ping -l 8092" veya FTP veya HTTP'yi deneyin.

Her şeyden önce: bilgisayarları bağlamak için hangi ortamı kullanıyorsunuz? Ne "100mpbs"? Ethernet? "Coğrafi olarak dağıtılmış" bilgisayarlar için kullanamazsınız, değil mi?

Bilgisayarlarınız arasındaki "İnternet üzerinden vpn" yönlendiricileri farklı bağlantılar kullanabilir: biri hızlı, diğeri değil. Birçok parametreye göre bağlantı seçebilirler.

Lütfen ağınızı tanımlayın.

Bu bir MTU sorunu da olabilir: birkaç bağlantı farklı MTU'lara sahip olabilir.

Birçok yorum ve kullanıcı burada harika tavsiyeler sundu. Bazıları aradığım şeye oldukça yaklaştı, ama aynı zamanda şirketimizden bir şeyleri açıklığa kavuşturmaya yardımcı olan bir Ağ gazisi ile tanışacak kadar şanslıydım. Bulgularımı / anlayışlarımı başkalarının yararına yayınlayacağımı düşündüm. Bunlardan herhangi biri görünüyorsa lütfen beni düzeltmekten çekinmeyin:

1.) 72ms gecikme ve 64K pencereli tek bir TCP oturumunun maksimum verimi 0,8 MB / s civarındadır ve bu hızı, robokopi ile gerçekleştirdiklerimiz gibi tek iş parçacığı, tek oturum kopyaları için makul hale getirir.

2.) Bu hız farkı, transfer yönteminin etkinliğine inmektedir. Bizim durumumuzda Robocopy ve Repliweb kullanıyorduk. Robocopy'nin tek bir TCP oturumu kullandığını fark ederken, Repliweb veri göndermek için birden fazla oturum açabilir.

3.) Microsoft'un web sitesinden yapılan araştırmalar, SMB2'nin SMB1 üzerinde önemli bir performans kazancı olduğunu göstermektedir. Ancak nasıl OS görüşür bazı durumlarda olmuştur sorunlar bir ikisi a farkında olmalıdır var bu yüzden kullanımına hangi protokolü.) Hangi durumlarda SMB2 edebilir kullanılan, b edilebilir.) SMB2 fiilen kullanılan dayalı ediliyor olsa da olmasa ağ yakalamalarında.

Şu anda, Tel-köpekbalığı SMB2 protokolünün kullanımını belirleyebilir gibi görünüyor.

Umarım bu yardımcı olur. Yine, benim anlayış burada oldukça ilkel, genişlemek için çekinmeyin.