Skip to content
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

Jump to bottom

"The monotonic clock must have nanosecond resolution..." exception #6224

Closed
BOR4 opened this issue Jun 3, 2020 · 20 comments · Fixed by #6252
Closed

"The monotonic clock must have nanosecond resolution..." exception #6224

BOR4 opened this issue Jun 3, 2020 · 20 comments · Fixed by #6252
Assignees
@konradkonrad
Projects
Raiden Berlin Sprint

Comments

@BOR4
Copy link
Contributor

BOR4 commented Jun 3, 2020

image

Happened to one of the community members. He was nice enough to provide logs:
raiden-exception-2020-06-03T13-27jx8_wfcj.txt
@palango
Copy link
Contributor

palango commented Jun 3, 2020

Do you have any information about the system and the python version?

@BOR4
Copy link
Contributor Author

BOR4 commented Jun 3, 2020

oy,
this is what I have.

"im running the wizard thru a ubuntu box on my win10 laptop (latest win10 update had a linux kernel)"

@hymner
Copy link

hymner commented Jun 3, 2020

Ubuntu 20.04 LTS (Running on the Windows 10 Version 2004 Linux Kernel)
Python 3.8.2

@ulope
Copy link
Collaborator

ulope commented Jun 3, 2020 •
edited

@hymner please run this command and report the result:

python -c 'import time; time.clock_gettime_ns(time.CLOCK_MONOTONIC_RAW)'

@hymner
Copy link

hymner commented Jun 3, 2020

@ulope i get no result from above command, and wizard behaves the same.

hymner@CAAHW-00541:/raiden$ python3 -c 'import time; time.clock_gettime_ns(time.CLOCK_MONOTONIC_RAW)'
hymner@CAAHW-00541:/raiden$

output from running the wizard again: https://pastebin.com/qUgs90FU

@konradkonrad
Copy link
Contributor

this is actually a raiden-network/raiden issue. I'll try to move it!

@konradkonrad konradkonrad transferred this issue from raiden-network/raiden-wizard Jun 4, 2020
@konradkonrad
Copy link
Contributor

@hymner can you try the adjusted command from below and report the result?

@hymner please run this command and report the result:

python -c 'import time; print(time.clock_gettime_ns(time.CLOCK_MONOTONIC_RAW))'

@hymner
Copy link

hymner commented Jun 4, 2020

@konradkonrad result from command: 3857438742600

@konradkonrad
Copy link
Contributor

the trailing 00 look suspicious. Could you run it once more?

@hymner
Copy link

hymner commented Jun 4, 2020

still some zeroes: 4286390247500

@ulope
Copy link
Collaborator

ulope commented Jun 4, 2020

Can you also run python -c 'import time; print(time.clock_getres(time.CLOCK_MONOTONIC_RAW))'?

@hymner
Copy link

hymner commented Jun 4, 2020

result: 1e-09

@konradkonrad
Copy link
Contributor

konradkonrad commented Jun 4, 2020 •
edited

There seem to be more general clock resolution differences in Windows (independent of using the linux subsystem or not): https://www.python.org/dev/peps/pep-0564/#windows
i.e.

OS function resolution
win monotonic() 15 ms
win monotonic_ns() 15 ms
linux monotonic() 81 ns
linux monotonic_ns() 84 ns

@ulope
Copy link
Collaborator

ulope commented Jun 4, 2020

Hm but that's weird. The assert checks that the resolution is below or equal to 1E-9. Which means it shouldn't have triggered here.

@hymer is that the same python you ran Raiden with?

@konradkonrad
Copy link
Contributor

@hymer is that the same python you ran Raiden with?

it's running from the binary bundled python, so most likely not

@ulope
Copy link
Collaborator

ulope commented Jun 4, 2020

Ah, didn't read the issue closely enough.

The bundled version is still built with Python 3.7.0. It could be that this is something that was fixed in one of the later point releases.

@konradkonrad konradkonrad mentioned this issue Jun 8, 2020
Open
@konradkonrad konradkonrad self-assigned this Jun 8, 2020
@konradkonrad
Copy link
Contributor

Further investigating this

@konradkonrad
Copy link
Contributor

konradkonrad commented Jun 8, 2020 •
edited

result: 1e-09

hmm, now this result is actually weird. I'm testing in a Win 10 Evaluation VM, and at least there I get

root@WinDev2005Eval:~# python3
Python 3.8.2 (default, Mar 13 2020, 10:14:16)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import CLOCK_MONOTONIC_RAW, clock_getres
>>> print(clock_getres(CLOCK_MONOTONIC_RAW))
1.0000000000000001e-07

which is "correctly" above 1e-09.

@hymner
Copy link

hymner commented Jun 8, 2020

I'm also getting that result from same box as earlier:
hymner@CAAHW-00541:~$ python3
Python 3.8.2 (default, Apr 27 2020, 15:53:34)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

