Neden X11 iletimi bu kadar yetersiz?


97

Ne zaman uzaktan X11 iletme ile büyük GUI'lar başlatsam, -C anahtarı dahil olsa bile, deneyim çok tepkisiz oluyor. Sorum şu ki, kavram / protokol düzeyinde buna ne sebep olur?

25mbit bağlantımla HD videoyu bilgisayarıma kesinlikle sorunsuzca aktarabilirim. Öte yandan, X11 iletme özelliğine sahip uzaktan başlatılan GUI'lerin tepkisizliği, gecikmenin sıfıra yakın olması gereken 100 MB'lık bir LAN üzerinden bile gerçekleşiyor.

Video akışının tersine, gecikmenin en iyi şekilde iki katına çıkacağını (girişin uzak makineye gönderilmesi gerektiğinden ve yalnızca uygulamanın yanıt verebilmesi gerektiğinden) anlıyorum, ancak dahili olarak gecikmeyi artıran başka faktörler var mı? Daha ileri?

İkincisi, bant genişliği. Neden bu kadar çok yiyor? Resim ve video formatları söz konusu olduğunda, boyutu önemli ölçüde azaltmak için birçok yöntem kullanılır.

Örneğin .bmp vs .png durumunda, büyük siyah kare bir görüntü .png sunumunda daha az yer alacaktır, çünkü bilgi her bir piksel için saklanmaz, fakat anladığım kadarıyla aralık şeklinde.

Videolarda, tüm kareler yerine kareler arasındaki fark gönderilerek çok fazla bilgi kaydedilebilir.

Bunun çok basit olduğunu biliyorum, ancak X11 bu yöntemleri kullanmıyor mu? Bir bitmap-ish'de veya bir seviyede diferansiyel olmayan bir ilkede davranıyor mu? Ve değilse, neden bu kadar çok bant genişliği alıyor?


9
Diğer bilgiler: Xpra ilginç bir yaklaşım sunuyor.
Kamil Maciorowski

12
BTW - "-C" yi kullanmak, bağlantınızın yeterince hızlı olması durumunda bağlantınızı yavaşlatır, çünkü sıkıştırma zaman alır. "-C" 100Mb'ye fayda sağlayabilir, ancak muhtemelen 1Gb'ye ve kesinlikle 10Gb'ye zarar verebilir. Bu aynı zamanda 'ssh' işleminin veriminize zarar vereceği durumudur - hızlı bağlantılar üzerinden yapılan şifrelemelerde olduğu gibi. Bilgisayarlar veya güvenli bir iç bağlantı arasında doğrudan bir bağlantınız varsa, X bağlantınızla TCP: 6000 üzerinden doğrudan gidin. Belirgin bir hız artışı elde edersiniz.
Astara,

2
Tüm verileri şifrelemek / şifresini çözmek zorunda olan SSH üzerinden yönlendiriyorsunuz. Bu ek yük / gecikme ekleyecektir. Daha hızlı işlemciler yardımcı olabilir, ancak ne yaparsanız yapın, bunun katacağı belli bir miktar gecikme var. X çok "konuşkan" dır, bu nedenle gecikmedeki hafif artış = performansta önemli düşüş. Geçmiş zamanlarda, 28.8 modem üzerinden SSH aracılığıyla tünellenmiş X'i kullanabildim; Bu, çok fazla veriyi önbelleğe alan / sıkıştıran ve bağlantının "konuşkanlığını" azaltan lbxproxy (şimdi kullanımdan kaldırılmış) kullanıyordu. -C kullanımı yalnızca daha fazla gecikme ekleyebilir.
Meower68

ssh -Y -c blowfishŞifrelemeyi yaparken ek yükü en aza indirgemek gibi bir şey kullanın . Her iki ucun da tam kontrolüne sahipseniz, ssh'ye bağlantıda tam transfer hızı elde etmek için "none" şifrelemesini kullanmayı öğretin.
Thorbjørn Ravn Andersen

Yanıtlar:


116

X11 protokolü, yoğun işlemleri asla grafiksel (bitmapler / dokular açısından) işlemeye yönelik değildi. X11'in ilk tasarlandığı güne, bilgisayar grafikleri bugün olduğundan çok daha basitti.

