Linux за българи: Форуми

Лаптоп Lenovo g50-30, Чипсет на интел и вградено интелско видео. Оказа се, че всички нови ядра включени в последно излезлите най-популярни дистрибуции а и не само, имат бъг. HD видеото в ютуб и в плеерите в произволен момент просто засича за 2-3 секунди.
Отне ми доста време да изпробвам различните дистрибуции и при всички е едно и също.
На Windows 10 няма никакви проблеми с HD, което изключи вероятността да имам хардуерен проблем. Снощи за последно реших да пробвам и със стабилния Дебиан, и О ЧУДО!  :) Хардуера работи коректно без никакви засечки. Е тук вече Дебиан ме спечели!  [_]3

Лаптоп Lenovo g50-30, Чипсет на интел и вградено интелско видео. Оказа се, че всички нови ядра включени в последно излезлите най-популярни дистрибуции а и не само, имат бъг.
Снощи за последно реших да пробвам и със стабилния Дебиан, и О ЧУДО!  :) Хардуера работи коректно без никакви засечки. Е тук вече Дебиан ме спечели!  [_]3

Ти си манна небесна за свещениците. Сигурно, поне 2-3 църкви воюват за твоята вяра.
Под "не само", сигурно имаш предвид деривати на известните със сменен тапет, но със същото ядро и драйвъри за видеото.
Провери ли, има ли друга разлика, освен ядрото между Джеси и другите, тествани от теб дистрибуции. Драйвърите за видеото, една и съща версия ли са ?

Специално за Ubuntu сега ще пробвам с lowlatency kernel и real time kernel. Пак ще пиша.

User,

ако имаш търпения изчакай да излезе Slackware 14.2 та пробвай и него. За сега е с ядро 4.4.8. Иначе това low latency или real time -- те за какво са?

Не нямаше резултат. Единствено Дебиан работи коректно. Само, че останах на KDE. Сравнено с Gnome 3.14 е доста по изпипана а и по-удобна за работа.
Ще ставам фен на Дебиан. :)

cybercop,
Освен, че ядрата са по-нови и драйверите за видеото са една идея по-нови. Не ми се вярва да е от драйверите. xorg-server на Дебиан е по стара версия а от там предполагам, че и версията на xorg драйверите за интел е една идея по-ниска.
Интересното е, че ако инсталирам примерно версията на Убунту отговаряща на версията на ядрото в Дебиан и там всичко работи добре.
Проблема ми е, че видеото съответно и звука на всеки между 3 - 4 минути засича за 2 - 3 секунди, което е дразнещо.

liquorix kernel ?

    Рапортувам :) Кубунту 14.04, KDE 4.13.3, 64 bit, Linux 3.12.0-rt2-ръчно компилиран, Pentium(R) Dual-Core  CPU    E5400  @ 2.70GHz, Nvidia GeForce 9600 GT,NVIDIA-CURRENT  Driver Version: 304.131,
      Creative X-Fi Xtreme Music
     
На клипове по 4.22 мин с Google Chrome на www.youtube.com-не засича

    На клипове по 4.22 мин с VLC-Cntr-N-отваряне на мрежов поток на www.youtube.com-не  засича

   VLC-изхода е на QjackCtl, който работи на семплираща честота 176400, латенция 1.45 msec

    да, гледал съм и дълги видеа-не помня да е имало засичания

   и в двата случая няма грижи, още ме мързи, да компилирам нов кернел

    Рапортувам :) Кубунту 14.04, KDE 4.13.3, 64 bit, Linux 3.12.0-rt2-ръчно компилиран, Pentium(R) Dual-Core  CPU    E5400  @ 2.70GHz, Nvidia GeForce 9600 GT,NVIDIA-CURRENT  Driver Version: 304.131,
      Creative X-Fi Xtreme Music
     
На клипове по 4.22 мин с Google Chrome на www.youtube.com-не засича

    На клипове по 4.22 мин с VLC-Cntr-N-отваряне на мрежов поток на www.youtube.com-не  засича

   VLC-изхода е на QjackCtl, който работи на семплираща честота 176400, латенция 1.45 msec

    да, гледал съм и дълги видеа-не помня да е имало засичания

   и в двата случая няма грижи, още ме мързи, да компилирам нов кернел

