Bitcoin Forum
May 05, 2024, 06:20:29 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How to achieve fastest node -- 2 minutes delay on block reception  (Read 192 times)
Peter88 (OP)
Newbie
*
Offline Offline

Activity: 10
Merit: 2


View Profile
June 24, 2018, 12:26:43 PM
 #1

Hi,

I have a Bitcoin core node running (0.16.1) which has 16 outgoing connections (to other fast/stable nodes according to Bitnodes) + approx 8 incoming connections. Full blockchain is synced and all txns are indexed.

Whenever a new block comes in, I can see that the time my node processes it is 2 minutes later than the timestamp on the block. What is the reason of this delay? I can't imagine the propagation will always take this long so is there anything else that might be affecting this?

What are normal delays?

For academic purposes I would like to achieve the least delay possible. What could be options to achieve this? I've read that having more peers would not help but can have an opposite effect?

Note: I've already heard about FIBRE, but I'd like to achieve this without it. Also afaik FIBRE is about compact blocks and I'd also like to receive txns as fast as possible.

kr
1714890029
Hero Member
*
Offline Offline

Posts: 1714890029

View Profile Personal Message (Offline)

Ignore
1714890029
Reply with quote  #2

1714890029
Report to moderator
1714890029
Hero Member
*
Offline Offline

Posts: 1714890029

View Profile Personal Message (Offline)

Ignore
1714890029
Reply with quote  #2

1714890029
Report to moderator
1714890029
Hero Member
*
Offline Offline

Posts: 1714890029

View Profile Personal Message (Offline)

Ignore
1714890029
Reply with quote  #2

1714890029
Report to moderator
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714890029
Hero Member
*
Offline Offline

Posts: 1714890029

View Profile Personal Message (Offline)

Ignore
1714890029
Reply with quote  #2

1714890029
Report to moderator
aleksej996
Sr. Member
****
Offline Offline

Activity: 490
Merit: 389


Do not trust the government


View Profile
June 24, 2018, 03:36:18 PM
 #2

Well, make sure first that your system clock is showing the right time.
Other than that, check if your CPU is strong enough to verify and index blocks fast enough.
SSD drive might help as well.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
June 24, 2018, 05:09:33 PM
Merited by ABCbits (1)
 #3

The timestamp on the block is not guaranteed to to be the correct time that the block was actually found. Miners can manipulate the block time quite a bit, so it doesn't reliably tell you when a block was found.

Propagation can also take a long time depending on how far away from the miners you are.

Note: I've already heard about FIBRE, but I'd like to achieve this without it. Also afaik FIBRE is about compact blocks and I'd also like to receive txns as fast as possible.
FIBRE is not really what you are looking for. You already are using compact blocks as that is in Bitcoin Core. Compact blocks is unrelated to transaction relay times.

Peter88 (OP)
Newbie
*
Offline Offline

Activity: 10
Merit: 2


View Profile
June 24, 2018, 05:41:14 PM
Merited by Foxpup (2)
 #4

Ok this is embarrassing, the default windows NTP server was enabed but not working so my PC was indeed more than a minute ahead. This already fixes a large part of the delta. Thanks for all other responses, I can assume all will be a factor for the remaining 40 seconds delay.

I'm still trying to achieve the least as possible, so any other hints or tuning methodes are welcome.

@ETFbitcoin Are the node addresses of miners public? Where to find them? And do they accept any incoming connection as I can imagine a lot of people will want to connect to them for various reasons.
kano
Legendary
*
Offline Offline

Activity: 4494
Merit: 1805


Linux since 1997 RedHat 4


View Profile
June 27, 2018, 01:45:00 PM
 #5

To clarify/correct a comment made above ...

The block time stamp is NOT the time the block was found.
It is something else.

Rather than going into details about what it IS, it is easiest to point out that it is NOT set to be the block find time.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
aleksej996
Sr. Member
****
Offline Offline

Activity: 490
Merit: 389


Do not trust the government


View Profile
June 28, 2018, 08:25:08 PM
 #6

To clarify/correct a comment made above ...

The block time stamp is NOT the time the block was found.
It is something else.

Rather than going into details about what it IS, it is easiest to point out that it is NOT set to be the block find time.

Well now you are just teasing us...
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!