Nimbus ethereum client, More channels on discord: https://discord.gg/XRxWahP
tharda@discord: it hanged here
NOT 2022-05-03 18:36:05.265+02:00 Starting trusted node sync databaseDir=/home/pi/.cache/nimbus/BeaconNode/db restUrl=http://X.X.X.X:5051 blockId=finalized backfill=true
INF 2022-05-03 18:36:05.547+02:00 Writing genesis state stateRoot=7e76880e genesis_validators_root=4b363db9
INF 2022-05-03 18:36:14.753+02:00 Writing genesis block blockRoot=4d611d5b blck="(slot: 0, proposer_index: 0, parent_root: \"00000000\", state_root: \"7e76880e\", eth1data: (deposit_root: 0000000000000000000000000000000000000000000000000000000000000000, deposit_count: 0, block_hash: 0000000000000000000000000000000000000000000000000000000000000000), graffiti: \"\", proposer_slashings_len: 0, attester_slashings_len: 0, attestations_len: 0, deposits_len: 0, voluntary_exits_len: 0, sync_committee_participants: -1)"
NOT 2022-05-03 18:36:15.391+02:00 Downloading checkpoint block restUrl=http://139.99.75.0:5051 blockId=finalized
NOT 2022-05-03 18:36:16.174+02:00 Downloading checkpoint state restUrl=http://139.99.75.0:5051 checkpointSlot=3730912
INF 2022-05-03 18:36:27.953+02:00 Writing checkpoint state
tharda@discord: it hanged here
NOT 2022-05-03 18:36:05.265+02:00 Starting trusted node sync databaseDir=/home/pi/.cache/nimbus/BeaconNode/db restUrl=http://X.X.X.X:5051 blockId=finalized backfill=true
INF 2022-05-03 18:36:05.547+02:00 Writing genesis state stateRoot=7e76880e genesis_validators_root=4b363db9
INF 2022-05-03 18:36:14.753+02:00 Writing genesis block blockRoot=4d611d5b blck="(slot: 0, proposer_index: 0, parent_root: \"00000000\", state_root: \"7e76880e\", eth1data: (deposit_root: 0000000000000000000000000000000000000000000000000000000000000000, deposit_count: 0, block_hash: 0000000000000000000000000000000000000000000000000000000000000000), graffiti: \"\", proposer_slashings_len: 0, attester_slashings_len: 0, attestations_len: 0, deposits_len: 0, voluntary_exits_len: 0, sync_committee_participants: -1)"
NOT 2022-05-03 18:36:15.391+02:00 Downloading checkpoint block restUrl=http://X.X.X.X:5051 blockId=finalized
NOT 2022-05-03 18:36:16.174+02:00 Downloading checkpoint state restUrl=http://X.X.X.X:5051 checkpointSlot=3730912
INF 2022-05-03 18:36:27.953+02:00 Writing checkpoint state
tharda@discord: oh okay, I believe it is now synced and it starts backfilling
INF 2022-05-03 18:39:32.417+02:00 Backfilling timeleft=02d10h21m slotsPerSecond=17.75988633672744 remainingSlots=3730687
INF 2022-05-03 18:39:45.595+02:00 Backfilling timeleft=03d13h20m slotsPerSecond=12.14345257941412 remainingSlots=3730601
INF 2022-05-03 18:39:58.326+02:00 Backfilling timeleft=04d03h53m slotsPerSecond=10.3733604692167 remainingSlots=3730514
INF 2022-05-03 18:40:11.027+02:00 Backfilling timeleft=04d12h42m slotsPerSecond=9.531988855849532 remainingSlots=3730425
INF 2022-05-03 18:40:23.268+02:00 Backfilling timeleft=04d20h00m slotsPerSecond=8.93267383935653 remainingSlots=3730345
tharda@discord: is it possible to disable the backfilling? I just want to test how what is the performance of the client once synced
firebredd@discord: Hi guys, I'm new to Nimbus, I've some questions.
- Can we run a nibus excecution node and consensus node with the help of docker? rather than downloading and installing the binaries.?
- If yes what is the stable or latest version of the docker image for the Nimbus?
- Can someone send me the documentation how do we make use of docker to run Nimbus execution layer client and consensus client?
firebredd@discord: Hi guys, I'm new to Nimbus, I've some questions.
- Can we run a nibus consensus node with the help of docker? rather than downloading and installing the binaries.?
- If yes what is the stable or latest version of the docker image for the Nimbus?
- Can someone send me the documentation how do we make use of docker to run Nimbus execution layer client and consensus client?
mratsim@discord: The EL client is not ready for prime-time yet.
Mkkoll@discord: Ive already got a mainnet prysm validator and beacon node set up so im not unfamiliar with CLI staking
Mkkoll@discord: Could anybody point me to any guides on how to setup for nimbus on one of the testnet merges?
andrewrobbins@discord: Hey everyone. I've finished setting up Nimbus and importing my validator keys. However my
https://cdn.discordapp.com/attachments/613988663034118153/976589678943809556/Screen_Shot_2022-05-18_at_3.58.27_PM.png
nextActionWait value is saying n/a. What am I doing wrong?https://cdn.discordapp.com/attachments/613988663034118153/976589678943809556/Screen_Shot_2022-05-18_at_3.58.27_PM.png
firebredd@discord: Hi, I'm running goerli geth as my eth1 client using this command:docker run -it -d -v /home/ec2-user/.geth:/root -p 8545:8545 -p 30303:30303 --name geth-node --net=host ethereum/client-go:v1.10.15 --datadir=/root --http --http.port=8545 --http.addr=0.0.0.0 --http.vhosts=* --http.api=eth,net,web3,personal --goerli
The Node is running perfectly fine and is now SYNCING
Now I'm running Nimbus Beacon and Validator Node as my eth2 client, where I'm getting this error
Eth1 chain monitoring failure, restarting topics="eth1" err="getBlockByHash(m.dataProvider,\n BlockHash(m.depositsChain.finalizedBlockHash.data)) failed 3 times. Last error: Failed to send POST Request with JSON-RPC."
But the beacon node is syncing properly, is the error is because of the geth which is not completely synced?
You can see the logs in the snapshot attached.
https://cdn.discordapp.com/attachments/613988663034118153/976764603105181696/Screenshot_2022-05-19_at_2.02.51_PM.png
mratsim@discord: Yes, updates that are low-urgency can be done at your convenience with little to no impact. At most you might miss slight performance improvements but those are mostly relevant for the folks overclocking their Raspberry Pi
arnetheduck@discord: our official donation address is: 0x70E47C843E0F6ab0991A3189c28F2957eb6d3842 (see https://github.com/status-im/nimbus-eth2/#donations= ) - there's also a gitcoin grant at https://gitcoin.co/grants/137/nimbus-2
arnetheduck@discord: our official donation address is: 0x70E47C843E0F6ab0991A3189c28F2957eb6d3842 (see https://github.com/status-im/nimbus-eth2/#donations= ) - there's also a gitcoin grant at https://gitcoin.co/grants/137/nimbus-2 (which points to the same wallet)
Mattia@discord: Hi guys, not sure what's the best channel to ask this question so I'll try here:
Lighthouse user here, I would like to switch to another ETH2 client both because of Lighthouse's high usage % and for better performance/resource usage. I've been monitoring my server and noticed that Lighthouse is writing to disk quite a lot, more than 2 GB in 20 minutes. Since I am using an SSD I would like to try to minimize disk writes as much as possible and I heard that Nimbus is great regarding resource usage, especially RAM. My main concern is not RAM though but disk I/O. Can anyone share any insight on Nimbus disk I/O usage?
From the message I'm quoting it looks like you guys optimized for disk I/O as well, I'd like to know more if possible. How can Nimbus use less RAM, less CPU and less disk I/O than all other clients?
arnetheduck@discord: One recent independent comparison is https://someresat.medium.com/ethereum-staker-migration-guide-migrating-from-prysm-to-nimbus-b802a7dcb31e - there's a section on disk usage which should give you an idea of what to expect
mratsim@discord: For disk IO, we reduce it by using caches.
Regarding CPU, we started single-threaded, and are still mostly single-threaded, meaning we had to have deep looks into the actually bottlenecks.
Also we have an unfair advantage, we wrote most of the libraries (besides SQLite and cryptography) ourselves, and cryptography doesn't use RAM and SQLite is very optimized.
mratsim@discord: Interesting
https://cdn.discordapp.com/attachments/613988663034118153/979026176544759849/unknown.png
https://cdn.discordapp.com/attachments/613988663034118153/979026176544759849/unknown.png
Mattia@discord: How can you have low disk IO because of cache, but also have low RAM usage?🤔
Mattia@discord: How can you have low disk IO because of cache, but also have low RAM usage?🤔
Is the cache very small? If yes, could it be increased even more somehow (maybe in the config) if RAM is not an issue?
Is the cache very small? If yes, could it be increased even more somehow (maybe in the config) if RAM is not an issue?
arnetheduck@discord: we use a particular storage format which deduplicates a lot of the data - this has the double effect of reducing RAM usage and storage / IO at the same time, at the cost of some complexity when re-constituting the data, allowing the caches to be more efficient instead of having them use more RAM - in some cases, our caches are also compressed in-memory which allows us to keep more stuff off the disk that other clients persist
arnetheduck@discord: we use a particular storage format which deduplicates a lot of the data (such as the validator set) - this has the double effect of reducing RAM usage and storage / IO at the same time, at the cost of some complexity when re-constituting the data, allowing the caches to be more efficient instead of having them use more RAM - in some cases, our caches are also compressed in-memory which allows us to keep more stuff off the disk that other clients persist
arnetheduck@discord: it's a similar story to writing: less data to read (because we wrote less) = faster read = faster startup and less CPU usage, also at startup - restarts are typically in the single-second range with most of the startup time is dedicated to looking for your UPnP configuration and decrypting your validator keys - the complexity is mainly in the code where we have to be a bit more careful not to load stale data, as opposed to using a more simple storage format
Mattia@discord: Looks like there's no drawback then. I'm sold, thank you guys!
arnetheduck@discord: get in touch if your run into any trouble - we have a general migration guide here: https://nimbus.guide/migration.html#migrate-from-another-client
Mattia@discord: I'm now a happy Nimbus user! Used checkpoint sync, now downloading the other blocks.
Two questions:
1) Should I enable
2) Can I increase Nimbus' cache? On geth I can change --cache to 6144 or more and it will use more RAM and sync faster. Is there anything similar for Nimbus? I haven't seen something like that on the documentation but it might worth to ask.
Two questions:
1) Should I enable
--subscribe-all-subnets? Are rewards actually higher?2) Can I increase Nimbus' cache? On geth I can change --cache to 6144 or more and it will use more RAM and sync faster. Is there anything similar for Nimbus? I haven't seen something like that on the documentation but it might worth to ask.
Mattia@discord: Also this is what my resource usage looks like when synching. 57 slots/s, ETA is actually increasing, started from 12 hours and now it's up to 17 hours
https://cdn.discordapp.com/attachments/613988663034118153/979093589164433478/unknown.png
https://cdn.discordapp.com/attachments/613988663034118153/979093589164433478/unknown.png
Mattia@discord: I'm now a happy Nimbus user! Used checkpoint sync, now downloading the other blocks.
Two questions:
1) Should I enable
2) Can I increase Nimbus' cache? On geth I can change --cache to 6144 or more and it will use more RAM and sync faster. Is there anything similar for Nimbus? I haven't seen something like that on the documentation but it might worth asking.
Two questions:
1) Should I enable
--subscribe-all-subnets? Are rewards actually higher?2) Can I increase Nimbus' cache? On geth I can change --cache to 6144 or more and it will use more RAM and sync faster. Is there anything similar for Nimbus? I haven't seen something like that on the documentation but it might worth asking.
arnetheduck@discord: 1) slightly better blocks can be produced, but it takes a bit of bandwidth and cpu - given how rare it is that you produce a block, it really depends a lot on your setup - many people run with free bandwidth and beefy machines, there it makes sense - if you're not in that category, "probably" doesn't make sense (which is why it's off by default)
2) No exposed cache options, except for historical replays via rest (
2) No exposed cache options, except for historical replays via rest (
--rest-statecache-size and --rest-statecache-ttl) - these are useful if you make a lot of historical queries of the state
arnetheduck@discord: 1) slightly better blocks can be produced, but it takes a bit of bandwidth and cpu - given how rare it is that you produce a block, it really depends a lot on your setup - many people run with free bandwidth and beefy machines, there it makes sense - if you're not in that category, "probably" doesn't make sense (which is why it's off by default)
2) No exposed cache options, except for historical replays via rest (
2) No exposed cache options, except for historical replays via rest (
--rest-statecache-size and --rest-statecache-ttl) - these are useful if you make a lot of historical queries of the state (such as when building balance reports etc)
LynxLove@discord: sorry guys, noob question. the command to DL nimbus new update is:
Right?