Devshares is a good platform for this.

Quote from: bytemaster on August 27, 2014, 03:31:00 pm

Quote from: OldMan on August 27, 2014, 03:28:27 pm

Excellent idea! You have my vote.

A controlled stress test will degrade user experience due to increased sync times and scan times. I think we keep "stress tests" on the "test network".

My point is that such "stress" will be reached with normal use sooner or later.
The test network is completely different than the real one (unless all delegates run another instance in the test network).
I think such test will be beneficial for the confidence in the network (any marketing words on this?).
The parameters can be altered of course but I think something like this should be done and possible issues identified before the horde of users attack.
Have you played Diablo III on the launch week ? Sims?

PS: I'm not going to attempt anything unless I have community approval !

Quote from: emski on January 15, 2015, 09:50:00 am

This is probably due to a delegate(s) running multiple instances.

Let us identify them and tell them once and for all that this update strategy HARMS the network .. it's a no-go!

Look at the forks...
What I see from a glance is delegateX.Xeldal .

Ubuntu 14.04 Server
8GB ram
Looks fine.

Quote from: emski on January 13, 2015, 08:51:08 pm

Quote from: monsterer on January 13, 2015, 08:08:36 pm

Quote from: VoR0220 on January 13, 2015, 03:52:09 am

Is the typical mobile device powerful enough to handle the workload of a typical delegate?

Currently the wallet needs around 600MB RAM to run, so no.

Large portion of mobile phones have 1GB+ ram today. It should be possible for the time being to run it. If you make it work and you have sufficient bandwidth.

How much bandwidth do you reckon is sufficient?

I'll provide stats I've collected from one of my seed nodes:
Currently there are peaks of 200 KBps.
It is about 30 KBps on average.

Perhaps the delegate requirement would be even lower as you have less network connections.

EDIT: My stats are the total communication of the network adapters.

Suggested feature:
Automatic checkpoints.json export from website.

Released a separate tool, bts_proxy, that acts as an RPC proxy for the BitShares client and provides fine-grained access control.

Announcement: https://bitsharestalk.org/index.php?topic=13143
Source code and README: https://github.com/wackou/bts_proxy

Good Work!
This might pave the way for development of more advanced (or closed source) delegate tools without the need to trust the tool creator explicitly.

Quote from: monsterer on January 07, 2015, 09:31:26 am

You should take a look at this research into NXT forging, where it shows the number of actual forgers is mostly above 200: https://nxtforum.org/general/network-analysis/ which is roughly twice as decentralised as the 101 delegates.

Yes... but what is the distribution... did 1 guy produce 99% and the other 199 produce 1%?

Given the (not so) recent events of buyouts of PTS/DNS/VOTE? decided solely by developers it should be accounted for points in favor of centralisation for Bitshares.
I'm in no way judging or accusing but until there is a vote inside the blockchain for such important decisions and it is demonstrated to work - bitshares remain a little bit more centralised in my mind.
I'm not saying this cannot happen to other project though but the fact that it happened to bitshares and currently there is no voting mechanism inplace is a little troubling.

I've pushed an update fixing Poloniex's asset name change.