Les derniers contenus liés au tag VIA

Lors de la publication des pilotes 375.70 par Nvidia, nous avions noté que la taille des pilotes augmentait significativement, passant de 292 à 373 Mo et laissant entendre des changements. En pratique, GeForce Experience en version 3 est désormais bundlé avec les pilotes, ce qui n'était pas le cas précédemment. Ce n'est cependant pas le seul changement.

Le site MajorGeeks  a noté l'arrivée de nouveaux programmes de télémétrie installés par ces pilotes. Si l'article semble indiquer que leur présence est liée à l'installation de GeForce Experience (GFE), nous avons vérifié que ces programmes étaient bel et bien désormais installés par défaut, même si l'on décoche GFE lors de l'installation :

Nous avons vérifié que les pilotes précédents, les 375.63, n'installaient pas ces tâches. Par contre, si l'on télécharge manuellement GFE et qu'on l'installe, on retrouvera bien ces tâches. La nouveauté est donc que Nvidia installe désormais, par défaut et pour tout le monde, ces tâches !

On retrouve trois entrées dans le planificateur de tâches Windows, concernant deux programmes (NvTmMon.exe et NvTmRep.exe) :

NvTmMon (Nvidia telemetry monitor) est lancé au démarrage, et relancé toutes les heures (on imagine en cas de crash). NvTmRep (Nvidia crash and telemetry reporter) est lancé lui aussi au démarrage, et une fois par jour (dans notre cas à 12h25, on imagine que l'heure varie en fonction de l'heure d'installation du pilote).

Des données transférées hors crash ?

Nous avons voulu voir si ces tâches communiquaient réellement des données, y compris en l'absence de crash du pilote. Nous avons lancé manuellement NvTmRep après une installation, et capturé le trafic réseau avec Wireshark :

Pour résumer cette capture qui peut paraître obscure, on y voit (la première colonne note le numéro des paquets capturés) :

• 199/201 : Une requete DNS pour obtenir l'adresse IP de gfe.nvidia.com (8.36.120.226)
• 202/213 : L'établissement d'une connexion avec le serveur (8.36.120.226), en mode SSL
• 214/215 : L'envoi par notre machine de deux paquets de données, de 296 et 5950 octets
• 219/220 : La réponse du serveur en deux paquets, 797 et 168 octets

Les serveurs de Nvidia sont donc bel et bien contactés, même en l'absence de crash. Quand au contenu exact des 6 ko de données envoyés, ils sont (heureusement) cryptés mais ne nous permettent pas de savoir ce qu'ils contiennent.

Des changements (presque) annoncés

On pourra se plaindre que Nvidia n'a pas vraiment annoncé ce changement majeur de collecte des données (les releases notes ne mentionnant rien). Cependant le constructeur arguera qu'il a prévenu ses clients dans ses conditions d'utilisations.

En effet, une autre différence entre la version 375.63 et la 375.70 est que la licence affichée avant l'installation du pilote a changé. A première vue on dirait que le constructeur a remplacé cette ancienne licence avec celle qui était "livrée" (il fallait cliquer sur un lien dans l'installeur pour la voir sur le web, elle n'était pas affichée directement contrairement aux pilotes ou elle apparaît dans une boite) avec GFE. La nouvelle licence contient ce passage :

3. CONSENT TO COLLECTION AND USE OF INFORMATION

Customer hereby acknowledges that the SOFTWARE accesses and collects both non-personally identifiable information and personally identifiable information about Customer and CUSTOMER SYSTEM as well as configures CUSTOMER SYSTEM in order to

(a) properly optimize CUSTOMER SYSTEM for use with the SOFTWARE,

(b) deliver content through the SOFTWARE,

(c) improve NVIDIA products and services, and

(d) deliver marketing communications.

Information collected by the SOFTWARE includes, but is not limited to, CUSTOMER SYSTEM'S

(i) hardware configuration and ID,

(ii) operating system and driver configuration,

(iii) installed games and applications,

(iv) games and applications settings, performance, and usage data, and

(iv) usage metrics of the SOFTWARE.

To the extent that Customer uses the SOFTWARE, Customer hereby consents to all of the foregoing, and represents and warrants that Customer has the right to grant such consent.

Concrètement, l'installation du pilote indique que l'on consent à la collecte de données présentée et aux utilisations que Nvidia pourra en faire.

Les points (a) et (d) sont liés a GFE, et le point (b) à la recherche de pilote automatique (liée précédemment à GFE). Le point (c) peut faire référence à un usage des logs pour détecter par exemple des bugs.

La liste des données collectée contient à la fois des données personnelles non-identifiables et identifiables. Outre la liste des jeux et applications installées, leurs réglages (utile pour GFE), les données relatives à l'utilisation des jeux et les "métriques" du pilotes sont aussi envoyés (dans les deux points iv).

En bref

Même si la télémétrie est entrée dans l'ère du temps avec Windows 10, et que Nvidia n'est pas le premier a insérer du réseau dans ses pilotes (on se souvient de Razer et de ses pilotes de souris "Cloud", la marque ayant fini par ajouter sous la pression de ses clients un mode "hors ligne") nous sommes relativement surpris du fait que Nvidia ait décidé d'installer désormais par défaut cette télémétrie pour tous ses utilisateurs, qu'ils utilisent GeForce Experience ou non.

Le constructeur pourra arguer qu'il a besoin des logs de crash de ses pilotes pour mieux les débugguer, une utilisation valide de la télémétrie, mais la collecte de données va bien au delà. S'il s'agissait uniquement de ces logs, le constructeur aurait pu, après un redémarrage et en cas de crash, demander que l'on lui envoie les logs (ce que faisait historiquement Microsoft).

Outre la manière dont ces changements ont été introduits, on notera qu'il n'y a pas, a priori, de moyen de refuser la collecte de données. La licence est précise sur ce point. De plus, la licence unique ne permet pas de savoir ce qui relève uniquement de GFE et ce qui relève du service de télémétrie.

Au strict minimum, le constructeur devrait clarifier dans sa licence ce qui relève de GFE, et ce qui relève de l'utilisation du pilote sans GFE. Cela permettra à ses clients de savoir si ils souhaitent consentir, ou non, à cette collecte. Nous pensons qu'il serait courtois de la part de Nvidia de proposer au minimum un opt-out - la possibilité de désactiver la collecte - si on le désire, et si possible lors de l'installation. La collecte potentielle de données personnelles identifiables, pour un pilote graphique, mérite plus que quelques lignes dans une licence que peu d'utilisateurs lisent.

En attendant, et si cela ne résoudra pas le problème, il est possible pour ceux qui le souhaiteraient de supprimer manuellement les tâches ajoutées (notamment via l'excellent Autoruns de Sysinternals/Microsoft ), en notant que rien n'assure que cela désactive définitivement toute collecte.

Après avoir proposé des contrôleurs SSD, VIA fait de nouveau parler d'elle en annonçant un nouveau contrôleur, le VL716 . Il s'agit d'un contrôleur USB/SATA, du type que l'on trouve dans les boîtiers pour disques durs externes. Ce contrôleur a cependant la particularité d'être le premier à avoir passé les certifications USB Type-C.

Asmedia propose déjà depuis un moment des solutions USB 3.1/SATA comme l'ASM1352R que nous utilisons durant nos tests de cartes mères, mais ce dernier n'était visiblement pas certifié Type-C (bien que notre boitier de test en soit muni). En pratique, nous avons rencontré avec lui un bon nombre de déconnexions à l'usage sous Windows.

 

 

Ce nouveau contrôleur de VIA gère donc d'un côté l'USB 3.1 10 Gbps, avec prise en charge des protocoles de transferts BOT et UASP (voir cet article pour plus de détails), et de l'autre le SATA 6 Gbps.

La puce est relativement petite, 6mm de côté ce qui permet de créer des designs compacts. VIA ne précise pas dans quelle mesure sa puce gère le standard USB Power Delivery. Techniquement, la présence de l'USB Type-C impose une gestion au moins à minima du standard.

L'alimentation d'un SSD (ou d'un disque dur 2.5 pouces) ne posera pas de problèmes, les 5W fournis par tous les connecteurs USB suffisant, mais des disques 3.5 pouces peuvent réclamer une puissance supérieure. En l'état, difficile de dire ce qui est réellement géré. L'illustration fournie laisse penser que l'on devrait retrouver cette puce dans des boîtiers 2.5 pouces.

Si le SATA est limité à 6 Gbps, en pratique passer de 5 à 10 Gbps côté USB devrait être assez bénéfique. Comme nous avions pu le voir dans cet article, les protocoles de transferts USB comme le mode BOT sont particulièrement inefficaces, et les pilotes UASP de Microsoft ne brillent pas non plus par leur rapidité.

La société Taiwannaise VIA est également présente au Flash Memory Summit et y annonce sa seconde (!) génération de contrôleur pour SSD au format SATA III et NVMe.

Le VT6745 en PCIe

Deux puces sont annoncées, les VT6735 et VT6745, fonctionnant respectivement en SATA III et en PCIe Gen 3 x2 fabriqués en 40nm. Il s'agit de contrôleurs disposant de quatre canaux NAND auxquels on pourra adjoindre un cache DRAM en DDR3L ou LPDDR2/3 1066. Ces contrôleurs sont annoncés comme compatible avec des puces TLC et 3D NAND en provenance d'Intel, Micron, Toshiba, Hynix et Sandisk.

Le VT6735 en SATA III

VIA ne parle pas de performances, mais tente de se distinguer en mettant en avant sa technologie "Gear shift" qui permet de choisir dynamiquement entre divers mécanismes de correction d'erreur pour trouver le meilleur compromis entre intégrité des données et performance.

Une technologie originale qui ressemble fortement à "ShiftDesigner", une technologie présentée par PMC Sierra (une société rachetée par Microsemi en début d'année) l'année dernière durant le Flash Memory Summit 2015 et dont vous pouvez retrouver ci-dessous la présentation :

 

 

La ressemblance nous laisse supposer, même si cela n'est pas précisé, que l'implémentation utilisée par VIA est dérivée/sous licence de celle de PMC Sierra. Il faudra voir si la technologie suffira a convaincre les divers constructeurs de SSD à s'intéresser aux contrôleurs de VIA, qui rentre sur un marché assez compétitif !