You do understand what the load average figures are telling you, right? It is simply a count of how many processes running on the system needed CPU time per second during that interval, it does not tell you anything at all about the actual CPU time spent servicing those processes.

Eg, if I do a

Code:

while /bin/true; do echo "."; sleep 1; done

The load average will show as 2, even though you can probably see that the actual amount of CPU time spent was likely < 0.001% ?

A high load average may be an indication of the system being CPU starved, but I'd judge "high load average" to be 10-12x the number of CPUs present in the system, depending on the type of processes the machine is running.

You do understand what the load average figures are telling you, right? It is simply a count of how many processes running on the system needed CPU time per second during that interval, it does not tell you anything at all about the actual CPU time spent servicing those processes.

Eg, if I do a

Code:

while /bin/true; do echo "."; sleep 1; done

The load average will show as 2, even though you can probably see that the actual amount of CPU time spent was likely < 0.001% ?

A high load average may be an indication of the system being CPU starved, but I'd judge "high load average" to be 10-12x the number of CPUs present in the system, depending on the type of processes the machine is running.

Of course I do.

In this case it is the cgminer process causing that load, just as ebereon suggested.

You do understand what the load average figures are telling you, right? It is simply a count of how many processes running on the system needed CPU time per second during that interval, it does not tell you anything at all about the actual CPU time spent servicing those processes.

Eg, if I do a

Code:

while /bin/true; do echo "."; sleep 1; done

The load average will show as 2,

No it won't. The load measures the number of processes using CPU, waiting for CPU or waiting for I/O system calls to complete (basically reads and writes on file descriptors).

even though you can probably see that the actual amount of CPU time spent was likely < 0.001% ?

A high load average may be an indication of the system being CPU starved, but I'd judge "high load average" to be 10-12x the number of CPUs present in the system, depending on the type of processes the machine is running.

Load > nb of CPU threads may not have anything to do with CPU, just fork large number of processes writing to disk, they won't use much CPU on modern hardware (where every I/O use DMA) but your load will be as high as the number of processes you forked.

In the case of cgminer on Avalon with p2pool, ckolivas already replied in an earlier conversation that p2pool makes cgminer use more CPU than traditional pools. This doesn't show on "normal" CPUs but Avalon has a very weak one.

An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?

No that isn't the only difference, the other 2 major problems are:1) it's python - so it will use more CPU2) it only uses one thread by default and thus p2pool itself can easily get CPU starved on a machine with 16 cores ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

No that isn't the only difference, the other 2 major problems are:1) it's python - so it will use more CPU2) it only uses one thread by default and thus p2pool itself can easily get CPU starved on a machine with 16 cores ...

No that isn't the only difference, the other 2 major problems are:1) it's python - so it will use more CPU2) it only uses one thread by default and thus p2pool itself can easily get CPU starved on a machine with 16 cores ...

I'm talking about the Avalon device's CPU.

Ah OK, you mean profiling cgminer ... yep that does indeed need to be done.Guessing about profiling is one of the common mistakes by most programmers ... but yes (again) it does need to be done.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?

There's an obvious optimisation there that I didn't spot and it's only now that we have hardware being outstripped by the work generation requirements that I've looked into it. Thanks for the pointer, I shall see what I can do.

An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?

There's an obvious optimisation there that I didn't spot and it's only now that we have hardware being outstripped by the work generation requirements that I've looked into it. Thanks for the pointer, I shall see what I can do.

Yes, that did it. I've committed code to the cgminer git tree which dramatically reduces the cpu usage (confirmed on my avalon mining to p2pool). When my server comes back online I'll upload new avalon firmware.

What driver do you use for the erupters with BFGMiner? I have tried WinUSB (zadig) and the Silicon Labs CP210x drivers, and BFGMiner refuses to see either.

Get rid of WinUSB. Just use the VCP drivers for bfgminer - it'll work if you see your BEs being assigned a COM port in Windows.

The WinUSB drivers are, in my opinion, a HUGE mistake that the cgminer folks have made. It's unnecessarily difficult to get working, and gives no real benefit. The VCP drivers are a 2 second install, and they just work (or at least have for me on a few different machines on Server 2012, Win7 and Win8.

I guess you haven't noticed all the FTDI code in the clone that bypasses the COM ports ... of the fact that the ztex is ONLY libusb ... as is the x6500 code ... of that the COM ports are actually about 5 or 6 different drivers underneath them ... i.e. it a mix of many different drivers and code ...

cgminer is purely only direct USB, libusb for all drivers, and simple instructions (Zadig) that all but the inept can follow.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

That's not really true, is it? WinUSB and zadiag is an unnecessary complication. And an unreliable one at that.

VCP drivers, as I said above, are so simple anyone can get those working. It's a 2 second install, wait for the sticks to be installed, run miner.

No

Well, yes actually.

I don't understand?

It really is as simple as running the VCP driver installer (double click, press next, press finish). Plug in hub. Plug in Erupters. Wait a few minutes until Erupters are assigned COM port. Run bfgminer with -S erupter:all flag, job done.

That's literally from a fresh install of Windows. No other driver.

How can running zadiag and changing drivers per stick and all that jazz possibly be easier that doing nothing? My mind is literally boggling as to how you think all those extra steps are easier than one step.