Re: [400GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Oh, and since were on the topic of cgminer..... BEGIN RANT.
Someone f-ed up big time when programming/designing the cgminer to bitforce interface.
Its funny, because I happen to find a program that was transmitting on all FTDI serial ports every 10 seconds at 115200 baud.
It turns out that one of the "miners" called cgminer has code in it that wrecklessly opens ALL FTDI ports and transmits on them.
Its a program that is trying to find a device called "bitforce". (its a fpga hashing cpu) to mine digital hashes.
The problem is, that it opens ports to other devices that use the FTDI chip ALSO, and transmits ZXG every 10 seconds on ALL FTDI ports at 115200 baud.
From a bitforce perspective, they don't give a shit, they just want their product to work.
From a 3rd party hardware engineer, that is really really mean to do to other hardware developers that develop using the FTDI CHIP.
(tons of microcontroller programmers and devices use it)
I know no one will change the code to be more "serial port" and other device friendly, and I also know you won't mention it to the developer.
But it really IS bad practice to open ALL ports every 10 seconds, not just open them, but actaully transmitt, and operate the DTR lines(many devices use the DTR to operate the reset line on the microcontroller/chip.
https://github.com/ckolivas/cgminer/...ver-bitforce.c
This code is included in almost all "miners"
WTF drugs have you been taking?Someone f-ed up big time when programming/designing the cgminer to bitforce interface.
Its funny, because I happen to find a program that was transmitting on all FTDI serial ports every 10 seconds at 115200 baud.
It turns out that one of the "miners" called cgminer has code in it that wrecklessly opens ALL FTDI ports and transmits on them.
Its a program that is trying to find a device called "bitforce". (its a fpga hashing cpu) to mine digital hashes.
The problem is, that it opens ports to other devices that use the FTDI chip ALSO, and transmits ZXG every 10 seconds on ALL FTDI ports at 115200 baud.
From a bitforce perspective, they don't give a shit, they just want their product to work.
From a 3rd party hardware engineer, that is really really mean to do to other hardware developers that develop using the FTDI CHIP.
(tons of microcontroller programmers and devices use it)
I know no one will change the code to be more "serial port" and other device friendly, and I also know you won't mention it to the developer.
But it really IS bad practice to open ALL ports every 10 seconds, not just open them, but actaully transmitt, and operate the DTR lines(many devices use the DTR to operate the reset line on the microcontroller/chip.
https://github.com/ckolivas/cgminer/...ver-bitforce.c
This code is included in almost all "miners"
Quote
and so most computers that run a miner program most likely have this FTDI port access every 10 seconds
It will transmit "ZGX" at 115200 baud every 10 seconds on all FTDI ports.
Why a simple switch couldn't have been implemented to turn the bitforce port attacking ON, instead of having it run 24/7, till it finds a bitforce device, beats me.
Most of you have no idea that your cgminers are doing this to every serial port on your computer, every 10 seconds, because most of you don't do hardware development.
But if a hardware developer were to see this activity from a program, that hardware developer would have a few CHOICE words to use, and they wouldn't be pretty.
LULZIt will transmit "ZGX" at 115200 baud every 10 seconds on all FTDI ports.
Why a simple switch couldn't have been implemented to turn the bitforce port attacking ON, instead of having it run 24/7, till it finds a bitforce device, beats me.
Most of you have no idea that your cgminers are doing this to every serial port on your computer, every 10 seconds, because most of you don't do hardware development.
But if a hardware developer were to see this activity from a program, that hardware developer would have a few CHOICE words to use, and they wouldn't be pretty.
Go complain to the person who wrote the miner you are complaining about.
If it is cgminer you are talking about, then it's the windows driver that you are using at fault, not cgminer (... if anything above you have said it true)
Cgminer searches for BFL devices at startup ... but never again.
When a BFL device fails, it will attempt to restart it then, but otherwise, "ZGX" isn't sent for any other reason in cgminer.
What's the next fairytale you are going to make up?
--
Aside: if I look around the forum and IRC logs I'll find my comments about using serial, at all, being crap.
Lucky for you I've rewritten the MMQ code in the past week to use libusb, once I finish off the tidy up of the resource tracking, it will be available for use for the Icarus and Bitforce driver also.
Yeah I'm one of the cgminer developers
I wrote the API, the majority of the Icarus driver, and shortly most of the MMQ driver code also.
I'll be writing the ASIC drivers in cgminer too along with ckolivas.
If you have some actual useful knowledge or suggestions come visit IRC and help
Otherwise - fuck off.