Аз работя само със стандартни ядра и никога не ми е засичало и с тях. Имало е проблемни драйвъри за видеото - примерно, този за интелски видеокарти с Убунту 14.10.
Защо не ползваш 4.14 LTS или щатното за Xenial (4.4.ХХ), което е достъпно в хранилищата на Trusty.
3.12 е доста странен избор.

просто с ръчно компилираното се усеща прираст в производителноста, а на мен от време на време ми трябва да съм на максимум...

просто с ръчно компилираното се усеща прираст в производителноста, а на мен от време на време ми трябва да съм на максимум...

Аз пък страдам от липса на въображение и все не мога да усетя тоя прираст на производителност. Нито пък виждам откъде ще ми дойде. Това, че ще орежа модулите с нищо няма да промени положението. А, услугите и без това са ми орязани до крайност.

Между другото много хора са ми казвали, че много добре я виждат тази увеличена производителност, сто на сто някой е правил подробни тестове на тази тема.

Между другото много хора са ми казвали, че много добре я виждат тази увеличена производителност, сто на сто някой е правил подробни тестове на тази тема.

Не съм писал никъде, че, всички хора са с бедна фантазия, като моята.
Преди години, критерия за разпознаване на начинаещи Linux потребители бяха два израза, които често употребяваха - "Прекомпилирано ядро" и "бъгаво Ubuntu". Чули бяха нещо и го повтаряха, като папагалчета с надеждата да се издигнат в очите на останалите.
Ядрото се компилира, когато се налага. Примерно, за да зададеш специфични параметри за гейм сървъри. Последния път, когато компилирах, машината беше стара и ми отне 4 часа. След 3 дни, когато открият няколко уязвимости и се налага актуализация, отново ли ще компилираш ? Докато нещо се обърка и се наложи да преинсталираш. За мен, по - добро ядро от щатното (generic), поддържано от издателя на дистрибуцията няма. От години, ползвам само такива и никога не съм имал, какъвто и да е проблем, причинен от ядрото. http://s19.postimg.org/bnos0c3xt/linux_generic.png ($2)

Когато щатното не отговаря на специфични нужди, тогава се търси друго или се компилира.

Цитат на: ЗевсБг в May 03, 2016, 16:33

просто с ръчно компилираното се усеща прираст в производителноста, а на мен от време на време ми трябва да съм на максимум...

Аз пък страдам от липса на въображение и все не мога да усетя тоя прираст на производителност. Нито пък виждам откъде ще ми дойде. Това, че ще орежа модулите с нищо няма да промени положението. А, услугите и без това са ми орязани до крайност.

Идва оттам че го компилираш оптимизирано за процесора ти (дали ще е да се ползват SIMD разширения като SSE2/3/4 или AVX, дали ще генерира по-оптимален код спрямо това което компилаторът знае за латентност на инструкции на конкретния процесор, където може да замести някоя инструкция с друга или комбинация, дето са по-бързи, дали ще има правилни предположения за cacheline и alignment, дали ще достъпва паметта по-оптимално с оглед на процесорните кешове по-ефективно). Пребилднатите ядра в репата на дистрибуциите обикновено са компилирани за generic x86 или x86_64 таргет, така че да вървят на максимално множество от системи (SSE4 инструкция би изгърмяла на по-стар процесор примерно) и тези оптимизации там съответно ги няма.

Друг е въпроса че файдата от всичко това е маргинална, освен обикновено в разни частни/гранични случаи или при високо натоварване. А и работата, която ядрото извършва е предимно I/O-интензивна, а не CPU-интензивна така или иначе.

Същото е и с изключването на разни подсистеми и модули - в частни случаи може да спести доста процесорни тактове, в общият случай няма особено значение. За десктоп система за общо ползване, обикновено няма никакво значение.

