-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quick and dirty PoC for syncing from Portal history network #2910
base: master
Are you sure you want to change the base?
Conversation
Note that it currently will start failing fairly fast because of the issue #2901 |
4dd1896
to
5fbe874
Compare
This PR is not intended to get merged. It is a very quick and dirty implementation with the intention of testing the Portal network and Fluffy code and to verify how long downloads of blocks take in comparison with the execution of them. It kind of abuses the current import from era code to do this. I think (?) in an improved version the block downloads should probably lead the implementation and trigger execution (it is a bit the reverse right now, which makes sense for era files). Perhaps that way the execution could even be offloaded to another thread? It is also coded without using the JSON-RPC API, as I found that easier for a quick version. But the getBlock call could be changed to use the json-rpc alternative.
5fbe874
to
24171c3
Compare
Some stats when syncing small blocks (from genesis): With 512 workers:
With 1024 workers:
Not that this is download + processing. Processing for these blocks is negligible. Also, this is average, there are quite some outliers with sometimes reaching 400bps and sometimes dropping to 100bps, I think mostly dependent on lookup failures. At block 2395517 (which are still small compared to today but does require more tx processing already).
As can be seen, bps drops considerable. But pure downloads is about 75-80 bps (And a lot of download failures occur actually, meaning a lot of retries) , compared to download + processing ~30 bps. I believe this is a first good indication that if we can offload processing on another thread, downloads might be able to keep up with processing. edit: I might have been to early on the above statement, as that range I was testing with seems to include the DDoS days. 1M blocks later:
|
At 4.4M range:
Should be noted that lots of block lookups fail and need to be retried. |
This PR is not intended to get merged. It is a very quick and dirty implementation with the intention of testing the Portal network and Fluffy code and to verify how long downloads of blocks take in comparison with the execution of them.
It kind of abuses the current import from era code to do this.
I think (?) in an improved version the block downloads should probably lead the implementation and trigger execution (it is a bit the reverse right now, which makes sense for era files). Perhaps that way the execution could even be offloaded to another thread?
It is also coded without using the JSON-RPC API, as I found that easier for a quick version. But the getBlock call could be changed to use the json-rpc alternative.