According to https://github.com/akkadotnet/akka.net/issues/2378#event-3071191410 there might be benefits in the P2P on the last version.
As #611 mentioned and discussed in other threads.

That sounds good.
Good news :)
Major changes from Akka 1.3 to Akka1.4 include:
1.Akka.Remote's performance has significantly increased as a function of our new batching mode- which is tunable via HOCON configuration to best support your needs.
The default transport in Akka.Remote is the DotNetty TCP transport, which is a good choice for most Akka.NET developers because TCP preserves message order and guarantees delivery of every message over the wire so long as the network remains available, which is consistent with IActorRef default messaging. The same cannot be said for alternative transports such as a UDP transport.
As of Akka.NET v1.4.0-beta4, we've added a new feature to Akka.Remote called a "batch writer" which has tremendously improved the performance of outbound writes in Akka.Remote by grouping many logical writes into a smaller number of physical writes (actual flush calls to the underlying socket.)
Here are some performance numbers from our RemotePingPong benchmark, which uses high volumes of small messages.
These numbers were all produced on a 12 core Intel i7 2.6Ghz Dell laptop over a single Akka.Remote connection running .NET Core 2.1 on Windows 10:


It can be seen that the average performance after improvement is 141,091 MSG /s, which is 1.7 times higher than before. The standard deviation was 15,291 MSG /s, indicating that the stability of the new akka was greatly enhanced。
Akka.Remote's flush batching system for DotNetty operates on the principle of trying to minimize the number of system calls to the I/O system because they are (1) expensive and (2) unpredictably long-running. Our data shows grouping together dozens of small writes, ~218 bytes per message in this sample, into larger payloads in the 4kb range significantly reduces the standard deviation for this benchmark, significantly improves the average, and also increases the maximum absolute throughput observed.
akka.remote.dot-netty.tcp{
batching{
enabled = true
max-pending-writes = 30
max-pending-bytes = 16k
flush-interval = 40ms
}
}
The batching system inside the DotNetty TCP transport works using the following business rules.
Only flush to the underlying transport when one of these happens:
2.All HOCON Config objects have been moved from the Akka.Configuration namespace within the core Akka library to the stand-alone HOCON project and its subsequent HOCON.Configuration NuGet package.
So we need to
Conclusion:
Akka1.4 has many improvements, but the two most important ones for NEO are the above.
After upgrading to Akka1.4, the overall performance and stability of the system will be greatly improved.
Great compilation @shawnyun, could you proceed with the PR?
@vncoelho Yes, I will test it and send the PR.
Waiting for a more stable release version
Most helpful comment
Major changes from Akka 1.3 to Akka1.4 include:
1.Akka.Remote's performance has significantly increased as a function of our new batching mode- which is tunable via HOCON configuration to best support your needs.
The default transport in Akka.Remote is the DotNetty TCP transport, which is a good choice for most Akka.NET developers because TCP preserves message order and guarantees delivery of every message over the wire so long as the network remains available, which is consistent with IActorRef default messaging. The same cannot be said for alternative transports such as a UDP transport.


As of Akka.NET v1.4.0-beta4, we've added a new feature to Akka.Remote called a "batch writer" which has tremendously improved the performance of outbound writes in Akka.Remote by grouping many logical writes into a smaller number of physical writes (actual flush calls to the underlying socket.)
Here are some performance numbers from our RemotePingPong benchmark, which uses high volumes of small messages.
These numbers were all produced on a 12 core Intel i7 2.6Ghz Dell laptop over a single Akka.Remote connection running .NET Core 2.1 on Windows 10:
It can be seen that the average performance after improvement is 141,091 MSG /s, which is 1.7 times higher than before. The standard deviation was 15,291 MSG /s, indicating that the stability of the new akka was greatly enhanced。
Akka.Remote's flush batching system for DotNetty operates on the principle of trying to minimize the number of system calls to the I/O system because they are (1) expensive and (2) unpredictably long-running. Our data shows grouping together dozens of small writes, ~218 bytes per message in this sample, into larger payloads in the 4kb range significantly reduces the standard deviation for this benchmark, significantly improves the average, and also increases the maximum absolute throughput observed.
The batching system inside the DotNetty TCP transport works using the following business rules.
Only flush to the underlying transport when one of these happens:
you can disable batching via akka.remote.dot-netty.tcp.batching.enabled = false.
2.All HOCON Config objects have been moved from the Akka.Configuration namespace within the core Akka library to the stand-alone HOCON project and its subsequent HOCON.Configuration NuGet package.
So we need to
Conclusion:
Akka1.4 has many improvements, but the two most important ones for NEO are the above.
After upgrading to Akka1.4, the overall performance and stability of the system will be greatly improved.