P.S за да изпреваря въпроса "дай ми пример", простият банален пример е с conntracking-а в ядрото, който в общи линии ти дава възможността да си правиш NAT и/или stateful firewall там с iptables. Като го изключиш, печелиш одма поне едни 50% по-ниска латентност при обслужването и рутирането на всеки TCP пакет просто защото не ходи да рови в разни таблици, които може да са в процесорния кеш, може да не са, ако не са, хабиш стотици процесорни тактове, докато се достави, а conntrack таблицата може да стане брутално голяма с времето и при подходящно натоварване. Ако просто ползваш машината за да браузваш и да гледаш видео в youtube, няма никакво значение. Ако я ползваш обаче като рутер, при прилично натоварване, машината ще се сгъне и ще откаже да търкаля повече трафик, отделно jitter-а ще е неприлично голям.

Обаче айде това не е добър пример, защото може да се билдне като като модул и при добро желание може да го разкараш. Но все още има прилично много неща, които не стават точно така.


Bottom line: повечето хора които прекомпилират ядра и твърдят че вървят по-бързо, обикновено не могат да дефинират кое точно е по-бързо. Чисто теоретично е по-бързо и в определени случаи това "по-бързо" може да е с порядъци. Userland-а е достатъчно сложен, начините на ползването му - също. Може това дето да е по-бързо да е абсолютно ирелевантно, примерно да речем като отвориш видео в някой плеър оттам до възпроизвеждането да минат 50 вместо 200 милисекунди и аха изглежда като подобрение, обаче на човек изначално му е трудно да идентифицира кое точно му изглежда по-бързо.

Те затова такива спорове са тъпи, първо защото не може да се конкретизира върху конкретен проблем и второ, дори това да е налице, profile-ването на цялата работа е достатъчно досадно занимание, а пък точно оттам евентуално ще дойдат твърдите "числа" дето да докажат нещо.

Това казано, за x86 не съм ползвал прекомпилирани ядра от сигурно едно 10 години, просто защото не виждам нужда. За ARM признавам сме билдвали custom ядра, но на старата работа, не за мои си неща. Компилирането на ядра е ужасно досадна работа, аз сигурно съм прост обаче не ми се получава добре от първия път, обикновено не и от втория и третия, евентуално след един месец се сещам поради някаква причина че не ми се е получило пак и отново, часове потрошено процесорно време и електроенергия, майката природа не се кефи на такъв зъл carbon footprint нали така.

P.S за да изпреваря въпроса "дай ми пример"

Изобщо няма да задавам никакви въпроси. Напълно съм съгласен с теб. Нищожното повишение на прозводителността върху десктроп машина, което може и а не се постигне ще бъде "изядено" само от един допълнителен процес - примерно включен мениджър на актуализациите в Kubuntu-то на колегата. Или mint-updater, който, поне до преди няколко години беше изключително лакомо приложение. И, това не може да компенсира неудобството от непрекъснатото компилиране и риска, който произтича от това. Компилиране, черен екран, конфигуриране на видео, компилиране, черен екран, ...преинсталация.
Трябва да си истински магьосник или по- скоро луд гении (акцента е върху луд) за да изкараш в този режим десет годишния цикъл на поддръжка на CENTOS. А, там кърпят старичкото 2.32 много често, защото основната ми офис машина е под шестицата и имам наблюдения.

Затова съм написал мнението си в едно изречение - ядро се компилира, когато е необходимо.

     cybercop, gat3way-благодаря Ви за отговорите, между другото навремето като компилирах Linux 3.12.0-rt2, спрямо стария компилиран кернел имаше подобрение във звука!

     Ще пробвам да инсталирам нов кернел спрямо тези инструкции- https://capocasa.net/realtime-kernels , пък ще видя, чуя какво ще стане!

