Réseau d'essais multi-core pour tous les arrivants - page 2

 

J'ai essayé d'exécuter des agents en utilisant différents VPN.

Hamachi est un outil convaincant, rien de plus, tous les agents à distance fonctionnent. Dommage que la version gratuite soit limitée à 16 ordinateurs.

2. TeamViewer - logiciel plutôt délicat, beaucoup de choses supplémentaires, il demande un mot de passe lors de la connexion, ce qui signifie que tout le monde doit entrer un mot de passe sur la personne nouvellement connectée. Toujours confirmer la connexion VPN (il peut être possible de faire une connexion automatique dans les paramètres, mais je ne l'ai pas trouvé). Beaucoup de fenêtres différentes. Le résultat est que j'ai pu me connecter à l'agent avec l'IP blanche. Je n'ai pas pu me connecter avec une IP grise.

3. Wippien est un programme cool, il a l'air génial mais je ne pouvais pas du tout me connecter aux agents distants. Et après quelques heures, il s'est déconnecté d'Internet et je n'ai pas pu le reconnecter.

4. Comodo Easy VPN - également un outil pratique, je n'ai rien remarqué d'inutile, je l'ai aimé. L'agent fonctionne avec une IP blanche, je n'ai pas pu le faire fonctionner avec une IP grise. J'ai plusieurs avantages par rapport à Hamachi. Il n'y a pas de limitation en termes de nombre d'ordinateurs. Le ping est 3 fois moins élevé que dans Hamachi. (Hamachi - 33 ms, Comodo Easy VPN - 11 ms)

Je n'arrive pas à savoir quels ports doivent être transférés pour démarrer Comodo Easy VPN avec le Pi gris. Quelqu'un peut-il suggérer ?

 

WARRRRRRRRRRRRRRRRRRRRRR TRAVAIL !!! ;)

Bien sûr, je ne m'attendais pas à une telle prise de la part du pare-feu de Vista. Comme on dit, ne croyez pas vos yeux. Ayant installé Comodo EasyVPN, dans le pare-feu de Vista cette application est enregistrée automatiquement comme application autorisée, mais il n'y a pas de connexion avec l'agent. Dès que je désactive le pare-feu, l'agent avec l'IP grise est connecté.

En général, j'utilise toujours Comodo Firewall comme pare-feu sur XP mais j'ai décidé de le laisser sur Vista. Je vais devoir utiliser Comodo Firewall sur Vista, également.

Maintenant, voici ce que vous devez faire pour vous connecter au réseau des agents :

1. Installer Comodo EasyVPN http://easy-vpn.comodo.com/download.html

2. Connexion au réseau des agents : Réseaux, Rejoindre un réseau, Nom du réseau : Metatester_agents, Mot de passe:1234567890

3. Envoyez dans un message privé les coordonnées d'un agent metatester - [Propriétaire][adresse IP VPN:port][mot de passe][temps d'accès approximatif].

4. Après vérification, vous avez accès à tous les agents.

Nous avons déjà 6 agents metatester dans notre réseau.

Participez ! !!
Download VPN - Comodo Unite VPN Free Download
  • www.comodo.com
GeekBuddy can remotely install any new software on your PC, as well as provide live remote support for virtually any computer problem you face! Verify and secure your site with COMODO. Get your SSL Certificate FAST, Order instantly and easily!. Our SSL is fully...
 
Jager:
Participez ! !!
Lors d'une discussion sur un forum un été, il s'est avéré que l'agent distant (partagé) d'une autre personne ne pouvait être utilisé que si personne d'autre n'y était encore connecté. En d'autres termes, chaque agent distant partagé ne peut servir qu'un seul utilisateur à la fois. Quelle est la situation aujourd'hui, dans votre réseau d'agents ?
 
Yedelkin:
Lors d'une discussion estivale sur un forum, il s'est avéré que l'agent distant (partagé) d'une autre personne ne peut être utilisé que si personne n'y est encore connecté. En d'autres termes, chaque agent distant partagé ne peut servir qu'un seul utilisateur à la fois. Comment cela se passe-t-il aujourd'hui, dans votre réseau d'agents ?