from time import CLOCK_MONOTONIC_RAW, clock_getres
print(clock_getres(CLOCK_MONOTONIC_RAW))
1.0000000000000001e-07

@konradkonrad
Copy link
Contributor

konradkonrad commented Jun 8, 2020 •
edited

@hackaugusto regarding

raiden/raiden/storage/ulid.py

Lines 65 to 69 in 13ddc68

msg = (
"The monotonic clock must have nanosecond resolution. This is "
"necessary because multiple state changes can be written on the same "
"millisecond."
)

It seems that the Windows Ubuntu subsystems only offers microsecond resolution, which is still below milliseconds. Any reason we couldn't lower the resolution requirement there?
EDIT: It is actually even 0.1 microseconds resolution, according to clock_getres(CLOCK_MONOTONIC_RAW)

konradkonrad added a commit to konradkonrad/raiden that referenced this issue Jun 8, 2020
@konradkonrad
Relax ULID time_monotonic resolution
839e9db 
On some systems (i.e. Linux Subsystem for Windows), the monotonic time
resolution is larger than nanoseconds.

The requirement for the monotonic clock resolution is, that it needs to
be finer than consecutive calls to `time.clock_gettime_ns`, which should
still be satisfied with a `microsecond` (`1e-06`) resolution.

See also https://www.python.org/dev/peps/pep-0564/#annex-clocks-resolution-in-python

This fixes raiden-network#6224
@konradkonrad konradkonrad mentioned this issue Jun 8, 2020
Merged
@Dominik1999 Dominik1999 moved this from Sprint Backlog (Team does that) to In progress in Raiden Berlin Sprint Jun 8, 2020
konradkonrad added a commit to konradkonrad/raiden that referenced this issue Jun 9, 2020
@konradkonrad
Relax ULID time_monotonic resolution
b6dd016 
On some systems (i.e. Linux Subsystem for Windows), the monotonic time
resolution is larger than nanoseconds.

The requirement for the monotonic clock resolution is, that it needs to
be finer than consecutive calls to `time.clock_gettime_ns`, which should
still be satisfied with a `microsecond` (`1e-06`) resolution.

See also https://www.python.org/dev/peps/pep-0564/#annex-clocks-resolution-in-python

This fixes raiden-network#6224
konradkonrad added a commit to konradkonrad/raiden that referenced this issue Jun 9, 2020
@konradkonrad
Relax ULID time_monotonic resolution
6fea534 
On some systems (i.e. Linux Subsystem for Windows), the monotonic time
resolution is larger than nanoseconds.

The requirement for the monotonic clock resolution is, that it needs to
be finer than consecutive calls to `time.clock_gettime_ns`, which should
still be satisfied with a `microsecond` (`1e-06`) resolution.

See also https://www.python.org/dev/peps/pep-0564/#annex-clocks-resolution-in-python

This fixes raiden-network#6224
konradkonrad added a commit to konradkonrad/raiden that referenced this issue Jun 9, 2020
@konradkonrad
Relax ULID time_monotonic resolution
78338f4 
On some systems (i.e. Linux Subsystem for Windows), the monotonic time
resolution is larger than nanoseconds.

The requirement for the monotonic clock resolution is, that it needs to
be finer than consecutive calls to `time.clock_gettime_ns`, which should
still be satisfied with a `microsecond` (`1e-06`) resolution.

See also https://www.python.org/dev/peps/pep-0564/#annex-clocks-resolution-in-python

This fixes raiden-network#6224
konradkonrad added a commit to konradkonrad/raiden that referenced this issue Jun 9, 2020
@konradkonrad
Relax ULID time_monotonic resolution
fff7b28 
On some systems (i.e. Linux Subsystem for Windows), the monotonic time
resolution is larger than nanoseconds.

The requirement for the monotonic clock resolution is, that it needs to
be finer than consecutive calls to `time.clock_gettime_ns`, which should
still be satisfied with a `microsecond` (`1e-06`) resolution.

See also https://www.python.org/dev/peps/pep-0564/#annex-clocks-resolution-in-python

This fixes raiden-network#6224
Raiden Berlin Sprint automation moved this from In progress to Done Jun 9, 2020
hackaugusto pushed a commit that referenced this issue Jun 9, 2020
@konradkonrad @hackaugusto
Relax ULID time_monotonic resolution
63c7b75 
On some systems (i.e. Linux Subsystem for Windows), the monotonic time
resolution is larger than nanoseconds.

The requirement for the monotonic clock resolution is, that it needs to
be finer than consecutive calls to `time.clock_gettime_ns`, which should
still be satisfied with a `microsecond` (`1e-06`) resolution.

See also https://www.python.org/dev/peps/pep-0564/#annex-clocks-resolution-in-python

This fixes #6224
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@konradkonrad konradkonrad

Labels
None yet
Projects
Raiden Berlin Sprint
  
Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Relax ULID time_monotonic resolution konradkonrad/raiden
5 participants
@ulope @palango @konradkonrad @BOR4 @hymner