Ако си на 64бит архитектура, едва ли изобщо ще се усети някаква разлика. Едно време имаше големи архитектурни промени в процесорите- добавяха нови инструкции, регистри. Сега Интел прави само козметики, оптимизации и вдигане броя на ядрата.

     cybercop, gat3way-благодаря Ви за отговорите, между другото навремето като компилирах Linux 3.12.0-rt2, спрямо стария компилиран кернел имаше подобрение във звука!

     Ще пробвам да инсталирам нов кернел спрямо тези инструкции- https://capocasa.net/realtime-kernels , пък ще видя, чуя какво ще стане!

Не зная за язрото, но според мен то е най-малкия фактор, специално за звука.
Например, когато пусна да се продвири някоя мр3-ка през pygame, доста звучи осезаемо по-добре, отколкото през разни графични плеъри

Ако си на 64бит архитектура, едва ли изобщо ще се усети някаква разлика. Едно време имаше големи архитектурни промени в процесорите- добавяха нови инструкции, регистри. Сега Интел прави само козметики, оптимизации и вдигане броя на ядрата.

И сега има. AVX512 примерно с 512-битовите SIMD регистри и съответно нови 16 xmm регистъра. Или разширенията за транзакционна памет.

Ммм другият момент според мен идва оттам че ядрата от сорс можеш да ги билдваш с по-нови версии на gcc, отколкото пакетираните - а в тях съответно може да има подобрения по оптимизациите, подобрения по генерирания код за архитектурата и т.н. Но със съшият успех може да има и регресии, които генерират бъглив код :)

Проблема за който писах със сигурност е от ядрото. Предполагам, че проблема го имат всички ядра версия 4 и нагоре. Проблема се забелязва във всички дистрибуции. Не знам дали е бъг или на какво точно се дължи. След като инсталирах на jessie от backports ядро 4.5 и хоп проблема се появи отново.

Моля някои експерт за помощ.

Имам проблем с микрофона. За да работи на Убунту инсталирвах pavucontrol и на секцията "вход" за микрофона намалях до край единия канал и работеше. Иначе микрофона ми не е стерео.
При същата стъпка на Дебиан нищо не се случва а и pavucontrol не си пази настройките или по скоро Gnome не ги приема.
С quasmixer като намаля единия канал микрофона работи но бутна ли нещо по вградения миксер на Gnome или restart, logaut, астройката се губи.

Интересното е, че с KDE няма подобни проблеми.

Иначе такъв масов проблем в линукс ядрото е доста обезпокоителен. Кара ме доста да се дразня от този факт. Още един доста сериозен минус за отворения код.
Все пак лаптопа е съвременен модел а и факта, че на вин10 няма абсолютно никакви хардуерни проблеми е достатъчно красноречив.

Какво ще се случи ако не е 8 (Джеси), ами някой батко? Так де, на чисто ново - чисто ново.

Проблема за който писах със сигурност е от ядрото. Предполагам, че проблема го имат всички ядра версия 4 и нагоре. Проблема се забелязва във всички дистрибуции. Не знам дали е бъг или на какво точно се дължи. След като инсталирах на jessie от backports ядро 4.5 и хоп проблема се появи отново.

Моля някои експерт за помощ.

Имам проблем с микрофона. За да работи на Убунту инсталирвах pavucontrol и на секцията "вход" за микрофона намалях до край единия канал и работеше. Иначе микрофона ми не е стерео.
При същата стъпка на Дебиан нищо не се случва а и pavucontrol не си пази настройките или по скоро Gnome не ги приема.
С quasmixer като намаля единия канал микрофона работи но бутна ли нещо по вградения миксер на Gnome или restart, logaut, астройката се губи.

Интересното е, че с KDE няма подобни проблеми.

Пишеш, че нямаш проблеми с видеото в Debian 8. Сложи си Debian с Xfce и виж, там как е звука. По подразбиране си само с Alsa. Ако инсталираш Pulseaudio, нямаш нужда от Pavucontrol, защото миксера позволява настройване и на Pulseaudio изхода. Само трябва да ги избереш от настройките на миксера.
Между другото - процесорът ти е кошмарен. Този тип са най- лошите, които са произведени през последните пет години.

