finer time resolution please

[drandreaskrueger]

If two blocks are closer in time than (half) a second, parity returns identical web3.eth.getBlock(blockNumber).timestamp for both blocks ...

.... which can then lead to ZeroDivisionError like here.

Of course, I can catch that, as you see. But ... but.

(For the context, please have a look at these chainhammer benchmarks --> parity.md)

--> Please increase the precision of the blocktime, thanks.

(geth quorum raft consensus is even using nanoseconds which is IMHO too extreme.)

---

• Parity Ethereum version: v1.11.10
• Operating system: Linux
• Installation: docker
• Fully synchronized: not relevant, instantseal
• Network: instantseal dev chain
• Restarted: yes

[drandreaskrueger]

Great, thanks a lot.

So, is it automatically enabled, or do I have to use a switch? Which one? Thanks.

[ordian]

@drandreaskrueger try this:

	"engine": {
		"instantSeal": {
			"params": {
				"millisecondTimestamp": true
			}
		}
	},

[drandreaskrueger]

Can I use it as a commandline switch too?

parity --millisecondTimestamp

?

[drandreaskrueger]

nope

error: Found argument '--millisecondTimestamp' which wasn't expected, or isn't valid in this context

[drandreaskrueger]

@drandreaskrueger try this:

Thanks, @ordian

And @Tbaut has added it to his repo, see https://github.com/paritytech/wiki/pull/240

---

But please reopen.

---

Now I have tried to adapt this file here:

https://github.com/paritytech/parity-deploy/blob/master/config/spec/engine/instantseal

into

cat config/spec/engine/instantseal
	"engine": {
		"instantSeal": {
			"params": {
				"millisecondTimestamp": true
			}
		}
	},

but when I then re-run, with these commands

cd ~/paritytech_parity-deploy
sudo ./clean.sh
docker kill $(docker ps -q); docker rm $(docker ps -a -q); docker rmi $(docker images -q)

./parity-deploy.sh --config dev --name instantseal --geth 
sed -i 's/parity:stable/parity:v1.11.11/g' docker-compose.yml
docker-compose up

I still get whole seconds of time resolution, not milliseconds (i.e. 1000 ms or 0 ms, never anything else):

...
block 6576 | new #TX  17 /    0 ms =   0.0 TPS_current | total: #TX  335 /  9.1 s =  36.9 TPS_average
block 6593 | new #TX  17 / 1000 ms =  17.0 TPS_current | total: #TX  352 /  9.4 s =  37.3 TPS_average
block 6610 | new #TX  16 /    0 ms =   0.0 TPS_current | total: #TX  368 /  9.8 s =  37.4 TPS_average
block 6626 | new #TX  17 /    0 ms =   0.0 TPS_current | total: #TX  385 / 10.2 s =  37.7 TPS_average
block 6643 | new #TX  17 / 1000 ms =  17.0 TPS_current | total: #TX  402 / 10.6 s =  37.9 TPS_average
block 6660 | new #TX  16 /    0 ms =   0.0 TPS_current | total: #TX  418 / 11.0 s =  38.0 TPS_average
block 6676 | new #TX  16 /    0 ms =   0.0 TPS_current | total: #TX  434 / 11.4 s =  38.1 TPS_average
block 6692 | new #TX  17 / 1000 ms =  17.0 TPS_current | total: #TX  451 / 11.8 s =  38.3 TPS_average
block 6709 | new #TX  18 /    0 ms =   0.0 TPS_current | total: #TX  469 / 12.2 s =  38.5 TPS_average
block 6727 | new #TX  17 / 1000 ms =  17.0 TPS_current | total: #TX  486 / 12.6 s =  38.7 TPS_average
block 6744 | new #TX  17 /    0 ms =   0.0 TPS_current | total: #TX  503 / 13.0 s =  38.8 TPS_average
...

simply because

web3.eth.getBlock(newBlockNumber).timestamp returns whole numbers like 1538430374.

What are we doing wrong?

Thanks a lot!

P.S.: I am using this environment & benchmarking tool.

[ordian]

sed -i 's/parity:stable/parity:v1.11.11/g' docker-compose.yml

"millisecondTimestamp" is available since 2.1.0

[drandreaskrueger]

:-)

[drandreaskrueger]

I see.

then I simply have to wait, until they have fixed this issue #9582

because the 2.x.y versions are not working well yet.

[drandreaskrueger]

I suggest you make this the default behavior of the instantseal chain.

Because otherwise you end up with tons of blocks which have an identical block time (i.e. the same second). Weird side effects.