Je me permets de vous soumettre le problème que je rencontre sur une
nouvelle machine, après avoir essayé une série de choses qui ne le
résolvent pas, en espérant que quelqu'un aurait une expérience utile
en la matière, ou déjà une idée ou deux :-)
La machine est un NUC Intel, modèle NUC7i3DNKE.
Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02)
Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est
couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual
Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x
2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz).
Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un
serveur LTSP en NFS, mais l'aspect LTSP est indifférent.
Question OS, a priori tout est du stretch pur jus, à jour (donc tant
le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le
NUC).
Le souci rencontré est que les écrans clignotent de temps en temps :
ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes,
voire parfois 4-5, et puis se rallument...
Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et
puis avec le microcode Intel (avec, ça améliore sensiblement les
choses, bien que ça ne soit pas encore parfait), pour finir enfin en
buster, avec le noyau 4.14.
Toujours avec le microcode, les résultats varient en fonction de la
version du noyau : avec le 4.9 de stretch, c'est inutilisable
tellement ça clignote. C'est un poil mieux avec le 4.14 des backports,
toujours en stretch et ça devient utilisable, mais encore gênant avec
le 4.14 de buster.
Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau
4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau
désactive une partie du microcode Intel en signalant qu'il ne résout
pas Spectre (j'ai oublié les termes exacts, mais le microcode est
pourtant la dernière version de chez Intel : 20171117).
Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes
graphiques modesetting et Intel. On ne peut toutefois pas dire que ça
fait une différence notable de comportement, et comme modesetting est
recommandé et semble (mais c'est subjectif) un poil plus rapide à
l'affichage, je tourne avec ce pilote, sous buster pour le moment.
Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière
version (039) du 22/02/2018.
Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les
clignotements persistent quand même encore, sur l'un ou l'autre des
écrans, au point que j'hésite à laisser ça comme poste de travail en
l'état...
Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout
à fait pareil ; les connecteurs sont bien vissés aux écrans, etc.
Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint
puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis
plus rien pendant un moment, etc.
Les seuls constats qui semblent pouvoir être posés sont :
- que le phénomène ne semble jamais se produire quand l'écran change
en permanence : en lançant xscreensaver ou un film, je ne l'ai
jamais surpris à s'éteindre de manière inexpliquée. C'est quand
l'image est fixe, mais qu'on tape du texte ou non, ça le fait ;
- que l'écran qui n'a pas le focus *semble* s'exciter davantage que
celui qui contient la fenêtre où je tape ceci, mais c'est difficile
d'en être sûr...
Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à
partager ou ne fut-ce qu'une idée de piste à explorer, je suis
preneur :-)
Je vous remercie d'avance, en tout cas de m'avoir lu.
[...] Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis preneur parce que j'y perds mes pingouins pour le moment :-) Je remercie aussi encore ceux qui se sont penchés sur le problème. A+
Bonjour, Le bios ne comporte pas d'options qui aideraient ? Sinon, toutes les tentatives le sont en ltsp ? Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ? Comment être certain que le standard est respecté ou compatible sur le câble dvi/hdmi ? Bon courage, -- Christophe De Natale
Le 05/03/2018 à 18:26, JF Straeten a écrit :
[...]
Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis
preneur parce que j'y perds mes pingouins pour le moment :-)
Je remercie aussi encore ceux qui se sont penchés sur le problème.
A+
Bonjour,
Le bios ne comporte pas d'options qui aideraient ?
Sinon, toutes les tentatives le sont en ltsp ?
Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ?
Comment être certain que le standard est respecté ou compatible sur le
câble dvi/hdmi ?
[...] Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis preneur parce que j'y perds mes pingouins pour le moment :-) Je remercie aussi encore ceux qui se sont penchés sur le problème. A+
Bonjour, Le bios ne comporte pas d'options qui aideraient ? Sinon, toutes les tentatives le sont en ltsp ? Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ? Comment être certain que le standard est respecté ou compatible sur le câble dvi/hdmi ? Bon courage, -- Christophe De Natale
Bernard Schoenacker
------=_Part_115013808_1087981901.1520273750590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable bonjour, serait il possible de faire un essai avec x2go server et x2go client (pyHoca) ? sources.list en pièce jointe lien : https://wiki.x2go.org/doku.php slt bernard ------=_Part_115013808_1087981901.1520273750590 Content-Type: application/octet-stream; name=x2go.list Content-Disposition: attachment; filename=x2go.list Content-Transfer-Encoding: base64 CiMgWDJHbyBSZXBvc2l0b3J5IChyZWxlYXNlIGJ1aWxkcykKIyBkZWIgICAgIGh0dHA6Ly9wYWNr YWdlcy54MmdvLm9yZy9kZWJpYW4gamVzc2llIG1haW4KICBkZWIgICAgIGh0dHA6Ly9wYWNrYWdl cy54MmdvLm9yZy9kZWJpYW4gc3RyZXRjaCBtYWluICBoZXVsZXIKICBkZWItc3JjIGh0dHA6Ly9w YWNrYWdlcy54MmdvLm9yZy9kZWJpYW4gc3RyZXRjaCBtYWluICBoZXVsZXIKICBkZWIgICAgIGh0 dHA6Ly9wYWNrYWdlcy54MmdvLm9yZy9kZWJpYW4gc2lkIG1haW4KCiMgIGFwdC1rZXkgYWR2IC0t cmVjdi1rZXlzIC0ta2V5c2VydmVyIGtleXMuZ251cGcubmV0IEUxRjk1ODM4NUJGRTJCNkUK ------=_Part_115013808_1087981901.1520273750590--
------=_Part_115013808_1087981901.1520273750590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable bonjour, serait il possible de faire un essai avec x2go server et x2go client (pyHoca) ? sources.list en pièce jointe lien : https://wiki.x2go.org/doku.php slt bernard ------=_Part_115013808_1087981901.1520273750590 Content-Type: application/octet-stream; name=x2go.list Content-Disposition: attachment; filename=x2go.list Content-Transfer-Encoding: base64 CiMgWDJHbyBSZXBvc2l0b3J5IChyZWxlYXNlIGJ1aWxkcykKIyBkZWIgICAgIGh0dHA6Ly9wYWNr YWdlcy54MmdvLm9yZy9kZWJpYW4gamVzc2llIG1haW4KICBkZWIgICAgIGh0dHA6Ly9wYWNrYWdl cy54MmdvLm9yZy9kZWJpYW4gc3RyZXRjaCBtYWluICBoZXVsZXIKICBkZWItc3JjIGh0dHA6Ly9w YWNrYWdlcy54MmdvLm9yZy9kZWJpYW4gc3RyZXRjaCBtYWluICBoZXVsZXIKICBkZWIgICAgIGh0 dHA6Ly9wYWNrYWdlcy54MmdvLm9yZy9kZWJpYW4gc2lkIG1haW4KCiMgIGFwdC1rZXkgYWR2IC0t cmVjdi1rZXlzIC0ta2V5c2VydmVyIGtleXMuZ251cGcubmV0IEUxRjk1ODM4NUJGRTJCNkUK ------=_Part_115013808_1087981901.1520273750590--
daniel huhardeaux
Le 06/03/2018 à 11:39, daniel huhardeaux a écrit :
[...] Je pense qu'un rapport de bug s'impose
En fait non. Je viens de faire le test sous W8.1 c'est encore pire: le phénomène apparaît toutes les 3 secondes, peu importe que quelque chose soit affiché ou non. -- Daniel
Le 06/03/2018 à 11:39, daniel huhardeaux a écrit :
[...]
Je pense qu'un rapport de bug s'impose
En fait non. Je viens de faire le test sous W8.1 c'est encore pire: le
phénomène apparaît toutes les 3 secondes, peu importe que quelque chose
soit affiché ou non.
Le 06/03/2018 à 11:39, daniel huhardeaux a écrit :
[...] Je pense qu'un rapport de bug s'impose
En fait non. Je viens de faire le test sous W8.1 c'est encore pire: le phénomène apparaît toutes les 3 secondes, peu importe que quelque chose soit affiché ou non. -- Daniel
Yann Serre
Oui, c'est pour cette famille de panne que j'ai fait remonter une remarque sur 6 Samsung 244T dont 4 qui se sont mis à clignoter dans le même trimestre. Une bonne adresse parisienne de composants électroniques a identifié un circuit intégré à changer sur les Samsung suite à un bouche à oreille de clients. Mais comme ces écrans consomment beaucoup, j'ai préféré les changer sans faire la réparation. Le 06/03/2018 à 12:22, daniel huhardeaux a écrit :
En fait non. Je viens de faire le test sous W8.1 c'est encore pire: le phénomène apparaît toutes les 3 secondes, peu importe que quelque chose soit affiché ou non.
Oui, c'est pour cette famille de panne que j'ai fait remonter une
remarque sur 6 Samsung 244T dont 4 qui se sont mis à clignoter dans le
même trimestre. Une bonne adresse parisienne de composants électroniques
a identifié un circuit intégré à changer sur les Samsung suite à un
bouche à oreille de clients. Mais comme ces écrans consomment beaucoup,
j'ai préféré les changer sans faire la réparation.
Le 06/03/2018 à 12:22, daniel huhardeaux a écrit :
En fait non. Je viens de faire le test sous W8.1 c'est encore pire: le
phénomène apparaît toutes les 3 secondes, peu importe que quelque chose
soit affiché ou non.
Oui, c'est pour cette famille de panne que j'ai fait remonter une remarque sur 6 Samsung 244T dont 4 qui se sont mis à clignoter dans le même trimestre. Une bonne adresse parisienne de composants électroniques a identifié un circuit intégré à changer sur les Samsung suite à un bouche à oreille de clients. Mais comme ces écrans consomment beaucoup, j'ai préféré les changer sans faire la réparation. Le 06/03/2018 à 12:22, daniel huhardeaux a écrit :
En fait non. Je viens de faire le test sous W8.1 c'est encore pire: le phénomène apparaît toutes les 3 secondes, peu importe que quelque chose soit affiché ou non.
JF Straeten
Salut, On Mon, Mar 05, 2018 at 07:15:50PM +0100, Bernard Schoenacker wrote:
serait il possible de faire un essai avec x2go server et x2go client (pyHoca) ? sources.list en pièce jointe lien : https://wiki.x2go.org/doku.php
Je peux si j'ai le temps, mais tu voudrais mettre quoi de particulier en évidence avec ce test ? J'ai déjà voulu tester ça par ailleurs, donc ce ne serait pas du temps totalement perdu ;) Mais ça s'installe facilement sur une Debian ? Y a pas de paquets Debian, à ce que j'ai vu... Merci & A+, -- JFS.
Salut,
On Mon, Mar 05, 2018 at 07:15:50PM +0100, Bernard Schoenacker wrote:
serait il possible de faire un essai avec x2go server
et x2go client (pyHoca) ?
sources.list en pièce jointe
lien :
https://wiki.x2go.org/doku.php
Je peux si j'ai le temps, mais tu voudrais mettre quoi de particulier
en évidence avec ce test ?
J'ai déjà voulu tester ça par ailleurs, donc ce ne serait pas du temps
totalement perdu ;)
Mais ça s'installe facilement sur une Debian ? Y a pas de paquets
Debian, à ce que j'ai vu...
Salut, On Mon, Mar 05, 2018 at 07:15:50PM +0100, Bernard Schoenacker wrote:
serait il possible de faire un essai avec x2go server et x2go client (pyHoca) ? sources.list en pièce jointe lien : https://wiki.x2go.org/doku.php
Je peux si j'ai le temps, mais tu voudrais mettre quoi de particulier en évidence avec ce test ? J'ai déjà voulu tester ça par ailleurs, donc ce ne serait pas du temps totalement perdu ;) Mais ça s'installe facilement sur une Debian ? Y a pas de paquets Debian, à ce que j'ai vu... Merci & A+, -- JFS.
JF Straeten
Salut, On Mon, Mar 05, 2018 at 06:59:51PM +0100, Christophe De Natale wrote: [...]
Le bios ne comporte pas d'options qui aideraient ?
Je n'ai rien vu de sexy par rapport à mon problème, même si je conviens que c'est très zoli, le Visual Bios d'Intel. J'ai essayé d'augmenter et de diminuer la taille de la RAM centrale affectée à l'IGP, pour voir, mais sans succès...
Sinon, toutes les tentatives le sont en ltsp ?
Oui : la machine est appelée à faire office de client léger et tous les boots le sont en NFS sur des chroot LTSP (passer d'un à l'autre est beaucoup plus rapide que de faire des installs locales évidemment).
Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ?
Et bien, tu n'as pas tort et j'en viens à me dire que le test du live-cd peut être intéressant. Si j'y arrive, j'essayerai ça ce soir, entre choses comme changer les câbles, essayer d'autres sorties, ou sur un projo, etc... Parce que quand on y pense... En LTSP, c'est le client léger qui lance le serveur X et le serveur LTSP vient présenter une session dessus. Peut-être qu'il y a une interaction problématique ? Actuellement, ils tournent tous avec LDM_DIRECTX=true, c.-à-d. que la connexion entre client et serveur n'est pas chiffrée par SSH. Mais je pourrais aussi essayer en chiffrant pour voir si ça fait une différence... Ceci dit, je me souviens qu'au moment de flasher le bios, la clé USB insérée avec le fichier .BIO dessus contenait l'installateur de stretch, lequel s'est lancé parce que je n'ai pas tapé assez vite sur F7 pour flasher... L'affichage n'a pas duré longtemps, certes, mais il ne clignotait pas. Serait-ce une piste ? Les résolutions d'affichage sont quand même très différentes et ça ne le fait peut-être qu'en sollicitant un peu la carte ? Si je sais, je retesterai tiens.
Comment être certain que le standard est respecté ou compatible sur le câble dvi/hdmi ?
Ah ça bien sûr... Je ne peux que faire confiance aux câbles que j'ai. Mais la question est pertinente parce que ce sont les deux mêmes, achetés en même temps, et neufs, donc par définition non testés ou du moins on n'en a pas de preuve... Si ça se trouve, ils viennent d'un même lot qui pourrait être défectueux ? En outre, je me suis fait la réflexion en les ouvrant que le fabricant ne s'est pas foulé sur le blindage, vu la taille du câble ; en tout cas par rapport à mes purs DVI-D d'avant, y a pas photo : la section et la "dureté" du câble sont moindres, peut-être même nettement.
Bon courage,
Merci ;) Ça devient surtout le temps, le problème. Ces tests sont chronophages à mort et d'autres trucs n'avancent pas, alors que je m'attendais à swaper simplement les machines et à pointer la macaddress de la nouvelle sur le bon chroot dans le DHCP. Là, c'est raté du coup :-[ Mais merci à tous les intervenants de la liste sur le problème ; c'est précieux dans l'adversité numérique ;) A+ -- JFS.
Salut,
On Mon, Mar 05, 2018 at 06:59:51PM +0100, Christophe De Natale wrote:
[...]
Le bios ne comporte pas d'options qui aideraient ?
Je n'ai rien vu de sexy par rapport à mon problème, même si je
conviens que c'est très zoli, le Visual Bios d'Intel.
J'ai essayé d'augmenter et de diminuer la taille de la RAM centrale
affectée à l'IGP, pour voir, mais sans succès...
Sinon, toutes les tentatives le sont en ltsp ?
Oui : la machine est appelée à faire office de client léger et tous
les boots le sont en NFS sur des chroot LTSP (passer d'un à l'autre
est beaucoup plus rapide que de faire des installs locales
évidemment).
Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ?
Et bien, tu n'as pas tort et j'en viens à me dire que le test du
live-cd peut être intéressant. Si j'y arrive, j'essayerai ça ce soir,
entre choses comme changer les câbles, essayer d'autres sorties, ou
sur un projo, etc...
Parce que quand on y pense... En LTSP, c'est le client léger qui lance
le serveur X et le serveur LTSP vient présenter une session dessus.
Peut-être qu'il y a une interaction problématique ?
Actuellement, ils tournent tous avec LDM_DIRECTX=true, c.-à-d. que la
connexion entre client et serveur n'est pas chiffrée par SSH. Mais je
pourrais aussi essayer en chiffrant pour voir si ça fait une
différence...
Ceci dit, je me souviens qu'au moment de flasher le bios, la clé USB
insérée avec le fichier .BIO dessus contenait l'installateur de
stretch, lequel s'est lancé parce que je n'ai pas tapé assez vite sur
F7 pour flasher... L'affichage n'a pas duré longtemps, certes, mais il
ne clignotait pas. Serait-ce une piste ? Les résolutions d'affichage
sont quand même très différentes et ça ne le fait peut-être qu'en
sollicitant un peu la carte ? Si je sais, je retesterai tiens.
Comment être certain que le standard est respecté ou compatible sur
le câble dvi/hdmi ?
Ah ça bien sûr... Je ne peux que faire confiance aux câbles que j'ai.
Mais la question est pertinente parce que ce sont les deux mêmes,
achetés en même temps, et neufs, donc par définition non testés ou du
moins on n'en a pas de preuve... Si ça se trouve, ils viennent d'un
même lot qui pourrait être défectueux ?
En outre, je me suis fait la réflexion en les ouvrant que le fabricant
ne s'est pas foulé sur le blindage, vu la taille du câble ; en tout
cas par rapport à mes purs DVI-D d'avant, y a pas photo : la section
et la "dureté" du câble sont moindres, peut-être même nettement.
Bon courage,
Merci ;)
Ça devient surtout le temps, le problème. Ces tests sont chronophages
à mort et d'autres trucs n'avancent pas, alors que je m'attendais à
swaper simplement les machines et à pointer la macaddress de la
nouvelle sur le bon chroot dans le DHCP. Là, c'est raté du coup :-[
Mais merci à tous les intervenants de la liste sur le problème ; c'est
précieux dans l'adversité numérique ;)
Salut, On Mon, Mar 05, 2018 at 06:59:51PM +0100, Christophe De Natale wrote: [...]
Le bios ne comporte pas d'options qui aideraient ?
Je n'ai rien vu de sexy par rapport à mon problème, même si je conviens que c'est très zoli, le Visual Bios d'Intel. J'ai essayé d'augmenter et de diminuer la taille de la RAM centrale affectée à l'IGP, pour voir, mais sans succès...
Sinon, toutes les tentatives le sont en ltsp ?
Oui : la machine est appelée à faire office de client léger et tous les boots le sont en NFS sur des chroot LTSP (passer d'un à l'autre est beaucoup plus rapide que de faire des installs locales évidemment).
Pas moyen d'essayer en plus "direct" (live-cd ou clé bootable) ?
Et bien, tu n'as pas tort et j'en viens à me dire que le test du live-cd peut être intéressant. Si j'y arrive, j'essayerai ça ce soir, entre choses comme changer les câbles, essayer d'autres sorties, ou sur un projo, etc... Parce que quand on y pense... En LTSP, c'est le client léger qui lance le serveur X et le serveur LTSP vient présenter une session dessus. Peut-être qu'il y a une interaction problématique ? Actuellement, ils tournent tous avec LDM_DIRECTX=true, c.-à-d. que la connexion entre client et serveur n'est pas chiffrée par SSH. Mais je pourrais aussi essayer en chiffrant pour voir si ça fait une différence... Ceci dit, je me souviens qu'au moment de flasher le bios, la clé USB insérée avec le fichier .BIO dessus contenait l'installateur de stretch, lequel s'est lancé parce que je n'ai pas tapé assez vite sur F7 pour flasher... L'affichage n'a pas duré longtemps, certes, mais il ne clignotait pas. Serait-ce une piste ? Les résolutions d'affichage sont quand même très différentes et ça ne le fait peut-être qu'en sollicitant un peu la carte ? Si je sais, je retesterai tiens.
Comment être certain que le standard est respecté ou compatible sur le câble dvi/hdmi ?
Ah ça bien sûr... Je ne peux que faire confiance aux câbles que j'ai. Mais la question est pertinente parce que ce sont les deux mêmes, achetés en même temps, et neufs, donc par définition non testés ou du moins on n'en a pas de preuve... Si ça se trouve, ils viennent d'un même lot qui pourrait être défectueux ? En outre, je me suis fait la réflexion en les ouvrant que le fabricant ne s'est pas foulé sur le blindage, vu la taille du câble ; en tout cas par rapport à mes purs DVI-D d'avant, y a pas photo : la section et la "dureté" du câble sont moindres, peut-être même nettement.
Bon courage,
Merci ;) Ça devient surtout le temps, le problème. Ces tests sont chronophages à mort et d'autres trucs n'avancent pas, alors que je m'attendais à swaper simplement les machines et à pointer la macaddress de la nouvelle sur le bon chroot dans le DHCP. Là, c'est raté du coup :-[ Mais merci à tous les intervenants de la liste sur le problème ; c'est précieux dans l'adversité numérique ;) A+ -- JFS.
Christophe De Natale
Le 06/03/2018 à 17:23, JF Straeten a écrit :
Sinon, toutes les tentatives le sont en ltsp ?
Oui : la machine est appelée à faire office de client léger et tous les boots le sont en NFS sur des chroot LTSP (passer d'un à l'autre est beaucoup plus rapide que de faire des installs locales évidemment). [...]
C'est marrant car dans ton premier post, lorsque j'ai lu que l'aspect ltsp étaitindifférent, je me suis dit le problème est là :D (ou pas) Tes clients sont "fat" ou "thin" et sur quelle architecture ? Une fois que tu es sûr que le matos est ok avec le test en "local", ce sera peut-être la piste à creuser... Bonne soirée, -- Christophe De Natale
Le 06/03/2018 à 17:23, JF Straeten a écrit :
Sinon, toutes les tentatives le sont en ltsp ?
Oui : la machine est appelée à faire office de client léger et tous
les boots le sont en NFS sur des chroot LTSP (passer d'un à l'autre
est beaucoup plus rapide que de faire des installs locales
évidemment).
[...]
C'est marrant car dans ton premier post, lorsque j'ai lu que l'aspect
ltsp étaitindifférent, je me suis dit le problème est là :D (ou pas)
Tes clients sont "fat" ou "thin" et sur quelle architecture ?
Une fois que tu es sûr que le matos est ok avec le test en "local", ce
sera peut-être la piste à creuser...
Oui : la machine est appelée à faire office de client léger et tous les boots le sont en NFS sur des chroot LTSP (passer d'un à l'autre est beaucoup plus rapide que de faire des installs locales évidemment). [...]
C'est marrant car dans ton premier post, lorsque j'ai lu que l'aspect ltsp étaitindifférent, je me suis dit le problème est là :D (ou pas) Tes clients sont "fat" ou "thin" et sur quelle architecture ? Une fois que tu es sûr que le matos est ok avec le test en "local", ce sera peut-être la piste à creuser... Bonne soirée, -- Christophe De Natale
JF Straeten
Re, On Tue, Mar 06, 2018 at 07:23:07PM +0100, Christophe De Natale wrote: [...]
C'est marrant car dans ton premier post, lorsque j'ai lu que l'aspect ltsp étaitindifférent, je me suis dit le problème est là :D (ou pas) Tes clients sont "fat" ou "thin" et sur quelle architecture ?
Tous "thin". En i386 jusqu'ici, le NUC étant la seule machine amd64. Mais je comptais paresseusement la lancer en 32bit aussi... jusqu'à devoir investiguer :-) Et là, j'ai créé rapido un chroot amd64, puis deux (buster), puis trois (sid), et de nouveau un jessie (que je venais de supprimer pour faire de la place, soit dit en passant)...
Une fois que tu es sûr que le matos est ok avec le test en "local", ce sera peut-être la piste à creuser...
Tout à fait. Je vais encore faire quelques tests, dont celui-là, si je sais... Encore merci en tout cas & A+, -- JFS.
Re,
On Tue, Mar 06, 2018 at 07:23:07PM +0100, Christophe De Natale wrote:
[...]
C'est marrant car dans ton premier post, lorsque j'ai lu que l'aspect ltsp
étaitindifférent, je me suis dit le problème est là :D (ou pas)
Tes clients sont "fat" ou "thin" et sur quelle architecture ?
Tous "thin". En i386 jusqu'ici, le NUC étant la seule machine amd64.
Mais je comptais paresseusement la lancer en 32bit aussi... jusqu'à
devoir investiguer :-) Et là, j'ai créé rapido un chroot amd64, puis
deux (buster), puis trois (sid), et de nouveau un jessie (que je
venais de supprimer pour faire de la place, soit dit en passant)...
Une fois que tu es sûr que le matos est ok avec le test en "local", ce sera
peut-être la piste à creuser...
Tout à fait. Je vais encore faire quelques tests, dont celui-là, si je
sais...
Re, On Tue, Mar 06, 2018 at 07:23:07PM +0100, Christophe De Natale wrote: [...]
C'est marrant car dans ton premier post, lorsque j'ai lu que l'aspect ltsp étaitindifférent, je me suis dit le problème est là :D (ou pas) Tes clients sont "fat" ou "thin" et sur quelle architecture ?
Tous "thin". En i386 jusqu'ici, le NUC étant la seule machine amd64. Mais je comptais paresseusement la lancer en 32bit aussi... jusqu'à devoir investiguer :-) Et là, j'ai créé rapido un chroot amd64, puis deux (buster), puis trois (sid), et de nouveau un jessie (que je venais de supprimer pour faire de la place, soit dit en passant)...
Une fois que tu es sûr que le matos est ok avec le test en "local", ce sera peut-être la piste à creuser...
Tout à fait. Je vais encore faire quelques tests, dont celui-là, si je sais... Encore merci en tout cas & A+, -- JFS.
JF Straeten
Chère Liste, On Tue, Mar 06, 2018 at 05:23:51PM +0100, JF Straeten wrote: [...]
On Mon, Mar 05, 2018 at 06:59:51PM +0100, Christophe De Natale wrote:
[...]
Comment être certain que le standard est respecté ou compatible sur le câble dvi/hdmi ?
Ah ça bien sûr... Je ne peux que faire confiance aux câbles que j'ai. Mais la question est pertinente parce que ce sont les deux mêmes, achetés en même temps, et neufs, donc par définition non testés ou du moins on n'en a pas de preuve... Si ça se trouve, ils viennent d'un même lot qui pourrait être défectueux ?
Petit retour sur les tests réalisés depuis hier... En synthèse, pour mémoire, on avait épinglé ceci au fur et à mesure de la discussion : - LTSP avec chiffrement ; - câbles différents ; - autre écran ; - sur live-cd ; - avec une install locale. J'ai pu essayer ceci : - LTSP avec chiffrement en premier, puisque c'est une variable à changer dans un fichier. Résultat : que dalle, ça le fait, même si c'est un peu moins et uniquement sur l'écran de gauche. C'est beaucoup plus rare à droite ; NB. curieusement, c'est sur des applications en mode texte (Mutt, rxvt, etc.) ou affichant beaucoup de texte (Thunar) que ça foire. Avec un Gimp + gLabels à l'écran, ça ne bouge pas. Strange... - différents câbles / autre écran : j'ai testé le NUC sur un Iiyama ProLite B2403WS, 24", en 1920x1200 (le max), en HDMI des deux côtés (avec un câble HDMI Philips qui semble de bonne facture) : et bien ici, aucun problème ! L'image est parfaitement stable, même avec des tas d'rxvt, Mutt et applications texte... Ça ne bouge pas et fonctionne normalement. Même résultat sur un projecteur Optoma GT5000+, en 1920x1080 (le max) : tout passe absolument parfaitement. Donc, fort de ce constat technologique de pointe, j'ai trépigné toute la journée jusqu'à avoir 5 minutes pour foncer ventre à terre chez les margoulins d'électronique du coin, histoire de trouver d'autres câbles HDMI to DVI-D DL. Y a pas, évidemment, que du SL... Je me rabats donc sur des adaptateurs HDMI to DVD-D (voire même I), de marque Ewent, que je teste sans même enlever mon paletot, sûr d'être dans le bon :-) Et ben non : foire totale ! C'est pire que tout. Même sur le bureau et l'écran d'accueil. À la limite, penser à lancer Mutt suffit à faire déconner l'affichage. Le seul constat possible est que la résolution 2560x1600 passe à travers, mais ça ne va pas plus loin, et même pas du tout en fait :-[ Je pense nécessaire d'essayer d'autres câbles du type requis, de bonne facture (et si vous en avez qui fonctionne, les références m'intéressent évidemment) parce qu'on a ici manifestement une piste exploitable. Ou bien, vous pensez que je perds mon temps ? - avec un live-cd [non testé] - avec un disque USB et une install locale [non testé] Ceci ne vaut pas la peine pour le moment si l'électronique est en cause à la base, à mon humble avis... NB1. les adaptateurs HDMI to DVI : d'une manière générale, ils ne sont à mon avis pas recommandables au delà des tests : il est évident que ça va forcer sur les connecteurs de la machine vu la disproportion des extrémités, sans parler du câble DVI aussi lourd que rigide qui va empirer les choses ; NB2. spécialement dans le cas du NUC... Il n'y a pas moyen de le brancher côté câble d'alimentation, sauf à en bidouiller le plug. En un sens, c'est ballot, je sais, mais j'étais chaud comme une baraque à frites un soir de kermesse sur ma résolution de problème et ai donc sacrifié ces détails sur l'autel de la R&D, même si ça ne serait pas à faire en prod' :-) Je me réjouis de voir si vous aurez d'autres idées et remarques après au moins un test concluant et confirmé, mais qui ne va pas encore loin assez : je *dois* arriver à la résolution native des écrans, 2560x1600, c'est contractuellement non négociable :-) Merci encore à tous d'avance, en tout cas & A+, -- JFS.
Chère Liste,
On Tue, Mar 06, 2018 at 05:23:51PM +0100, JF Straeten wrote:
[...]
On Mon, Mar 05, 2018 at 06:59:51PM +0100, Christophe De Natale wrote:
[...]
> Comment être certain que le standard est respecté ou compatible sur
> le câble dvi/hdmi ?
Ah ça bien sûr... Je ne peux que faire confiance aux câbles que
j'ai.
Mais la question est pertinente parce que ce sont les deux mêmes,
achetés en même temps, et neufs, donc par définition non testés ou du
moins on n'en a pas de preuve... Si ça se trouve, ils viennent d'un
même lot qui pourrait être défectueux ?
Petit retour sur les tests réalisés depuis hier...
En synthèse, pour mémoire, on avait épinglé ceci au fur et à mesure de
la discussion :
- LTSP avec chiffrement ;
- câbles différents ;
- autre écran ;
- sur live-cd ;
- avec une install locale.
J'ai pu essayer ceci :
- LTSP avec chiffrement en premier, puisque c'est une variable à
changer dans un fichier. Résultat : que dalle, ça le fait, même si
c'est un peu moins et uniquement sur l'écran de gauche. C'est
beaucoup plus rare à droite ;
NB. curieusement, c'est sur des applications en mode texte
(Mutt, rxvt, etc.) ou affichant beaucoup de texte (Thunar)
que ça foire. Avec un Gimp + gLabels à l'écran, ça ne bouge
pas. Strange...
- différents câbles / autre écran : j'ai testé le NUC sur un Iiyama
ProLite B2403WS, 24", en 1920x1200 (le max), en HDMI des deux côtés
(avec un câble HDMI Philips qui semble de bonne facture) : et bien
ici, aucun problème !
L'image est parfaitement stable, même avec des tas d'rxvt, Mutt et
applications texte... Ça ne bouge pas et fonctionne normalement.
Même résultat sur un projecteur Optoma GT5000+, en 1920x1080 (le
max) : tout passe absolument parfaitement.
Donc, fort de ce constat technologique de pointe, j'ai trépigné
toute la journée jusqu'à avoir 5 minutes pour foncer ventre à terre
chez les margoulins d'électronique du coin, histoire de trouver
d'autres câbles HDMI to DVI-D DL. Y a pas, évidemment, que du SL...
Je me rabats donc sur des adaptateurs HDMI to DVD-D (voire même I),
de marque Ewent, que je teste sans même enlever mon paletot, sûr
d'être dans le bon :-)
Et ben non : foire totale ! C'est pire que tout. Même sur le bureau
et l'écran d'accueil. À la limite, penser à lancer Mutt suffit à
faire déconner l'affichage.
Le seul constat possible est que la résolution 2560x1600 passe à
travers, mais ça ne va pas plus loin, et même pas du tout en
fait :-[
Je pense nécessaire d'essayer d'autres câbles du type requis, de
bonne facture (et si vous en avez qui fonctionne, les références
m'intéressent évidemment) parce qu'on a ici manifestement une piste
exploitable. Ou bien, vous pensez que je perds mon temps ?
- avec un live-cd [non testé]
- avec un disque USB et une install locale [non testé]
Ceci ne vaut pas la peine pour le moment si l'électronique est en
cause à la base, à mon humble avis...
NB1. les adaptateurs HDMI to DVI : d'une manière générale, ils ne
sont à mon avis pas recommandables au delà des tests : il est
évident que ça va forcer sur les connecteurs de la machine vu la
disproportion des extrémités, sans parler du câble DVI aussi lourd
que rigide qui va empirer les choses ;
NB2. spécialement dans le cas du NUC... Il n'y a pas moyen de le
brancher côté câble d'alimentation, sauf à en bidouiller le plug.
En un sens, c'est ballot, je sais, mais j'étais chaud comme une
baraque à frites un soir de kermesse sur ma résolution de problème
et ai donc sacrifié ces détails sur l'autel de la R&D, même si ça
ne serait pas à faire en prod' :-)
Je me réjouis de voir si vous aurez d'autres idées et remarques après
au moins un test concluant et confirmé, mais qui ne va pas encore loin
assez : je *dois* arriver à la résolution native des écrans,
2560x1600, c'est contractuellement non négociable :-)
Chère Liste, On Tue, Mar 06, 2018 at 05:23:51PM +0100, JF Straeten wrote: [...]
On Mon, Mar 05, 2018 at 06:59:51PM +0100, Christophe De Natale wrote:
[...]
Comment être certain que le standard est respecté ou compatible sur le câble dvi/hdmi ?
Ah ça bien sûr... Je ne peux que faire confiance aux câbles que j'ai. Mais la question est pertinente parce que ce sont les deux mêmes, achetés en même temps, et neufs, donc par définition non testés ou du moins on n'en a pas de preuve... Si ça se trouve, ils viennent d'un même lot qui pourrait être défectueux ?
Petit retour sur les tests réalisés depuis hier... En synthèse, pour mémoire, on avait épinglé ceci au fur et à mesure de la discussion : - LTSP avec chiffrement ; - câbles différents ; - autre écran ; - sur live-cd ; - avec une install locale. J'ai pu essayer ceci : - LTSP avec chiffrement en premier, puisque c'est une variable à changer dans un fichier. Résultat : que dalle, ça le fait, même si c'est un peu moins et uniquement sur l'écran de gauche. C'est beaucoup plus rare à droite ; NB. curieusement, c'est sur des applications en mode texte (Mutt, rxvt, etc.) ou affichant beaucoup de texte (Thunar) que ça foire. Avec un Gimp + gLabels à l'écran, ça ne bouge pas. Strange... - différents câbles / autre écran : j'ai testé le NUC sur un Iiyama ProLite B2403WS, 24", en 1920x1200 (le max), en HDMI des deux côtés (avec un câble HDMI Philips qui semble de bonne facture) : et bien ici, aucun problème ! L'image est parfaitement stable, même avec des tas d'rxvt, Mutt et applications texte... Ça ne bouge pas et fonctionne normalement. Même résultat sur un projecteur Optoma GT5000+, en 1920x1080 (le max) : tout passe absolument parfaitement. Donc, fort de ce constat technologique de pointe, j'ai trépigné toute la journée jusqu'à avoir 5 minutes pour foncer ventre à terre chez les margoulins d'électronique du coin, histoire de trouver d'autres câbles HDMI to DVI-D DL. Y a pas, évidemment, que du SL... Je me rabats donc sur des adaptateurs HDMI to DVD-D (voire même I), de marque Ewent, que je teste sans même enlever mon paletot, sûr d'être dans le bon :-) Et ben non : foire totale ! C'est pire que tout. Même sur le bureau et l'écran d'accueil. À la limite, penser à lancer Mutt suffit à faire déconner l'affichage. Le seul constat possible est que la résolution 2560x1600 passe à travers, mais ça ne va pas plus loin, et même pas du tout en fait :-[ Je pense nécessaire d'essayer d'autres câbles du type requis, de bonne facture (et si vous en avez qui fonctionne, les références m'intéressent évidemment) parce qu'on a ici manifestement une piste exploitable. Ou bien, vous pensez que je perds mon temps ? - avec un live-cd [non testé] - avec un disque USB et une install locale [non testé] Ceci ne vaut pas la peine pour le moment si l'électronique est en cause à la base, à mon humble avis... NB1. les adaptateurs HDMI to DVI : d'une manière générale, ils ne sont à mon avis pas recommandables au delà des tests : il est évident que ça va forcer sur les connecteurs de la machine vu la disproportion des extrémités, sans parler du câble DVI aussi lourd que rigide qui va empirer les choses ; NB2. spécialement dans le cas du NUC... Il n'y a pas moyen de le brancher côté câble d'alimentation, sauf à en bidouiller le plug. En un sens, c'est ballot, je sais, mais j'étais chaud comme une baraque à frites un soir de kermesse sur ma résolution de problème et ai donc sacrifié ces détails sur l'autel de la R&D, même si ça ne serait pas à faire en prod' :-) Je me réjouis de voir si vous aurez d'autres idées et remarques après au moins un test concluant et confirmé, mais qui ne va pas encore loin assez : je *dois* arriver à la résolution native des écrans, 2560x1600, c'est contractuellement non négociable :-) Merci encore à tous d'avance, en tout cas & A+, -- JFS.
JF Straeten
Re, On Wed, Mar 07, 2018 at 06:43:47PM +0100, JF Straeten wrote: [...]
J'ai pu essayer ceci :
[...]
- différents câbles / autre écran : j'ai testé le NUC sur un Iiyama ProLite B2403WS, 24", en 1920x1200 (le max), en HDMI des deux côtés (avec un câble HDMI Philips qui semble de bonne facture) : et bien ici, aucun problème ! L'image est parfaitement stable, même avec des tas d'rxvt, Mutt et applications texte... Ça ne bouge pas et fonctionne normalement. Même résultat sur un projecteur Optoma GT5000+, en 1920x1080 (le max) : tout passe absolument parfaitement.
Oublié de préciser ceci : sur le DELL U3011 aussi, en passant par le connecteur HDMI (même test que ci-dessus), l'image est parfaitement stable également. Il y a toutefois dans ce cas que la résolution 1920x1200 est émulée par le DELL (et n'est franchement pas terrible), mais sur le principe ça marche. A+ -- JFS.
Re,
On Wed, Mar 07, 2018 at 06:43:47PM +0100, JF Straeten wrote:
[...]
J'ai pu essayer ceci :
[...]
- différents câbles / autre écran : j'ai testé le NUC sur un Iiyama
ProLite B2403WS, 24", en 1920x1200 (le max), en HDMI des deux côtés
(avec un câble HDMI Philips qui semble de bonne facture) : et bien
ici, aucun problème !
L'image est parfaitement stable, même avec des tas d'rxvt, Mutt et
applications texte... Ça ne bouge pas et fonctionne normalement.
Même résultat sur un projecteur Optoma GT5000+, en 1920x1080 (le
max) : tout passe absolument parfaitement.
Oublié de préciser ceci : sur le DELL U3011 aussi, en passant par le
connecteur HDMI (même test que ci-dessus), l'image est parfaitement
stable également.
Il y a toutefois dans ce cas que la résolution 1920x1200 est émulée
par le DELL (et n'est franchement pas terrible), mais sur le principe
ça marche.
Re, On Wed, Mar 07, 2018 at 06:43:47PM +0100, JF Straeten wrote: [...]
J'ai pu essayer ceci :
[...]
- différents câbles / autre écran : j'ai testé le NUC sur un Iiyama ProLite B2403WS, 24", en 1920x1200 (le max), en HDMI des deux côtés (avec un câble HDMI Philips qui semble de bonne facture) : et bien ici, aucun problème ! L'image est parfaitement stable, même avec des tas d'rxvt, Mutt et applications texte... Ça ne bouge pas et fonctionne normalement. Même résultat sur un projecteur Optoma GT5000+, en 1920x1080 (le max) : tout passe absolument parfaitement.
Oublié de préciser ceci : sur le DELL U3011 aussi, en passant par le connecteur HDMI (même test que ci-dessus), l'image est parfaitement stable également. Il y a toutefois dans ce cas que la résolution 1920x1200 est émulée par le DELL (et n'est franchement pas terrible), mais sur le principe ça marche. A+ -- JFS.