Иначе такъв масов проблем в линукс ядрото е доста обезпокоителен. Кара ме доста да се дразня от този факт. Още един доста сериозен минус за отворения код.
Все пак лаптопа е съвременен модел а и факта, че на вин10 няма абсолютно никакви хардуерни проблеми е достатъчно красноречив.

не сериозен минус е за производителя на чипа за звук, защото не се е погрижил за драйвера му, спираш да купуваш хардуер от този производител и си решаваш проблема.

Както вече писах проблема е само в по-новите ядра, и не засяга само звука а и видеото. Каква е логиката проблема да е в производителя на хардуера?

Както вече писах проблема е само в по-новите ядра, и не засяга само звука а и видеото. Каква е логиката проблема да е в производителя на хардуера?

Едва ли е в производителя на хардуера. По- скоро е от поддръжката на този хардуер в новите ядра.
Остава въпроса, защо при един и същи драйвър имаш проблеми с две различни ядра. Разбираемо ще бъде, ако драйвърът е фирмен и се налага ново конфигуриране.
Щом нямаш проблем с 3.16 Jessie, значи нямаш грижи. Debian 8 ще се поддържа още 3 години, CENTOS 7 с ядро 3.10 още 8 или 9, а в Ubuntu, можеш да ползваш 3.13 Trusty или 3.14 LTS от Ubuntu kernel, което си е доста сериозно ядро.
Би ли изпълнил три команда и да публикуваш изходите ?
lsusb
lspci
uname -a
както и да ми кажеш, какво не работи в момента.

Всичко работи на 6 останах си с KDE. 
Приятно съм изненадан от пакетите, които има в backports, особено на новата версия на libreoffice. Инсталирах и последния smplayer, както и clmentine 1.3, също firefox 46
Какво му трябва повече на човек.  8)
Макар хардуера ми да е слаб клиповете в ютуб работят на full hd без засечки. :)

Инсталирах и последния smplayer, както и clmentine 1.3, също firefox 46

MPlayer е важно да е нов. Обвивка, като SMPlayer, можеш да ползваш и на 5-6 години. Аз още ползвам периодично един стар UMPlayer, който си пазя на флашката. Въпреки гръмките имена, това не са истински плеъри, а, само една декорация. Потребителски интерфейси за работа с Mplayer.

Последната версия на Calculate Linux 15.17 с ядро 4.4.9 и xorg-server 1.17.4 работи безупречно. Системата сама си генерира собствен xorg.conf, като в него съм добавил само Option "TearFree"

Debian е с доста по-старо ядро и xorg-server 1.16.4 и там проблеми няма.
Всички други последни издания на популярните дистрибуции, съответно с различни версии на ядрата и xorg-xserver са проблемни за моята конфигурация.

Правил съм тестове на OpenSuse, Fedora, ROSA, всякакви версии на Ubuntu. Учудващо но проблеми има дори на LMDE, която е базирана на Debian jessie.

Правете си изводите сами. Явно проблема не е нито във версията на ядрото, нито във версията на xorg-xserver. Пробвал съм и с различни версии на драйвера за видеото.

Първо трябва да бъде "TearFree" "true". Препоръчително е xorg.conf вече да не се използва, иначе може да се генерира ръчно

GeSHi (Bash):
sudo Xorg :2 -configure
sudo mv /root/xorg.conf.new /etc/X11/xorg.conf

Може да ползваш, която дистрибуция ти е удобна и да си направиш сам настройките, ако не са направени по подразбиране. Освен това в Plasma errata https://community.kde.org/Plasma/5.5_Errata пише, че sna е "бъгаво" (не знам дали все още е валидно)

Благодаря за забележката, пропуснал съм "true".
Иначе съм съгласен, логиката от всичките ми тестове е, че ако ползвам същия xorg.conf в друга дистрибуция би трябвало да нямам проблеми.
Не съм забелязал бъгове при ползването на "sna".

Всъщност от КДЕ пишат това:

"Random application crashes

This issue is caused by a driver bug. A reported workaround is to change AccelMethod to UXA in the xorg configuration and restarting the system. Please refer to documentation provided by your distribution on how to change this."