Il est probable que ce soit le cas. Il y a plusieurs façons de résoudre ce problème (du moins, c'est ainsi que je le vois) :

1. installer plusieurs agents sur un seul noyau "libre". Disons, de 2 à 4. Cette méthode est peu pratique car les performances de chaque agent individuel se dégraderaient ;

2. Augmentation significative du nombre de cœurs. Toutefois, si vous n'avez qu'un seul agent par cœur, cela ne résoudra pas le problème ;

3. Régulation du temps d'utilisation du réseau. Par exemple, vous pouvez programmer l'utilisation du réseau par jours/heures.

Il existe peut-être d'autres solutions au problème. Jusqu'à présent, je pense que la meilleure solution est d'utiliser les trois éléments.

PS

Mon idée principale est donc que tout le monde dans le réseau devrait avoir au moins 2 agents (de préférence 2 cœurs) pour les besoins communs, et que le temps de fonctionnement devrait également être réglementé (bien qu'en général le premier point soit probablement suffisant pour commencer).

 
Yedelkin:
Lors d'une discussion sur un forum un été, il s'est avéré que l'agent distant (partagé) d'une autre personne ne pouvait être utilisé que si personne d'autre n'y était connecté. En d'autres termes, chaque agent distant partagé ne peut servir qu'un seul utilisateur à la fois. Comment cela fonctionne-t-il aujourd'hui, dans votre réseau d'agents ?
Si un agent est occupé, nous faisons la queue, et le premier à entrer est le dernier à manger. Lorsqu'il y a des centaines d'agents, le traitement d'une tâche sera idéalement beaucoup plus rapide si vous l'exécutez sur plusieurs agents locaux.
 
Jager:
Si un agent est occupé, nous faisons la queue et ensuite nous mangeons.

Je vois. Une deuxième question : la file d'attente sera-t-elle en quelque sorte automatisée, ou chaque participant devra-t-il vérifier périodiquement si un agent est disponible ?

Ou est-ce que ce sera comme dans le proverbe "Dans une grande famille, on ne claque pas du bec" ? :) Je plaisante :)

 
Jager:
Si un agent est occupé, on attend dans une file d'attente, puis on mange l'agent. Lorsque vous avez des centaines d'agents, le traitement de la tâche sera beaucoup plus rapide que si vous l'exécutez sur plusieurs agents locaux.

Si vous prenez un agent par noyau et un noyau par participant, cela peut ne pas fonctionner. Il y aura des centaines de personnes, aussi...

Yedelkin:

Je vois. Deuxième question : la file d'attente sera-t-elle en quelque sorte automatisée, ou chaque membre devra-t-il vérifier périodiquement si un agent est libre ?

Ou est-ce que ce sera comme dans le proverbe : "Dans une grande famille, on ne claque pas du bec" ? :) Je plaisante :)

Le testeur est censé déterminer quels agents connectés sont disponibles et libres. Mais il est préférable de gérer tout cela en "mode manuel".
 

Interesting:
По  идеи тестер сам должен определять какие из подключенных агентов доступны и свободны. Но лучше как-то управлять всем этим в "ручном режиме".

Pas exactement. Lors de l'exécution de la procédure d'optimisation, le testeur vérifie une fois quels agents connectés sont disponibles et libres. Une étiquette "failed" est accrochée aux agents occupés. Et le testeur n'accède plus à ces agents. Du moins, c'était comme ça pendant l'été. D'où la question de savoir si chaque membre de la "grande famille" devrait vérifier manuellement et périodiquement la présence d'agents libres (lire "redémarrer le testeur/agent").
 
Yedelkin:
Pas vraiment. Lors de l'exécution de la procédure d'optimisation, le testeur vérifie une fois quels agents connectés sont disponibles et libres. Une étiquette comme "échec" est attachée aux agents occupés. Et le testeur n'accède plus à ces agents. Du moins, c'était comme ça pendant l'été. D'où la question de savoir si chaque membre de la "grande famille" devrait vérifier manuellement et périodiquement la présence d'agents libres (lire "redémarrer le testeur/agent").

Dans ce cas, il est fort probable que ceux qui exécuteront l'optimisation en premier obtiendront le maximum du nombre d'agents possibles. Tous les autres sont dans l'ordre des ressources disponibles.

Je serais également intéressé par le trafic entre les agents, car je comprends que c'est aussi un sujet de réflexion.

 
Yedelkin:

Je vois. Une deuxième question : la file d'attente sera-t-elle en quelque sorte automatisée, ou chaque participant devra-t-il vérifier périodiquement si un agent est disponible ?

Ou est-ce que ce sera comme dans le proverbe "Dans une grande famille, on ne claque pas du bec" ? :) Je plaisante :)

Ce n'est pas le but en soi, il faut l'utiliser selon les besoins, bien que le point soit correct "in der grosse familie nieht klueven klatz-klatz !". ;)

Yedelkin:
Pas tout à fait. Lors du lancement d'une procédure d'optimisation, le testeur vérifie une fois quels agents connectés sont disponibles et libres. Une étiquette comme "échec" est attachée aux agents occupés. Et le testeur n'accède plus à ces agents. Du moins, c'était comme ça pendant l'été. D'où la question de savoir si chaque membre de la "grande famille" devrait vérifier manuellement et périodiquement la présence d'agents libres (lire "redémarrer le testeur/agent").
Intéressant:

Dans ce cas, il est fort probable que ceux qui seront les premiers à lancer l'optimisation, obtiendront le maximum du nombre d'agents possibles. Tout le reste dans l'ordre des ressources disponibles.

Je serais également intéressé par le trafic entre agents, d'après ce que j'ai compris, il y aura également matière à réflexion.

Je propose de tester le réseau conjointement, chacun pourra vérifier personnellement sa question. Les bogues et les inconvénients doivent être signalés afin qu'ils puissent être corrigés et complétés.

Testé. Les agents non occupés essaient de démarrer automatiquement toutes les minutes.

Raison: