Fleming Testnet v5 Release - *OFFLINE*

[Vort]

By the way, when my node was elder in previous testnet, it was using ~800MB of RAM.
Which looks like more than all network data at that moment.
What is stored there and why it is so large?

[MrKeepingItSafe]

@happybeing

Much better to debug one thing at a time, particularly when you have a tricky bug like this which you think you’ve fixed several times but keeps popping up again.

Yes true, I understand. Unless the bug is because AE isn’t there

[Vort]

@MrKeepingItSafe

Unless the bug is because AE isn’t there

Theoretically it should be possible to prove if this hypothesis is true or false.
Nodes are writing log files for reason.

upd. Hmm… it may be that our discussion makes little sense )

Anti-Entropy work

[Toivo]

Damn, they are quick!

[dirvine]

@tfa

The consequences was that adults that didn’t explicitly allow the port they used in the firewall were relocated successfully even though they didn’t store chunks of their new sections.

Adults connect to Elders in the same way clients do. If we cannot connect back to them they are not allowed to promote to Elder.

@tfa

My second question is related to promotion to elder stage: Correction of previous problems allows adults to be relocated in another section without data loss but doesn’t allow an adult to be promoted elder. For that the node needs to allow the port it uses because a complete stranger must be able to connect to an elder (new node or client).

This is the same thing as above. If a node cannot be contacted it cannot promote.

@tfa

So, do you allow the port used by each of your elders, or intended elders for the future?

If you run a node that could be contacted and don’t allow it then it will not become an Elder. If that means opening a port etc. then it’s best you run a node with the port open.

[happybeing]

Looks like they went with your suggestion!

[MrKeepingItSafe]

yahoo… this is good to see

[dirvine]

No that’s us pushing T6 while debugging T5 is happening But you never know these days

[StephenC]

Update from MaidSafe HQ

We are now back online! Testing can start again.

Please remember to follow the full instructions, you need to remove your ~/.safe/ dir and re-add the network configuration.

We will be monitoring for the OOM issue happening again.

[Aragorn]

much better now,
congrats to @bochaco btw !

[MrKeepingItSafe]

$ safe keys create --test-coins --for-cli
New SafeKey created: “safe://hyryyyy8rbidrqyq69apf6mgoipp95fikbau3mccqcd96a6uaww891c9gra”
Preloaded with 1000.111 testcoins
Key pair generated:
Public Key = e40d464701defe1a5f2cd0ab5bfd96aa0e2795b18e60ffec7a78a50ff933e626
Secret Key = 8e66d859516a3780c33f09d3aea41c6b846ba2f564b614a7111f4cd9f35a2181
Setting new SafeKey to be used by CLI…
New credentials were successfully stored in C:\Users\colmo.safe\cli\credentials
Safe CLI now has write access to the network

YES!

[Josh]

Omg… running.

@bochaco

[Vort]

Looks like upload now works faster. Strange. Nothing should be changed…

[neik]

im in happy days well done to all the team for quick turn around on 5.1 !

[dirvine]

@Vort

Strange. Nothing should be changed…

We are suspecting a long running mem leak will be found. Meanwhile Ae progresses and might answer the bug in any case.

[BambooGarden]

the OOM bug wont show cause it knows we’re looking for it…

[Vort]

Then we test other features ))

[Vort]

I mean enabled memory profiling should not make upload faster.
But I clearly see difference.

[dirvine]

Yes I suspect we are seeing nodes not currently being hampered by OOM issues, but they likely will.

[Vort]

So nodes begin to swap because of low RAM condition which makes upload slower? Look plausible.