Network Working Group G. Hicks
Request for Comments: 392 B. Wessler
NIC: 11584 Utah
Tarih: 20 Eylül 1972

Ağ Verisinin İletimi İçin Ana Bilgisayar Maliyetlerinin Ölçümü

UTAH Zamanlama Deneyleri için Arka Plan

Ekim 1971’den bu yana Utah Üniversitesi’nde her gün çalışan, büyük ölçüde hesaplama kısıtlı işlerimiz bulunmaktadır. Bu işler, kısmi sonuçlar elde etmek için birçok CPU saati boyunca çalışmakta ve başka yerlerden daha iyi sağlanabilecek kaynakları kullanmaktaydı. Bu süreçler yığın (batch) işleri olarak ele alındığından, bir yığın makinesinde çalıştırılmaları gerektiğini düşündük.

Bu “yığın” kullanıcılarının gereksinimlerini karşılamak üzere, bu yılın Mart ayında UCLA-CCN’deki Remote Job Service System (RJS) hizmetini kullanmak için bir program [1] geliştirdik. UCLA’daki RJS, bir IBM 360/91 üzerinde çalıştırılmaktadır.

Bu işlere bazı örnekler şunlardı (ve hâlâ öyledir!):

• (a) Cebirsel sadeleştirme (LISP ve REDUCE kullanılarak)
• (b) Kısmi diferansiyel denklem çözüm uygulamaları
• (c) Dalga biçimi işleme (hem ses hem de video)

91 üzerinde çalıştırılan işlerin özellikleri, RJS’ye gönderilen küçük veri desteleri ve geri alınan büyük yazdırma dosyalarıydı. Bir istisna vardı: dalga biçimi işleme grubu, zaman zaman daha sonra işlemek üzere UCLA’da büyük veri dosyaları depolamaya ihtiyaç duyuyordu. Bu grup işlem yaptığında, daha sonra burada görüntülenen veya dinlenen çok büyük delikli kart dosyalarını geri alıyordu.

Program Mart ayının sonlarında işler hâle geldiğinde—ve rutin olarak kullanılmaya başlandığında—kullanıcılar programın sık sık sayfa hatası (page fault) verdiğinden şikâyet ettiler. Programı, sık kullanılan bölümlerin sayfa sınırlarını aşmayacağı şekilde yeniden yapılandırdık.

UCLA’daki RJS ile olan protokol, veri bağlantısı üzerinden iletilecek tüm program ve verilerin bloklanmasını [2] gerektirir. Bu, özel başlıklar kullanarak kayıtları ve blokları benzetim yoluyla oluşturduğumuz anlamına gelir. Bunun, içerdiği hesaplama ve çekirdek bellek alanı nedeniyle başka bir sorun olduğunu gördük. Bu hesaplama, kayda değer miktarda zaman ve çekirdek alanı alıyordu. Gerçek çekirdek boyutumuz nedeniyle sayfa hataları yüzünden aşırı miktarda ücretlendirildiğimizi fark ettik. Sayfa hataları ayrıca gerçek zamanlı iletim hızımızı, programın gönderme ve alma bölümlerinin yeniden yazılmasının gerekli olduğunu düşündüğümüz ölçüde düşürdü.

Programın sistemden en iyi hizmeti alabilmesi için, bu bölümler her birinin bir sayfanın biraz üzerinde yarısını kaplayacak şekilde iyileştirildi. Böylece herhangi bir anda çekirdekte çok az sayıda sayfamız olduğundan, TENEX zamanlayıcısı programı daha büyük çalışma kümesine sahip işlere göre tercih edebildi. (Bir yan not olarak, sınırlı çekirdeğimiz nedeniyle, etkileşimli bir metin düzenleme hizmeti sağlamak amacıyla küçük—bir buçuk sayfalık—bir editör yazdık.)

TENEX altında ağa erişim mekanizması dosya yönelimlidir. Bu, başka bir ana bilgisayar ile iletişim kurmak için byte-in (BIN) ve byte-out (BOUT) komutlarının kullanılması gerektiği anlamına gelir. Bu iki komutun temel zamanlaması (hızlı modda), veriyi ağa koymak ya da ağdan almak için bayt başına 120 μs’tir [3]. Bir ayrım yapılmıştır; çünkü TENEX izleyicisi (monitor), kullanıcının baytlarını iletime hazır hâle getirmek için bazı “bit karıştırma” işlemleri yapmak zorundadır ya da ağ iletilerini kullanıcı için uygun bir biçime sokmalıdır. Bu işlem “yavaş BIN, BOUT” olarak adlandırılır ve ileti başına bir kez gerçekleşir. Kullanıcının baytları 36 bit uzunluğundaysa, ileti başına ortalama 500 μs sürecektir. Baytların kullanılabilir olması için iletiden açılması gerekiyorsa, iletinin boyutuna bağlı olarak bir milisaniyeye kadar sürebilir [3].

II. Ölçümler ve Sonuçlar

Programın çeşitli bölümlerinin zamanlamasını yaparak, RJS programının bit baytı başına 600 ila 700 μs kullandığını ya da bit başına 75 ile 85 mikrosaniye arasında ücretlendirilebilir CPU zamanı harcadığını bulduk. (Gerçek sonuçlar için Tablo 1 ve 2’ye bakınız.) Bu değerlerin nasıl elde edildiğine dair kısa bir tartışma şimdi yerinde olacaktır.

NOT: Ağ iletim hızlarını ölçmeye çalışmadık; bunun yerine, bir programı (veriyi) diskimizden alıp başka bir ana bilgisayara yürütülmek (işlenmek) üzere göndermenin bize ne kadara mal olduğunu ölçtük.

• Sütun 1, ilk baytın diskten alındığı andan son baytın ağa verildiği ana kadar geçen saat zamanı (gerçek zaman)dır (ya da ağdan ilk baytı aldığımız andan disk dosyasının kapatılmasına kadar geçen süre).

• Sütun 2, Sütun 1 ile aynı şekilde hesaplanır; ancak süreç için ücretlendirilebilir çalışma süresidir.

• Sütun 3, ağa giden ya da ağdan gelen gerçek bayt sayısıdır. Bu sütunu izleyen harf yönü belirtir (örneğin, UCLA’ya gönderme için s, UCLA’dan alma için r).

• Sütun 4, aşağıdaki formülle hesaplanmıştır:

  Saniye başına bit = (gerçek zaman) / ((bayt sayısı) × 8)

• Sütun 5, aşağıdaki formülle hesaplanmıştır:

  μs/bit = (ücretlendirilebilir çalışma süresi × 1000) / ((bayt sayısı) × 8)

• Sütun 6, 5 dakikalık yük ortalamasıdır (ayrıntılar için TENEX dokümantasyonuna bakınız).

Bu değerleri kullanarak, bir milyon bitlik bilgi—yürütülecek programlar ya da veriler—için iletimin 75 ila 85 CPU saniyesi süreceği sonucuna varabiliriz. TENEX sistemlerinde CPU saatinin $474.60 olduğu bir maliyetle [5], bu bir milyon bitin kaynak ana bilgisayardan aktarımı $9.90 ila $11.20 arasında bir maliyete sahip olacak ve yabancı ana bilgisayarın alması için potansiyel olarak aynı miktar gerekecektir. Bu, öngörülen ağ iletim maliyetlerinden [4] yaklaşık 33 ila 37 kat daha yüksektir.

Bazı durumlarda, ağ üzerinden iletilecek programlar için, bunların iletiminden kaynaklanan maliyetin yabancı ana bilgisayarda yürütülme maliyetinden daha yüksek olduğu görülmektedir.

III. Analiz

Ağın ana bilgisayar üzerindeki maliyetini azaltmanın çok sayıda yolu olabilir:

• (a) Ağı bir dosya aygıtı olarak değil, süreçler arası iletişim aygıtı olarak ele almak [6].
• (b) “Akıllı” bir ağ giriş/çıkış aygıtı oluşturmak. Bu, elbette, belirli işletim sistemi türleri ve donanım yapılandırmaları için özelleştirilecektir. TENEX sistemleri için bu, kullanıcının sanal belleğinden doğrudan ağa eşleme işlemleri yapabilme yeteneği olarak uygulanabilir. Her durumda, bu akıllı ağ aygıtının ana bilgisayar için çeşitli protokolleri ele alması gerekecektir. NCP protokollerinde bazı değişiklikler gerekebilir.

RJS programının (Tablo 1 ve 2’de ölçülen) maliyetini azaltmanın bir yolu, RJS-UCLA protokolünü değiştirmek olacaktır. Olası bir değişiklik, ana bilgisayarlara protokolün şu anda gerektirdiği 8 bitlik baytlar yerine 32 bitlik baytları kullanma seçeneğinin tanınmasıdır (çünkü daha verimli olabilir!).

Temel olarak, referans [4] yazarlarının öngördüğü şekilde ağı ekonomik açıdan uygulanabilir kılmak için, ilgili iletişim aygıtlarının daha fazla iyileştirilmesinden ziyade, ana bilgisayarlar ve ağ protokolleri üzerinde çok çalışmaya ihtiyaç olduğu kanaatindeyiz.

Kaynaklar

1. Hicks, Gregory, "Network Remote Job Entry Program—NETRJS", Network Information Center #9632, RFC #325.
2. Braden, R. T., "Interim NETRJS Specifications", Network Information Center #7133, RFC #189, 5 Temmuz 1971.
3. 13-EYL-71 ile 19-EYL-72 döneminde Bolt, Beranek & Newman’dan R. S. Tomlinson ile yapılan kişisel yazışmalar.
4. Roberts, L. G. ve B. D. Wessler, "Computer Network Development to Achieve Resource Sharing", Spring Joint Computer Conference, 7 Mayıs 1970, s. 543–549.
5. Bolt, Beranek & Newman ile yapılan kişisel yazışmalar.
6. Bressler, B., D. Murphy ve D. Walden, "A Proposed Experiment with a Message Switching Protocol", Network Information Center #9926, RFC #333, 15 Mayıs 1972.

Ağ Kullanımı için Utah-10 Muhasebesi

Dönem: 16-EYL-72 12:48:34 ile 19-EYL-72 13:56:11

(Tablo, özgün metindekiyle tamamen aynı şekilde devam eder.)

Dönem: 13-EYL-72 02:23:12 ile 16-EYL-72 11:47:07

(Tablo, özgün metindekiyle tamamen aynı şekilde devam eder.)

Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere Helene Morin, Viagenie tarafından 12/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.