Вопросы Теги

Понимание, почему такое несоответствие в сетевой передаче?

.xinitrc exectued, когда Вы явно работаете xinit (startx в конечном счете вызовы xinit) запускать X-сервер. Главным образом этого не происходит, поскольку текущие Linux используют среды рабочего стола, какие diretly запускают X-сервер и затем работают /etc/X11/Xsession <desktopenvironment>, где <desktopenvironment> значение любой строки Exec= из файла в /usr/share/xsessions, например,

Exec=startxfce4

если Вы выбрали XFCE как sessiontype.

По крайней мере, на Debian основывал системы сценарии в /etc/X11/Xsession.d/ получены (!) в порядке. Главным образом все эти сценарии настроенный материал и/или изменяют переменную STARTUP который в конечном счете используется в строке

exec $STARTUP

Так технически Вы могли записать a /usr/share/xsession/xinitrc.desktop файл, который позволяет Вам выбрать сессию, которая будет работать ~/.xinitrc.

5
20.03.2015, 15:32
1 ответ

Я могу только дать предположение, что Составлено, что расхождение объясняется различной вычислительной памятью, памятью, кэшированием или дисковыми характеристиками двух хозяев:

  • Если мы предположим, что ЦП - это узкое место, то это будет иметь некоторое смысл, если медленная машина была медленнее на отправку (это предполагает что шифрование более вычислительно тяжело, чем дешифрование). Это может быть проверено путем переключения на шифр, который является легче, чтобы вычислить (попробуйте добавить -C ArcFour в вашу командную строку SSH; в этом случае прохождение - RSH = "SSH -C Arcfour" rsync ).

  • Если мы предполагаем, что файлы прочитаны / записываются прямо с / на диск, то диск может быть возможным быть узким местом; Скорости чтения из 100 Мбит / с имеют в пределах досягаемости более современных компьютеров, но не старые, или компьютеры, работающие на дисках класса ноутбуков (например, я полагаю, Mac Mini).

  • Если мы далее предположим, что операционная система использует файловые системы кэши, ситуация может быть дополнительно усложнена:

    • Если исходный файл содержится в кэше файловой системы, в оперативной памяти, то он может быть прочитан намного быстрее, чем 100 Мбит / с;

    • Если целевая система применяет кэширование записи и может соответствовать значительной части файла в оперативной памяти (в вашем случае должно быть, поскольку RAM намного больше, чем ваш тестовый файл), то он может претендовать на запись Заполните до того, как он действительно достиг диска (это может означать, что ваши измеренные 200 Мбит / с).

Неизвестный диск-кэш-кэш может быть протестирован путем промывки кэша файловой системы перед чтением (как это сделать это ОС-зависимое): затем отправка файла будет по крайней мере так же медленным, как диктурный диск. И наоборот, читая файл полностью перед отправкой (возможно, с CAT File.bin> / dev / null ), можно повлиять на ОС в кэширование.

Для дальнейшего изучения того, является вопросом CPU, это имеет смысл пробежать TOP , когда передача продолжается; Если RSYNC или процесс SSH принимает 100% ядра, то это будет узкое место.

3
27.01.2020, 20:41

Теги

Похожие вопросы