[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[HellDiverUK]

(Zadig) that all but the inept can follow.

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.

[1714286859]

1714286859

[bitpop]

A complication is finding the com ports

[kano]

(Zadig) that all but the inept can follow.

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

[HellDiverUK]

(Zadig) that all but the inept can follow.

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. 

[-ck]

Well it is slightly more work initially, despite what kano says, but you run zadig as administrator, plug in ONE device, wait till windows finishes fscking around with it, then tell zadig to change that device to winusb (that's all the extra work there is). Then you don't need to specify any command line options for cgminer to recognise and use the device, and any time you plug in any other device of the same kind from then on forever more, it will run, including without restarting cgminer since it will hotplug them.

[HellDiverUK]

Well it is slightly more work initially, despite what kano says, but you run zadig as administrator, plug in ONE device, wait till windows finishes fscking around with it, then tell zadig to change that device to winusb (that's all the extra work there is). Then you don't need to specify any command line options for cgminer to recognise and use the device, and any time you plug in any other device of the same kind from then on forever more, it will run, including without restarting cgminer since it will hotplug them.

Finally, someone with some sense.  

I still prefer the new bfgminer interface (Blue bits!), and pool prioritization facility (rather than the plain old Failover etc of cgminer).   

[xgtele]

Is there any option in p2pool to send an email when payout is generated?

[Krak]

Is there any option in p2pool to send an email when payout is generated?

If you use Blockchain.info to watch your address, you'll get an email when you receive a payment.

[xgtele]

Is there any option in p2pool to send an email when payout is generated?

If you use Blockchain.info to watch your address, you'll get an email when you receive a payment.

For BTC this is fine, but do you have any ideas how to get notifications for LTC payouts?

[Ghost of USD]

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.

Cool. Can't wait to test it.

[kano]

(Zadig) that all but the inept can follow.

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.  

I never said it was easier than doing nothing.
Quote where I said that?

Though as you pointed out yourself - it isn't "doing nothing" to do it your way either ...

Sheesh, I can't stand people who argue about crap just so they pretend they never say anything incorrect.

It is however, easy to do for all but the inept.

Not only that, you don't have to wait.
You start cgminer even before you plug them in with all the other hardware you already have ...
and when you plug them in, and they are detected properly, cgminer will start using them.
For the first one that requires using Zadig, rather than using "VCP driver installer"
For the rest it is ... nothing.

[Ghost of USD]

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.

Cool. Can't wait to test it.

Managed to figure out how to cross compile cgminer from the git repo.

Latest version brings down the CPU usage to ~20%, not quite as optimized as bfgminer, but now we have plenty of headroom on the TP-Link to hash at p2pool with full power.

Thank you ckolivas!

[-ck]

Thanks for testing. Still got a little bit more to squeeze out of it but the cpu usage will always look a little higher due to the driver cpu usage all being attributed to cgminer now instead of hidden in the operating system (since there is no driver with direct usb).

[-ck]

Thanks for testing. Still got a little bit more to squeeze out of it but the cpu usage will always look a little higher due to the driver cpu usage all being attributed to cgminer now instead of hidden in the operating system (since there is no driver with direct usb).

I've completed the rework of the stratum work generation code which was where most of the high CPU usage on p2pool was, and uploaded new firmware with the newly released version 3.3.3 of cgminer:

EDIT: Updated link, with slightly newer firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/

[K1773R]

Thanks for testing. Still got a little bit more to squeeze out of it but the cpu usage will always look a little higher due to the driver cpu usage all being attributed to cgminer now instead of hidden in the operating system (since there is no driver with direct usb).

I've completed the rework of the stratum work generation code which was where most of the high CPU usage on p2pool was, and uploaded new firmware with the newly released version 3.3.3 of cgminer:

http://ck.kolivas.org/apps/cgminer/avalon/20130813/

great, seems i have to try stratum + p2pool again, as stratum was worse than getwork and +<diff>, tough i dont have avalons

[bronan]

Well i allways loved cgminer but i switched simply because the other just runs without doing any zadig crap.
It probably depends also on which version of windows your running in my case windows 8 pro x64.

You say : install zadig once and all work....... The hell it does not

It will not install on all usb devices.
You have to freaking add all by hand every freaking device

It simply not install any other then that one device you did, in my case each and every block erupter YES all 12

True after that .. it works flawless with this zadig, unless you want to use a different hardware with it ... like bfl jalapeno

Because indeed i could not get the freaking jala to work with or without zadig at all, cgminer simply refused to find that thing.
Even though it was clearly visible as a FTDI device in windows

And last but not least to get the zadig crap out your kinda busy as well, the only simple solution is delete each and every usb driver which was used with zadig and keep deleting them till the libusb driver is back instead of winusb.
It really turned out to be nastier then i expected, even now some ports still got the winusb installed after several attempts to get rid of them. I have not found one simple solution to remove that winusb driver yet.
The libusb which the zadig tool puts in IS not the one which works flawless with bfgminer

[K1773R]

Well i allways loved cgminer but i switched simply because the other just runs without doing any zadig crap.
It probably depends also on which version of windows your running in my case windows 8 pro x64.

You say : install zadig once and all work....... The hell it does not

It will not install on all usb devices.
You have to freaking add all by hand every freaking device

It simply not install any other then that one device you did, in my case each and every block erupter YES all 12

True after that .. it works flawless with this zadig, unless you want to use a different hardware with it ... like bfl jalapeno

Because indeed i could not get the freaking jala to work with or without zadig at all, cgminer simply refused to find that thing.
Even though it was clearly visible as a FTDI device in windows

And last but not least to get the zadig crap out your kinda busy as well, the only simple solution is delete each and every usb driver which was used with zadig and keep deleting them till the libusb driver is back instead of winusb.
It really turned out to be nastier then i expected, even now some ports still got the winusb installed after several attempts to get rid of them. I have not found one simple solution to remove that winusb driver yet.
The libusb which the zadig tool puts in IS not the one which works flawless with bfgminer

welcome to winblows

[bronan]

lol
I admit tux has some advantages but also has many disadvantages
If i would not have to cope with 5 ladies using winblows software like *cough* ms office *cough* and if games really would run smooth and instant on tux, like they do on winblows i would instant switch over.
This far non of the game industry is willing and able to port their games over to linux.
So i guess thats not gonna happen anytime soon, and i expect that not to happen for at least 10 decades.

[-ck]

I believe this is why the abbreviation YMMV was invented, but we love you still.

[stevegee58]

...and if games really would run smooth and instant on tux, like they do on winblows i would instant switch over.

I was quite the gamer in my time.  Fortunately I've moved on and it no longer influences me in important decisions like this.