You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 24, 2022. It is now read-only.
Apparently Boost::asio is hammering with polls the socket in search for data and I have the suspect that this behavior may lead to cases like #936 where weak CPUs may record high usage and eventually cause segfaults on nic driver.
I think (but I might be well wrong) async_read_until (as it's a combined operation of multiple async_read_some) keeps polling io_service=>nic in search of small chuncks of data causing exit with error EAGAIN continuosly preventing locking.
Probably keeping the listening socket on a separate lockable and sync thread would mitigate this issue.
Got rid of libjson-rpc-cpp which hammers network driver (#1059)
Built API server entirely on boost::asio
Starting point to share http and rpc on same port
- Got rid of jsonrpccpp server which hammers socket (#1059)
- Some cnotes pushed in log to detect API operations
- Socket(s) are persistent till disconnection (a client can issue
multiple requests)
- Added miner_shuffle method to re-rand nonce scrambler at runtime (it
may give you the chance to abandon a low performance batch)
I just performed an strace over network communications for both ethminer and claymore
Claymore first :
Nothing special and really expected.
Now ethminer
Apparently Boost::asio is hammering with polls the socket in search for data and I have the suspect that this behavior may lead to cases like #936 where weak CPUs may record high usage and eventually cause segfaults on nic driver.
I think (but I might be well wrong) async_read_until (as it's a combined operation of multiple async_read_some) keeps polling io_service=>nic in search of small chuncks of data causing exit with error EAGAIN continuosly preventing locking.
Probably keeping the listening socket on a separate lockable and sync thread would mitigate this issue.
@chfast
@smurfy
@jean-m-cyr
@MariusVanDerWijden
Any help or hint appreciated.
The text was updated successfully, but these errors were encountered: