search

neo-ngd / Neo3-GUI

Neo3-GUI: still under development
MIT License
16 stars 12 forks source link

Syncing very slow #52

Open ixje opened 4 years ago

ixje commented 4 years ago

There seems to be some issue with syncing. I've recorded a short video (download link) comparing NEO-GUI vs neo3-Python

What you'll see in the first part of the video is NEO-GUI connecting to seed3t.neo.org:20333 and my python implementation connecting to seed2t. In 1 minute and 20 seconds my python implementation syncs ~18000 blocks, whereas the GUI syncs only headers and 0 blocks. (look at the bottom of the screen in the log window there are some prints saying "Local chain height: ")

To show that this is not an issue with different nodes I switched the Python implementation to use the same seed3t as NEO-GUI (around 1:38 in the video). Within about 10 seconds it has synced 3000 blocks, whereas NEO-GUI is still "stuck".

If you compare the clock (upper right corner) in the video with the below screenshot, you'll see that eventually it has synced ~5800 blocks but that took around 20 minutes!

Screenshot 2020-05-07 at 11 24 29
longfeiWan9 commented 4 years ago

@ixje thank you for your feedback. Since Neo-GUI is running a C# full node under the table, I think it is related to the performance of .net in macOs.

Fortunately, our Windows version works fine and it sync pretty fast. We will work on a way to identify the cause of the slowness for macOS version and then improve the syncing process for it.

ixje commented 4 years ago

@wanglongfei88 I can confirm this is likely an OSX issue. I just tried neo-node on Ubuntu Linux vs OSX and the same issue happens there while I've restricted both nodes to 1 connection max and to the same node.

Ashuaidehao commented 4 years ago

@ixje Thanks for your investigation. There are 2 problems:

  1. Sync Header but not sync blocks: This is caused by neo-node's default sync policy. When connection count is lower than 3, the "GetHeader" task has higher priority than "Sync Block" taskref code. We cannot control it at present, but we will create issue on neo to optimize it .
  2. Sync very slow on Mac: As far as I know, some .net core official ECDSA api runs very slow on Mac. As a result, neo's Mac version syncing process slow down by a mass of ECDSA. Other OS does not got this problem. This cannot be fixed in a short time, we will create a issue on dotnet repo and track it.
ixje commented 4 years ago

@Ashuaidehao

  1. Thanks for explaining. Sounds like a good improvement. I do the same in python, where I only ask for maximum 6000 headers ahead of my local chain height.
  2. I can confirm if I remove header verification it runs fast on OSX.
dusmart commented 3 years ago

@ixje Thanks for your investigation. There are 2 problems:

  1. Sync Header but not sync blocks: This is caused by neo-node's default sync policy. When connection count is lower than 3, the "GetHeader" task has higher priority than "Sync Block" taskref code. We cannot control it at present, but we will create issue on neo to optimize it .
  2. Sync very slow on Mac: As far as I know, some .net core official ECDSA api runs very slow on Mac. As a result, neo's Mac version syncing process slow down by a mass of ECDSA. Other OS does not got this problem. This cannot be fixed in a short time, we will create a issue on dotnet repo and track it.

Have you solved this problem? I found that neo-cli on macos is fast while neo-gui(v1.3.1) on macos is very slow and energy-consuming. When the GUI is open, the fan will spin noisily. Currently neo-gui (v1.3.1) is totally unusable for me.

os version memory processor neo-gui version neo-cli version
macOS Mojave 10.14.6 8GB 2.7GHz Intel Core i5 v1.3.1 3.0.2.0
ixje commented 3 years ago

I have not attempted to solve this as this seems to be an issue with .net core as pointed out by @Ashuaidehao . I have also not tried with the latest .net, might be worth a shot as a lot can change in 1+ year