< gmaxwell>
oops #9233 contained a change to ctaes which should have been directed upstream (not like it really matters but the change will potentially get blown away with the next subrepo merge).
< bitcoin-git>
[bitcoin] luke-jr opened pull request #9245: Drop IO priority to idle while reading blocks for getblock requests (master...ionice) https://github.com/bitcoin/bitcoin/pull/9245
< jonasschnelli>
wumpus: "Doesn't every wallet get its own database environment?" <--- wouldn't this require a "directory" per wallet?
< wumpus>
jonasschnelli: good point - I wasn't aware that there is a directory - database environment correspondence
< luke-jr>
wumpus: I put it in util.h cuz I'm not sure what the best way to add a conditional header to the makefiles is :x
< wumpus>
luke-jr: just add it unconditionally
< luke-jr>
I guess it wouldn't be conditional at this point
< jonasschnelli>
luke-jr: if BITCOIN_CORE_H+=?
< wumpus>
luke-jr: we do want this functionality for windows eventualy (though it's ok if you don't do thatin your pull)
< luke-jr>
jonasschnelli: yeah, but it's resolved earlier than it can be added cleanly
< * luke-jr>
wonders if Windows has IO priorities
< wumpus>
it's better to not have conditional headers
< wumpus>
yes, it has
< wumpus>
in any case you should make at least the interface abstract, that the implementation is empty on windows for now is ok
< luke-jr>
it's pretty abstract right now?
< wumpus>
yes, but it wouldn't be if you make the header conditional
< jonasschnelli>
I think this should also work on OSX.
< bitcoin-git>
[bitcoin] gmaxwell opened pull request #9246: Developer docs about existing subtrees. (master...devdocs_for_subtrees) https://github.com/bitcoin/bitcoin/pull/9246
< gmaxwell>
wumpus: yea, there is an enviroment/directory correspondance.
< jonasschnelli>
luke-jr: would this also affect filtered blocks?
< * gmaxwell>
wonders if fanquake is automated, he was so fast tagging that PR.
< jonasschnelli>
heh
< luke-jr>
jonasschnelli: yes, that's intentional
< wumpus>
luke-jr: my comment was completely about code organization, if you make a util_prio.cpp, you should define the interface in util_prio.h, this makes it easier to find stuff :)
< jonasschnelli>
Yes. I though about an option to only prio down the filtere blocks (not the non-filtered).
< wumpus>
yes he is fast
< luke-jr>
hmm, other util files don't have an underscore; should I rename it?
< wumpus>
gmaxwell: bummer
< wumpus>
luke-jr: yes, would make sense for consistency
< wumpus>
jonasschnelli: well further options could be added later I suppose
< luke-jr>
along these lines, I was pondering adding DSCP flags at the network level too
< luke-jr>
but that seems invasive
< wumpus>
luke-jr: does libevent support that?
< luke-jr>
no idea :x
< gmaxwell>
luke-jr: actually doesn't usually help. ... turns out that lots of network gear ignores it and a lot of what doesn't will do terrible things like drop all the marked packets. :(
< wumpus>
I wouldn't recomment hacking on low level bits of the network code as it's going to be ripped out anyway
< wumpus>
do torrent clients use that?
< luke-jr>
gmaxwell: really? to try to survive with this DSL I have my router tagging everything differently :x
< wumpus>
or is it something you would usually define at the OS/firewall level?
< luke-jr>
my torrent client has a field for it, but it seems to be set to 0
< gmaxwell>
torrent mostly uses utp, a reliable transport constructed over UDP that has flow control management that is designed to be as unintrusive as possible... slow downs when it detects delay going up.
< gmaxwell>
And the use of UDP allows it to do hole punching, of course.
< wumpus>
interesting
< wumpus>
I had no idea bittorrent implemented its own bulk data transfer protocol on top of UDP
< wumpus>
thought it used udp just for negotiation and distributed hash tables and such
< gmaxwell>
I don't think any of the utp stuff is using DSCP, it could, but as I mentioned there are networks that respond poorly to it. (not that many, but enough that I've seen multiple pieces of software in the past deploy bits of tagging then either take it out or add more code to detect stupidity and adapt)
< gmaxwell>
yea, it's why ISPs mostly dropped the war on bittorrent. :P
< wumpus>
would be interesting to use something similar
< jonasschnelli>
Wasn't aware of uTP, very interesting.
< gmaxwell>
Yep. It's just a ... big project. I thought maybe after our networking is cleaner adding other transports might be easier.
< wumpus>
it's a big project though I guess if some of the implementation coudl be shared with some bittorrent implementation, it'd help - transferring historical blocks isn't that different from transferring other data
< gmaxwell>
(mostly interesting for block syncing, though the fact that it does hole punching is useful too. and of course, fibre has a udp based transport for blocks on the tip-- designed for an entirely different goal, latency minimization).
< * wumpus>
always thought bittorrent was just dumb dump-data-over-TCP
< jonasschnelli>
luke-jr: OSX: "checking for ioprio syscalls... no"
< gmaxwell>
wumpus: there is a libutp, I dunno about its quality.
< gmaxwell>
wumpus: no the dump-data-over-tcp with many parallel connections is pretty unfriendly to other traffic on the network, tends to irritate users and ISPs.. :)
< gmaxwell>
and also doesn't traverse NAT without heroic efforts.
< luke-jr>
jonasschnelli: dunno how..
< wumpus>
jonasschnelli: can you check in config.log why?
< wumpus>
gmaxwell: true, though the main user of upnp seems to be torrent clients too - that put me on the wrong track, probably just as a fallback if the hole punching doesn't work
< jonasschnelli>
luke-jr, wumpus: conftest.cpp:61:21: error: use of undeclared identifier 'SYS_ioprio_get'
< wumpus>
jonasschnelli: oh wait it's actually directly calling syscalls, yea that won't work on anything but Linux. You probably need to just add a specific implementation for macosx
< luke-jr>
wumpus: BSD seems to use the same syscall macro though
< luke-jr>
jonasschnelli: maybe a new header needed?
< wumpus>
but the syscalls will be named differently and have a different interface
< wumpus>
certainly obscure ones like this
< luke-jr>
looks like this abstraction isn't going to work for Windows
< luke-jr>
it can only set threads low-priority for IO, CPU, and paging at the same time; or set IO alone per-fd
< jonasschnelli>
I'll have a look for OSX.
< luke-jr>
per-fd is probably ideal, but will require API changes
< wumpus>
per-fd is neat
< gmaxwell>
Per-fd is super neat.
< gmaxwell>
luke-jr: rather than IO-nicing it might be better to just rate limit responses.
< luke-jr>
that doesn't allow an idle PC to max out IO, nor an active PC to throttle it down further :x
< wumpus>
might be even better to do both
< jonasschnelli>
Yes. That level would be desirtable.
< jonasschnelli>
But do we want all this custom platform specific code in our codebase?
< jonasschnelli>
I think its nice. I probably would go for it.
< luke-jr>
done I think
< luke-jr>
I was tempted to make it support platforms with BOTH ioprio and iopolicy, and retry the alternate if the first fails, but meh
< bitcoin-git>
bitcoin/0.13 94531b5 Wladimir J. van der Laan: torcontrol: Explicitly request RSA1024 private key...
< bitcoin-git>
[bitcoin] wodry opened pull request #9249: Improvement of documentation of command line parameter 'whitelist' (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9249
< bitcoin-git>
[bitcoin] wodry opened pull request #9251: Improvement of documentation of command line parameter 'whitelist' (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9251
< bitcoin-git>
[bitcoin] wodry closed pull request #9249: Improvement of documentation of command line parameter 'whitelist' (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9249
< bobbytux>
hello all
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #9252: Release cs_main before calling ProcessNewBlock (cmpctblock handling) (master...cb-lock) https://github.com/bitcoin/bitcoin/pull/9252