netsukuku-vala
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netsukuku-vala] Planning test


From: Ricardo Lanziano
Subject: Re: [Netsukuku-vala] Planning test
Date: Sat, 13 Jul 2013 16:16:43 -0005

On Sat, Jul 13, 2013 at 5:19 AM, Luca Dionisi <address@hidden> wrote:
First, I am not sure it is a good move. It depends on the size of the community. The program is unstable and could very well block the network for a number of reasons. If the network is large and many users rely on it for their daily communication needs, then this test will probably result in a bad reputation for netsukuku. On the other hand, if the users are aware of the tests going on and are willing to have a temporarily broken network, then go ahead. What IP ranges do they use for the networks? Maybe we can coexist. Do they use the network to get Internet access?

Sorry, I explained myself wrong. We were planning to use the hardware
only, not their current network, were going to test ntk only. Since he
program is currently unstable, that is exactly what I want to test: trying
to get ntk running for a while (ntk network exclusive) and see if it
crashes somewhere to get some stack traces and debug it further.

Second, I have no testing plans at the moment. Proceed with any test plan you can imagine. Take note of what you want to verify and the steps you follow.

Yes, since I have very little knowledge of the current code I was
thinking was to try to test it in real hardware nodes and catch and
report the finded bugs.

Also, I want to take the opportunity to verify the interface wrapper
for GNU/Linux, you know, entering and leaving the network, etc.
stress testing.

Third, I am interested mainly in proving that the protocol works correctly and does scale. Optimizations for the wireless world, I will face this problem later.

Yes me too, I am letting those issues to the wireless gurus aswell.

So, for recap:

1) There would be a test network only, we are only interesting in
testing ntk in real wireless equipment and nodes (OpenWRT, etc)

2) The plan is to review all the bugs that pop up during the testing,
write them on the bug tracker and start the hunting.

3) There would be no wireless annotations, that would be the job
for the wireless gurus.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]