[tor-dev] Hogging of second_elapsed_callback()

[Linus Nordberg]

Hi,

How long time can we spend signing status documents before tor gets sad?

I ask because I'm planning on putting dirauth signing keys on a
sloooooow HSM and would like to understand if I'd have to make
format_networkstatus_vote() and networkstatus_compute_consensus() (and
their callers) be "restartable", much like dirvote_act() is
"restartable".

Current measurements indicate a worst case figure of 6.5 seconds for a
hashing and signing operation. This may even increase some over
time. (It may also shrink considerably with some optimisations but this
is where we are today.)

[teor]

Post by Linus Nordberg
Hi,
How long time can we spend signing status documents before tor gets sad?
I ask because I'm planning on putting dirauth signing keys on a
sloooooow HSM and would like to understand if I'd have to make
format_networkstatus_vote() and networkstatus_compute_consensus() (and
their callers) be "restartable", much like dirvote_act() is
"restartable".
Current measurements indicate a worst case figure of 6.5 seconds for a
hashing and signing operation. This may even increase some over
time. (It may also shrink considerably with some optimisations but this
is where we are today.)

Connections and circuits might timeout over that 6.5 seconds.

Can you shift the signing to its own thread?
Or make it asynchronous?

Tor has cpuworkers, which could be used to do signing work.

T

[Linus Nordberg]

Post by teor
Connections and circuits might timeout over that 6.5 seconds.

OK, good to know.

Post by teor
Can you shift the signing to its own thread?
Or make it asynchronous?
Tor has cpuworkers, which could be used to do signing work.

Some non-blockingness would be required, yes.

An asynchronous cryptographic tokens API would be useful but if we're
unable to pull that off, having a cpuworker blocking on the call would
be a solution.