← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 618 · protokol

NCP İstatistikleri Üzerine Birkaç Gözlem

Yazar
Kurum
Tarih
18 Şubat 1974
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

Network Working Group Edward Taft (PARC-MAXC) Request for Comments: 618 Şubat 1974 NIC #21989

NCP İstatistikleri Üzerine Birkaç Gözlem

HARV-10, CMU-10A ve CMU-10B üzerinde kullanımda olan NCP, bir dizi çalışma ve hata istatistiği toplar; bunlar, örnek daktilo çıktısında gösterildiği gibi, IMP ERROR komutu aracılığıyla herhangi bir kullanıcı tarafından istek üzerine yazdırılabilir.

Gösterilen sayılar, sistemin en son yeniden başlatılmasından bu yana geçen dönemi kapsar. Yazılımın uygulandığı HARV-10’daki son derece sınırlı çevrim içi depolama nedeniyle, bu istatistikler daha kalıcı herhangi bir biçimde günlüklenmez veya kaydedilmez. Bununla birlikte, sistemin küçük boyutu ve seyrek monitör geliştirme çalışmaları nedeniyle HARV-10, donanım bakımı arasındaki süreye, yani bir haftaya yaklaşan süreler boyunca çalışır durumda kalma eğilimindedir. Ekli çıktı, sistemin 168 saatlik çalışma süresinden sonra elde edilmiştir.

NCP uygulayıcılarının ilgisini çekebileceğini düşündüğüm birkaç noktaya dikkat çekmek istiyorum.

İlk olarak, atılan (beklenmeyen) RFNM’lerin sayısının, simüle edilen (zaman aşımına uğrayan) RFNM’lerin sayısına eşit olduğuna dikkat edin. Bu durum, bu istatistiklere baktığım hemen her seferde geçerli olmuştur. Bu da RFNM’lerin kaybolmadığını, aksine NCP zaman aşımı aralığının ötesine geciktiğini düşündürmektedir; bu aralığın 30 saniye olduğuna inanıyorum.

Ağ topluluğundaki birkaç kişi arasında “kayıp RFNM’ler” hakkında konuşmalar duydum ve bunu olası bir alternatif açıklama olarak önermek istiyorum. Belki de daha uzun zaman aşımı değerleri uygundur.

İkinci olarak, alınan allocate’lerin gönderilen allocate’lere oranının (yaklaşık ikiye bir mertebesinde) da oldukça tipik olduğu gözlemlenmektedir. Bunun, çeşitli ana bilgisayarlar arasındaki ayırma stratejilerindeki farklılıkları yansıttığına inanıyorum.

Birçok ana bilgisayar, alınan her veri iletisi için bir allocate göndermiş gibi görünmektedir. Bu, FTP veri aktarım bağlantıları gibi bağlantılar için makul olmakla birlikte, ağda en yaygın görünen tek karakterlik iletiler söz konusu olduğunda önemli ölçüde ek trafik yükü getirir.

Harvard NCP tarafından kullanılan strateji, her sokete bir “istenen ayırma düzeyi” değeri atamaktır (Telnet bağlantıları için genellikle oldukça küçük, FTP veri bağlantıları için ise büyük; bu, kullanıcı programı tarafından ayarlanabilen bir parametredir). Soket için mevcut ayırma bu düzeyin %50’sinin altına düştüğünde, onu tam “istenen düzey”e çıkarmaya yetecek kadar ek ayırma gönderilir.

Bu stratejinin etkisi, alınan belirli sayıda küçük ileti için geri gönderilen allocate sayısını önemli ölçüde azaltmaktır. Bu durum hem ağ trafiğini hem de karşı uçtaki kontrol iletisi yükünü azaltır. Stratejinin FTP veri iletileri üzerinde bir etkisi yoktur; çünkü her ileti genellikle tek seferde bekleyen ayırmayı en az yarı yarıya azaltacak kadar büyüktür.

Son olarak, alınan NOP’ların ürkütücü derecede yüksek sayısı (genellikle tüm kontrol iletilerinin %25’i) hakkında bir yorum yapmak isterim. Bunların çoğu, diğer kontrol iletilerine eklenmiş gibi görünmektedir; dolayısıyla durum, sayıların gösterdiği kadar korkunç değildir. Yine de, birinin neden bu kadar çok göndermek isteyeceğini merak etmeden edemiyorum.


TELNET Daktilo Çıktısı

TELNET daktilo çıktısı dosyası THU 31 JAN 74 428:05 tarihinde başlatıldı

#harv-10 (ayarlar yüklendi) tamamlandı.#

Harvard 5.06A-18 7:28:38
Gerekiyorsa "HELP" yazın.

.login 62,#
JOB 2 Harvard 5.06A-18 TTY25
Adınız lütfen (önce soyadı): Taft
62,404000 olarak giriş yaptınız
0728 31-Oca-74 Per
PERŞEMBELERİ PLANLI PM, 0830-1200 EOT

.imp error

NCP sürüm 1573.1604 çalışma istatistikleri

07:29:02 31-OCA-74

NCP İstatistikleri

NCP (bağlantı 0) İleti Hataları

NCP İletileri

Tür Alınan Gönderilen
NOP 81850 0
RTS 3688 2507
STR 2388 3562
CLS 6055 6059
ALL 183050 101442
GVB 772 0
RET 0 772
INS 109 0
ECO 7472 15426
ERP 15065 7472
ERR 2 0
RST 2782 226
RRP 162 2782

Alınan NCP Hata İletileri

Tür Sayı
4 2

En son hata: UCLA-CCN’den tür 4

Veri:

IMP Veri İletisi Arızaları

Alınan IMP İletileri

Alınan Veri İletisi Boyutlarının Histogramı

Bit Sayı
<1 3
<16 146834
<32 39751
<64 7044
<128 196983
<256 46099
<512 147609
<1024 534
<2048 1820
<4096 1152
<8192 2979
.kjob/k
Job 2, User [62,404000] TTY25’ten çıkış yaptı 0729 31-Oca-74
Çalışma süresi 0 Dak, 03.29 Sn