That’s just it, for DKG we don’t need PARSEC. But that’s not to say it’s not needed for other elder->elder decisions. This is just one thing that we don’t have to put through PARSEC. Much like we are investigating CRDT for concurrent data, as opposed to feeding all data changes through PARSEC. It may be possible, and that may well speed things up.
But neither of those things mean we don’t need parsec consensus in other areas.
It’s a 2 prong thing. So BLS will allow section keys to be used instead of groups of elder keys. so space efficient. It also allows us to know what specific group agreed/signed etc. But this is just group consensus (remember data chains) and is much more efficient, The cost is that not all operations are strictly ordered and this is where CRDT data types come in, operations do not need strict order, the order can be causal and repeating the same op has the same effect as doing the op once (idempotent), therefor group consensus is all we need there. This also allows massively concurrent updates to data which a slower/blocking mechanism simply cannot do.
The other cost is reality and the reality of not being certain you have the latest data, no network can help you there, but some think with strict order you can and that is false. You can get the latest agreed value if all nodes return a data chain for the data item (parsec does not have this) or indeed the whole parsec graph (multiple Gb per value). However, you still don’t know it’s the latest unless you stop time and ask all holders of the data for copies and the proof of each update in relation to existing data elements (i.e. it’s a fools errand). So we get space efficiency from BLS and speed from group consensus and CRDT. We are doing a lot of background work to make more use of this and allow very responsive and offline apps to be used as well as handling partitions that may last years
As @joshuef says we have places right now we need parsec as we have not got crdt there, but this is where we hired a crdt consultant to dive deeper into.
I think I will leave that known issue to you guys…
Meantime is there any point in me trying to gather performance data by running PUT tests say 50 times and counting failures for varying sizes of test data?
Also get some timings over an average of say 50 runs?
It may be worthwhile. I was trying something similar before. And repetition on the command line was not erroring for me now (where previous it was pretty reliable). So I’d definitely be curious to know if you manage to get the error without using the bench command.
Right now I’m just playing around to get my batch scripts right. I am not getting any failures with small files < 100k for now
Got a large no of failures earlier with bigger files but I need to re-run these tests to give a sensible report.
I wish I was better with grep.
Rather than doing it all in one batch I think I’ll generate the test outputs the process them with a wee python file to look for the errors - Yes I know its a cop-out…
Anybody good at grep, sed and that stuff want to DM me, please
I want to turn this kind of output into something useful - pref in a .csv so we can do nice graphs
------------------------------------------
test run 20
50+0 records in
50+0 records out
51200 bytes (51 kB, 50 KiB) copied, 0.000447579 s, 114 MB/s
[2020-03-20T19:16:25Z ERROR safe] safe-cli error: [Error] NetDataError - Failed to PUT Sequenced Append Only Data: Error(CoreError(Data error -> Error on Vault network: Not enough space - CoreError::DataError -> NetworkOther("Not enough space")))
real 0m0.242s
user 0m0.071s
sys 0m0.022s
------------------------------------------
test run 21
50+0 records in
50+0 records out
51200 bytes (51 kB, 50 KiB) copied, 0.00043953 s, 116 MB/s
[2020-03-20T19:16:26Z ERROR safe] safe-cli error: [Error] NetDataError - Failed to PUT Sequenced Append Only Data: Error(CoreError(Data error -> Error on Vault network: Not enough space - CoreError::DataError -> NetworkOther("Not enough space")))
real 0m0.256s
user 0m0.084s
sys 0m0.008s
------------------------------------------
test run 22
50+0 records in
50+0 records out
51200 bytes (51 kB, 50 KiB) copied, 0.000447212 s, 114 MB/s
[2020-03-20T19:16:26Z ERROR safe] safe-cli error: [Error] NetDataError - Failed to PUT Sequenced Append Only Data: Error(CoreError(Data error -> Error on Vault network: Not enough space - CoreError::DataError -> NetworkOther("Not enough space")))
real 0m0.414s
user 0m0.078s
sys 0m0.015s
------------------------------------------
Meanwhile Im going to set up a new set of vaults - as you can see above, the present ones are full.
I’m also wondering if the recent run of poor results is due to the vaults being nearly full.
Instead of wiping all my vaults, I deleted just one, following a suggestion by @davidpbrown. The idea being to see if the remaining vaults would notice the lost chunks and relocate them to another vault. That doesn’t seem to have worked though. Now I just have 7 vaults with 2 holding significant amounts of data.
The script I am using to run my current testing is here
Any assistance is welcome, please clone and help me make these scripts more useful.
Specifically, I could use help to detect errors and log these separately. I have already had help from @davidpbrown about sed and I will be implementing that later tonight to try and get some graphs of the results.
But please don’t let that put you off adding that feature yourself if you are bored with being locked down.
OK - just searching for any reason why yours fill more evenly than mine. Can you try some larger PUTs to see how it fails when you run out of space, please?
Also what is the largest file size you can reliably PUT?
I get a failure here when I try to go above ~1.05Gb