silverdr

Unfortunately it didn't help. I still tried one more approach and listed all devices (including the dual chip ones) by serial numbers, together with their appropriate :chips=2 entries. That didn't...

My current config looks like this: ``` { "pools" : [ ] , "api-mcast-port" : "4028", "api-port" : "4028", "expiry" : "120", "expiry-lp" : "3600", "failover-switch-delay" : "300", "log" :...

AFAIR there was a mechanism for automatically increase the queue if needed. Having in mind that the problem shows after some time, this might in fact be somehow related to...

Setting it to chips or chips_2 gives 0 hash rate and 100% HW errors. Trying the other way around now (chips_10).

:-)) I see.. well, I didn't check the exact meaning. I kind of thought that "max_queued" is what's on top of what the device is actually working on already. Like...

Setting to chips_10 didn't help much. Setting it to chips_20 helped in a way that flow of "Unknown job id" messages does not appear anymore. But the hash rate drops...

No. At the beginning it is about one to three percent. Sometimes a bit more but no too much. Then this HW percentage starts growing and the hash rate drops...

Sure. I am not at that machine now but shall have a look next time there.

Unfortunately "this bug" link leads to 404...

Right - just add one more voice to the chorus. Keeping root as default but adding possibility to select what folders/subfolders should be used seems the best way to go.