Closed drandreaskrueger closed 6 years ago
Puneetha17
commented
6 years ago I just followed the exact same steps and it works completely fine for me and I am on mac. When I look up the Warning, looks like an Alpine issue to me https://github.com/gliderlabs/docker-alpine/issues/207 https://github.com/gliderlabs/docker-alpine/issues/279. Are you working with Ubuntu?
drandreaskrueger
commented
6 years ago AWS
drandreaskrueger
commented
6 years ago Use this AMI (ami-07ae98bd023ea9955) to reproduce the exact same system. It is Debian-stretch based.
drandreaskrueger
commented
6 years ago I have now done the same again, starting all over in a new instance of the same AWS image ... and I could reproduce the problem.
drandreaskrueger
commented
6 years ago Are you seeing it too, when you run it in that ami-07ae98bd023ea9955?
carlosfaria94
commented
6 years ago I have the same problem running locally in a MacOS.
As said here: https://github.com/gliderlabs/docker-alpine/issues/207#issuecomment-387041034
There is a problem doing apk --update add --no-cache
I changed this lines: https://github.com/blk-io/crux/blob/master/docker/crux/Dockerfile#L3-L5 in Dockerfile to:
RUN apk update --no-cache && \
# Update and then install dependencies
apk add unzip db zlib wrk wget libsodium-dev go bash libpthread-stubs db-dev && \
apk -X http://dl-cdn.alpinelinux.org/alpine/edge/testing add leveldb && \
apk add build-base cmake boost-dev gitIt solves the problem.
@drandreaskrueger I will test in AWS.
drandreaskrueger
commented
6 years ago Thanks a lot. Good news. Please commit. Thanks.
drandreaskrueger
commented
6 years ago Also, please fix this too
https://github.com/blk-io/crux/blob/master/docker/quorum-crux/Dockerfile
because that is what is failing - I start with
cd blk-io_crux/docker/quorum-cruxI have tried replacing in https://github.com/blk-io/crux/blob/master/docker/quorum-crux/Dockerfile
with
RUN apk update --no-cache && \
# Update and then install dependencies
apk add unzip db zlib wrk wget libsodium-dev go bash libpthread-stubs db-dev && \
apk -X http://dl-cdn.alpinelinux.org/alpine/edge/testing add leveldb && \
apk add build-base cmake boost-dev gitand ... it works. Hooray.
Please commit to master. Thanks.
carlosfaria94
commented
6 years ago I submitted a PR https://github.com/blk-io/crux/pull/40 waiting to be merged. @Puneetha17
Here: https://github.com/carlosfaria94/crux I made a fork with Dockerfile fix and with your performance tweaks.
I also tested in AWS and it works well (Ubuntu 16 LTS).
@drandreaskrueger I have been following your work, I think it is really important to start stress testing all these implementations. Thank you for your contributions! (And I'm sorry to see Parity team not interested in searching for a solution, it's sad.)
P.S: Be careful with AuRa, the algorithm relays on the UNIX timestamp being sync between nodes. Bad things can happen if timestamps don't sync (lack of consistency):
AuRa favors availability instead of consistency. I prefer a PBFT approach (e.g. IBFT), it favors consistency instead of availability. But depends a lot on your use-case and your project risk tolerance.
One more question, I'm trying to benchmark quorum-crux IBFT in AWS, following your amazing work: https://gitlab.com/electronDLT/chainhammer/blob/master/reproduce_TODO-crux.md
When you do geth attach http://localhost:22001 is inside of the AWS instance or from your local machine to AWS?
drandreaskrueger
commented
6 years ago @carlosfaria94
Oh wow, thanks for all that interesting infos! Hopefully get the time to look deeper next week.
And most of all THANKS for the encouragement. Much needed right now.
Yes, the interactions over there have been ... tiring; (apart from low TPS) another disadvantage of parity?
But of course, we are all busy, so I also understand their reluctance to run someone else's code.
You could see however, how easy I have made it for them. They can test my stuff literally in 10 minutes now.
So now I can only ask for that ... and wait.
Anyways ... digress ... back to this:
reproduce_TODO-crux.md
Yes, I have just committed an update to exactly that, a few minutes ago. Still work in progress, and I want to wait for @Puneetha17 and then simplify that too long text reproduce_TODO-crux.md before I include it into the main reproduce.md. Then I will also create yet another newer version of the AMI.
But already:
I could get it working!!
(preliminary!) results:
| hardware | node type | #nodes | config | peak TPS_av | final TPS_av |
|---|---|---|---|---|---|
| t2.2xlarge | parity | 4 | (D) | 57.6 | 57.6 |
| t2.2xlarge | geth | 3+1 | (B) | 421.6 | 400.0 |
| t2.2xlarge | quorum crux IBFT | 4 | (F) | 435.4 | 423.1 |
And:
inside of the AWS instance or from your local machine to AWS?
I need that geth attach http://localhost:22001 only if I want to query the node manually, e.g. for blocknumber, or any other JSRE query.
But that geth attach is now also working again.
Yes, from yet another ssh chainhammer terminal on the cloud machine, into itself.
submitted a PR #40 waiting to be merged.
Fantastic, that'll help.
I'll continue not before next week. But you feel free to play with parameters, perhaps you can accelerate even more? Also try raft consensus? Good luck.
Thanks A LOT for the good vibes! ;-) Muito obrigado!
carlosfaria94
commented
6 years ago Yes, the interactions over there have been ... tiring; (apart from low TPS) another disadvantage of parity?
I only have researched the AuRa consensus algorithm, I'm personally never worked with Parity, only Geth.
I will certainly perform more tests until the end of the week.
I only started this week looking to your work, I'm digesting it, and then I will perform some benchmarking, and I look forward to contribute with something :)
Raft is not byzantine fault-tolerant, our internal project require a BFT consensus algorithm. But I will certainly look to Raft to see the performance compared with IBFT.
Thank you for all of your work :) Obrigado :D
edit so that it looks like this
start:
full log: