-
UkoeHB
is the function h2d() endian-aware or has monero always been broken on big-endian machines?
-
hyc
I wouldn't be surprised if it's always been broken
-
hyc
there aren't any big-endian systems in common use any more
-
vtnerd
UkoeHB: the device api is a bit of a kludge from what I recall, it wasn't done properly but its kind of too late now
-
UkoeHB
vtnerd: I see
-
tusko
byte-order is always little-endian, whether or not words are big- or little-endian.
-
UkoeHB
tusko: it matters when converting uints to and from bytes
-
moneromoooo
sech1: there is an abort in monerod with the recent rx patch in a corner case which you might not care about:
-
moneromoooo
if you mine fast (ie, fixed difficulty 1 in tests), every block added calls rx_set_main_seedhash_thread, which starts a thread and does not join.
-
moneromoooo
The first one ends up initializing the rx stuff, which takes a long time.
-
moneromoooo
In the meantime, all other calls to rx_set_main_seedhash_thread stop at the dataset write lock, and bunch up. Block addition does not wait, since no join.
-
moneromoooo
It bombs when the process limit is reached.
-
moneromoooo
It breaks my TF functional tests, which mines a lot, that's why I had to debug it. So it won't happen in the wild. Just when mining fast.
-
sech1
"if (is_main(seedhash)) return;" should prevent this
-
sech1
because rx_set_main_seedhash_thread sets main_seedhash asap
-
moneromoooo
OK, I'll debug some more, possibly I broke something then.
-
sech1
unless it's a different seedhash every time
-
moneromoooo
With a different seed hash every time (like with merge mining and alternating merge/not-merged blocks), it'd be dog slow anyway, right ?
-
sech1
yes
-
moneromoooo
OK, so best I just drop this patch anyway. Thanks.
-
sech1
it can happen when you set one seedhash, then quickly switch to another while the first one is initializing
-
sech1
then it'll keep spawning threads
-
sech1
and you need just 2 hashes
-
moneromoooo
What's the speedup you got from this patch btw ?
-
sech1
it enables fast mode for block verification
-
sech1
10-11 ms down to 1-2 ms to verify PoW
-
moneromoooo
ty
-
xmr-pr
tobtoht opened pull request #8714: depends: bump hidapi/libusb
-
xmr-pr
-
xmr-pr
tobtoht opened pull request #8713: depends: bump hidapi/libusb
-
xmr-pr
-
jeffro256[m]
moneromoooo Did you ever end up taking a look at
moneromooo-monero/bitmonero #7?
-
moneromoooo
Not in detail but it's the next logical step, yes. Please go ahead.
-
jeffro256[m]
Sorry, please go ahead do what?
-
moneromoooo
PR this patch I mean (or finish it if not finished).
-
jeffro256[m]
Ohh, I was thinking you could merge it against yours since you came up with the original idea for the spendable cache
-
jeffro256[m]
But I can also create a new PR against the monero repo if that's easier
-
moneromoooo
It certainly seems saner. If people start to PR other people's patches, it's going to be confusing fast ^_^
-
moneromoooo
Though I did that a few times before. Usually when the author wasn't around anymore. But also when sarang and I were working on the same thing in parallel as the patches were intertwined.
-
moneromoooo
Also loses signatures from the other author as soon as you rebase.