Multi-core testing network for all comers - page 2

[Jager]

Tried to run agents using different VPNs.

Hamachi is a convinient tool, nothing extra, all remote agents work. Too bad that the free version is limited to 16 computers.

2. TeamViewer - rather tricky software, a lot of extra stuff, it asks for a password when connecting, which means everyone has to enter a password on the newly connected person. Always confirm VPN connection (it can be possible to make automatic connection in settings, but I haven't found it). A lot of different windows. As the result I was able to connect to the agent with the white IP. I could not connect with a gray IP.

3. Wippien is a cool program, it looks great but I couldn't connect to remote agents at all. And after a couple of hours it disconnected from the internet and I couldn't connect it again.

4. Comodo Easy VPN - also a handy tool, I didn't notice anything unnecessary, I liked it. Agent works with white IP, I haven't been able to run it with grey IP. I have several advantages in comparison with Hamachi. It has no limitation in terms of the number of computers. The ping is 3 times less than in Hamachi. (Hamachi - 33 ms, Comodo Easy VPN - 11 ms)

I guess I can not figure out what ports should be forwarded to start Comodo Easy VPN with grey Pi. Can anyone suggest?

[Jager]

WARRRRRRRRRRRRRRRRRRR WORK!!! ;)

Of course, I didn't expect such a catch from the Vista firewall. As they say, don't believe your eyes. Having installed Comodo EasyVPN, in Vista firewall this application is registered automatically as allowed application, but there is no connection with the agent. As soon as I turn off the firewall, the agent with the grey IP is connected.

In general, I always use Comodo Firewall as firewall on XP but decided to leave it on Vista. I will have to use Comodo Firewall on Vista, too.

Now here's what you need to do to get agents into the network:

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

2. Login to the agents network: Networks, Join a network, Network name: Metatester_agents, Password:1234567890

3. Send in a private message the details of one agent metatester - [Owner][IP address VPN:port][password][approximate access time].

4. After verification you get access to all agents.

We already have 6 metatester agents in our network.

Join in!!!

[Yedelkin]

Jager:
Join in!!!

Some time during a discussion on a forum in the summer, it became clear that someone else's (shared) remote agent could only be used if no one else was connected to it yet. That is, each shared remote agent could only serve one user at a time. What is the situation today, in your agent network?

[[Deleted]]

Yedelkin:
Some summertime discussion on forum it turned out, that someone else's (shared) remote agent can be used only if no one is connected to it yet. That is, each shared remote agent can only serve one user at a time. How is this going today, in your agent network?

This is likely to be the case. There are several ways to solve this problem (at least that's how I see it):

1. installing multiple agents on a single "free" kernel. Say, 2 to 4. This method is inconvenient because the performance of each individual agent will slow down;

2. Significant increase in the number of cores. However, if you have only one agent per core, this will not solve the problem;

3. Regulating the network usage time. For example, you can schedule network usage by days/hours.

Perhaps there are other solutions to the problem. So far I think the best solution is to use all three items.

PS

So my main idea is that everyone in the network should have at least 2 agents (preferably 2 cores) for common needs, and the uptime should also be regulated (although in general the first point is probably enough to start with).

[Jager]

Yedelkin:
In a forum discussion one summer, it turned out that someone else's (shared) remote agent could only be used if no one else was connected to it. That is, each shared remote agent could only serve one user at a time. How does this work today, in your agent network?

If an agent is busy, we take a queue, and the first one to get in is the first one to eat. When there are hundreds of agents, processing a task will ideally be much faster than you run it on multiple local agents.

[Yedelkin]

Jager:
If an agent is busy, we take a queue and then we eat.

I see. A second question: will the queue be somehow automated, or will each participant have to check periodically to see if an agent is available?

Or will it be like in the proverb "In a big family you don't click your beak"? :) Just kidding :)

[[Deleted]]

Jager:
If an agent is busy, we wait in a queue and then we eat the agent. When you have hundreds of agents, the task processing will be much faster, than if you run it on several local agents.

If you take one agent per core and one core per participant, it might not work. There'll be hundreds of people, too...

Yedelkin:

I see. The second question: will the queue be somehow automated, or will each member have to check periodically if an agent is free?

Or will it be like in the proverb: "In a big family you don't click your beak"? :) Just kidding :)

The tester is supposed to determine which of the connected agents are available and free. But it's better to somehow manage it all in "manual mode".

[Yedelkin]

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

Not exactly. The tester, when running the optimisation procedure, checks once to see which of the connected agents are available and free. A "failed" label is hung on busy agents. And the tester doesn't access those agents again. At least that's how it was over the summer. Hence the question as to whether each member of the "big family" would have to manually check for free agents periodically (read "restart the tester/agent").

[[Deleted]]

Yedelkin:
Not really. The tester, when running the optimization procedure, once checks which of the connected agents are available and free. A label like "failed" is attached to busy agents. And the tester doesn't access those agents again. At least that's how it was over the summer. Hence the question as to whether each member of the "big family" would have to manually check for free agents periodically (read "restart the tester/agent").

In this case, it is most likely that those who will run optimization first will get the most out of the number of possible agents. All the others are in the order of available resources.

I would also be interested in traffic between agents, as I understand it would also be something to think about.

[Jager]

Yedelkin:

I see. A second question: will the queue be somehow automated, or will each participant have to check periodically to see if an agent is available?

Or will it be like in the proverb "In a big family you don't click your beak"? :) Just kidding :)

This is not the goal itself, you have to use it as needed, although the point is correct "in der grosse familie nieht klueven klatz-klatz!" ;)

Yedelkin:
Not quite so. When starting an optimization procedure, the tester checks once which of the connected agents are available and free. A label like "failed" is attached to busy agents. And the tester doesn't access those agents again. At least that's how it was over the summer. Hence the question as to whether each member of the "big family" would have to manually check for free agents periodically (read "restart the tester/agent").

Interesting:

In this case, most likely, those who will be first to launch optimization, they will get the most out of the number of possible agents. All the rest in the order of available resources.

I would also be interested in the traffic between agents, as far as I understand there will also be something to think about.

I propose to test the network jointly, everyone will be able to check his question personally. Bugs and inconveniences should be reported so that they can be corrected and supplemented.

Tested. Busy failed agents try to start every minute automatically.