Temel olarak, X11 ekranı bilgisayarınıza göndermez, ancak yerel bilgisayardaki X sunucusunun yerel sisteminizde ekranı yeniden oluşturabilmesi için ekran yönergelerini gönderir. Ve bunun ekranın her değişiminde / yenilemesinde yapılması gerekiyor.
Böylece bilgisayarınız "bu renkte x, y - (xx, yy) koordinatlarından çizgi çizin, W piksel genişliğinde dikdörtgen çizin, sol üst köşede H piksellerini (x, y), vb. H şeklinde çizin. "
Yerel müşteri neyin güncellenmesi gerektiğinin farkında değil ve uzaktaki sistem müşterinin gerçekte neye ihtiyacı olduğu hakkında çok az bilgiye sahip; bu nedenle, temel olarak sunucu, müşterinin ihtiyaç duyabileceği veya ihtiyaç duymayabileceği çok fazla fazla bilgi göndermelidir.
Oluşturulacak ekran sınırlı sayıda basit grafik şekilden oluşuyorsa ve yalnızca düşük bir yenileme sıklığı (animasyon ve benzeri şeyler) gerekmiyorsa, bu çok etkilidir. Bu, X11'in ilk geliştirildiği günlerdeki durumdu.

Fakat modern GUI'lerin çok fazla gözü var ve bunun büyük bir kısmı uzak sistemden müşterinize çok fazla bant genişliği gerektiren bitmapler / dokular / yazı tipleri biçiminde gönderilmesi gerekiyor. Ve her çeşit göz şekeri, sık sık güncelleme gerektiren animasyon efektleri içerir. Ekranlar da daha büyük olmaya devam ediyor, iki katı geniş / yüksek, piksel sayısının 4 katı.

Elbette, zaman içinde, bunu mümkün olduğunca optimize etmek için X11 protokolünde geliştirmeler yapıldı, ancak temel dayanaklı tasarım, aslında, günümüzde beklediğimiz GUI insanlarının taleplerine uygun değil.

Diğer protokoller (RDP ve VNC gibi), uzaktaki sistemin tüm sıkı işleri yapmasına izin vermek ve sistemin hangi güncellemeleri istemciye (sıkıştırılmış bitmapler olarak) mümkün olduğunca verimli bir şekilde göndereceğine karar vermesini sağlamak için tasarlanmıştır. Genellikle bu modern GUI'ler için daha verimli olduğu ortaya çıkıyor.

Her iki yöntem de mükemmel değildir ve her durumla aynı derecede iyi başa çıkabilir. Akla gelebilecek her kullanım durumunun altında iyi bir performans sergileyen tek bir ekran protokolü yoktur.
Bu nedenle çoğu durumda yerel istemcinizle uzak sunucu arasında desteklenen tüm protokolleri denersiniz ve en iyi sonucu veren protokolü kullanırsınız. Bazı durumlarda ise başka seçenek yoktur ve sadece elinizde olanı yapmak zorundasınız.

Çoğu protokol, bazı performans ayarlarına izin verir, ancak bu ayarların çoğu yalnızca sunucu tarafındadır ve ortalama bir kullanıcı tarafından kullanılamaz. (Ve onları düzgün bir şekilde yapılandırmak biraz eğlenceliydi. Çok sayıda sys-admin bu konuda uğraşmayacak.)

Çoğu durumda, performansı iyileştirmenin en kolay yolu (bazen oldukça dramatik), daha az göz alıcı olan daha basit bir masaüstü ortamına geçmek ve arka plan görüntülerinin kullanılmasından kaçınmaktır.


15
+1 RDP ve VNC'den bahsedildiğinden beri , X11 iletmeyi gerçekten hızlandıran bir X11 önbellek / iletme çözümü olan x2go'dan da bahsetmeliyim . Geçmişte başarı ile kullandım.
Rath

7
Sonuna yakın "yalnızca sunucu tarafı ayarları" ile ilgili olarak, X sunucusunun fiziksel ekrana bağlı bilgisayarda çalıştığını hatırlayın ve X istemcisi bazı görevleri gerçekleştirmek için kullanılan yazılımdır (örneğin bir web tarayıcısı veya kelime işlemci). ). Bu nedenle, X sunucu ayarlarına, grafiksel bir uygulamayı çalıştırmak için uzaktaki sisteme bağlanan kullanıcı erişebilirdi. Bununla birlikte, bu, cevabınızın değerini önemli ölçüde azaltmamaktadır.
CVn

2
Teknik olarak protokol, VNC değil RFB'dir.
OrangeDog

6
Yanlış mıyım yoksa ikinci paragrafınızda müşteri ile sunucuyu karıştırıyor musunuz? İstemci uzaktan çalışan program, sunucu yerel makine.
Jonas Schäfer

2
Üçüncü paragrafta ele aldığınız şey, 1990'larda, X sunucularını çalıştıran makinelerin, destek deposunu mümkün kılmak için pratik bir şey haline gelmeye yetecek kadar hafızayı almaya başlamasıyla büyük ölçüde azaltıldı.
Blrfl

45

Her ikisi de sorunuzda dokunduğunuzda X11 bağlantılarının yavaş olmasının başlıca iki sebebi var: bant genişliği ve gecikme. X11 uygulamalarının neden ağ üzerinde yavaş olduğunu anlamak için, ikisini de tartışalım.

Bant genişliği

X11, varsayılan olarak, uygulama ve ekran sunucusu arasında geçen ağ verilerinde herhangi bir sıkıştırma yapmaz. Bahsettiğiniz gibi, sıkıştırmayı etkinleştirmek için SSH'deki -C seçeneğini kullanabilirsiniz ve bu yardımcı olurken, grafiksel verilerin sıkıştırılması için optimize edilmemiştir. 100 ila 1 sıkıştırma oranlarını elde edebilen H.264 gibi formatlarla karşılaştırıldığında, -C sıkıştırma 2 ila 1 sıkıştırma elde edeceği için şanslı olacaktır. Daha iyi bir çözüm, X11 videosu için grafik veya video optimize edilmiş bir codec bileşeni kullanmaktır, ancak masaüstü bilgisayarların genellikle bir filmden daha net görüntülere sahip olmaları gerekeceğinden, kullanıcının metni net bir şekilde okuyabilmesi ve ince detayları ortaya koymak.

Gecikme

X11 yüksek gecikme süresine sahip olma eğilimindedir, çünkü çoğu işlem uygulama ile ekran sunucusu arasında çoklu turlar gerektirir. Ping sürelerinin milisaniyeden daha az olduğu bir LAN üzerinden çalıştırdığınızda, bu çoklu gidişatlar farkedilmez, ancak internet bağlantısı üzerinden hızlı bir şekilde toplanırlar.

Çözümler

Birkaç yıl önce, X11 protokolünde bulunan bant genişliği ve gecikme sorunlarını gidermek için inşa edilen birkaç proje vardı. lbx (Düşük Bant Genişliği X) ve dxpc (Diferansiyel X Protokolü Kompresörü). Lbx'in çok fazla çekiş aldığını sanmıyorum, ancak dxpc, NX adlı bir ürün için kullanılan teknoloji haline geldi . NX, bant genişliği gereksinimlerini azaltmak için hem kayıplı sıkıştırma hem de yüksek gecikmeyi oluşturan ileri ve geri bilgi sayısını azaltmak için farklı bir algoritma ve önbellekleme kullanır. NX'i çok sık kullandım ve performansı neredeyse yerel uygulamalar kadar iyi buldum. Bunu hissediyorsanız, NX'i deneyebilir ve sizin için çalışıp çalışmadığını görebilirsiniz. Dezavantajı, bağlantının her iki ucuna da yazılım yüklemeyi gerektirmesidir; oysa ki X11 genellikle zaten kuruludur.


3
Gecikme konusuna bağlı olarak, X11'in çoğu akışlı video için UDP'ye karşılık TCP olacağı söylenebilir. Uzaktan çalışmaya yardımcı olacak birkaç ürün var. Tony, RDP ve VNC'den bahsetti. Oracle hala iyi çalışan Sun Global Desktop'ı (SGD) satıyor. Citrix bir şeye sahipti (XenApp?). Değerlendirmemiz SGD'yi ihtiyaçlarımız için daha iyi bir seçenek olarak buldu, ancak daha önce iki Citrix ürünü kullanmıştı.
sleepyweasel

x2go benim için çok iyi çalıştı, hatta "sunucu" ile eski bir dizüstü bilgisayar bile. birkaç dakika içinde çalışıyor ve çalışıyor ... X11 fwd'den performansımda büyük artış (benim yapılandırmayla kullanılamaz)
comte

Gecikme bilge, açık * ix makinelerinde, yerel ekranlara X11 oturumları genellikle TCP yerine Unix alan soketleri kullanır; Unix alan soketleri, localhost stackoverflow.com/questions/14973942/… adresine bile gidiş dönüşlerde TCP'den çok daha hızlıdır . Gerçekten patolojik olarak çok sayıda gidiş-dönüş turu olan X11 uygulamaları için, tamam ve gözle görülür derecede yavaş performans arasındaki fark olabilir.
rakslice
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.