BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150

[CA Coins]

Does GPUmax have a slightly different protocol since it relays you to the different pools?

[Turbor]

You can try the "-n 1" option, i.e. one device per thread. But that only reduces the impact of the network problems.

  -n 1 helped. I'm down to below 40ms per thread now. No more overflows ! Thanks a lot for your continued support.

[ztex]

You can try the "-n 1" option, i.e. one device per thread. But that only reduces the impact of the network problems.

  -n 1 helped. I'm down to below 40ms per thread now. No more overflows ! Thanks a lot for your continued support.

Someone solved the network problems (or the attack has been ended). "-n 1" only reduces the possibility of overflows if the network is slow. It does not influence the "getwork time" and "submit time".

[Turbor]

Someone solved the network problems (or the attack has been ended). "-n 1" only reduces the possibility of overflows if the network is slow. It does not influence the "getwork time" and "submit time".

Yes, the overflows come and go. Getwork times go from 700 to 2k ms...

[ztex]

Someone solved the network problems (or the attack has been ended). "-n 1" only reduces the possibility of overflows if the network is slow. It does not influence the "getwork time" and "submit time".

Yes, the overflows come and go. Getwork times go from 700 to 2k ms...

Proper response times (getwork and submit) are less than 200 ms.

[Turbor]

Proper response times (getwork and submit) are less than 200 ms.

Internet is slow over here but i can get 250-300 ms with regular pools. Sadly i have not enough insider knowledge how GPUMAX exactly works.

If i ping the ip java is connected to (GPUMAX) i get this

Code:

Ping wird ausgeführt für 184.173.241.234 mit 32 Bytes Daten:
Antwort von 184.173.241.234: Bytes=32 Zeit=195ms TTL=50
Antwort von 184.173.241.234: Bytes=32 Zeit=194ms TTL=50
Antwort von 184.173.241.234: Bytes=32 Zeit=190ms TTL=50
Antwort von 184.173.241.234: Bytes=32 Zeit=193ms TTL=50

Ping-Statistik für 184.173.241.234:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 190ms, Maximum = 195ms, Mittelwert = 193ms

C:\Program Files\NetBalancer>

So no idea why the submit time is that high 

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.15%,  maxErrorRate
=0.99%,  hashRate=207.7MH/s,  submitted 16 new nonces,  luckFactor=0.98
bus-0-1: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.84%,  maxErrorRate
=2.35%,  hashRate=210.2MH/s,  submitted 9 new nonces,  luckFactor=0.97
bus-0-0: poll loop time: 34ms (USB: 0ms network: 34ms)   getwork time: 931ms  su
bmit time: 964ms
bus-0-1: poll loop time: 36ms (USB: 0ms network: 36ms)   getwork time: 938ms  su
bmit time: 977ms
Total hash rate: 417.9 MH/s
Total submitted hash rate: 404.8 MH/s
 --------
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.00%,  maxErrorRate
=0.99%,  hashRate=208.0MH/s,  submitted 16 new nonces,  luckFactor=0.98
bus-0-1: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.69%,  maxErrorRate
=2.35%,  hashRate=210.5MH/s,  submitted 14 new nonces,  luckFactor=0.97
bus-0-0: poll loop time: 35ms (USB: 0ms network: 34ms)   getwork time: 924ms  su
bmit time: 944ms
bus-0-1: poll loop time: 37ms (USB: 0ms network: 37ms)   getwork time: 963ms  su
bmit time: 990ms
Total hash rate: 418.5 MH/s
Total submitted hash rate: 404.9 MH/s
 --------
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.02%,  maxErrorRate
=0.99%,  hashRate=208.0MH/s,  submitted 24 new nonces,  luckFactor=0.98
bus-0-1: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.60%,  maxErrorRate
=2.35%,  hashRate=210.7MH/s,  submitted 5 new nonces,  luckFactor=0.97
bus-0-0: poll loop time: 36ms (USB: 0ms network: 36ms)   getwork time: 908ms  su
bmit time: 969ms
bus-0-1: poll loop time: 35ms (USB: 0ms network: 34ms)   getwork time: 950ms  su
bmit time: 990ms
Total hash rate: 418.7 MH/s
Total submitted hash rate: 404.9 MH/s

[antirack]

Possibly the pool's response time?

What happens if you change to a underutilized pool for testing?

[BR0KK]

Hi,

I'm using five boards in cluster mode atm. They work fine so far

Would be nice if BTC Miner gets a new interface --> i don't have the right words in english right now. i mean it should look like cgminer or some thing like that. Displaying every information like it is now can be confusing ?

Is that possible or something that can't be done?

Would like to be able to use cgminer ore different  miners with ztex boards aswell:)

[Turbor]

I like it the way it is.

[ztex]

Is that possible or something that can't be done?

Another UI is possible, but not planned.

[antirack]

I have received another 2 units so now I have a "cluster" of 3 ZTEX 1.15x. Had it running over night on my new cheapo 10 port USB hub (since I only plugged in 3 boards I didn't use the additional USB 5V 2.0A power supply that came with the hub).

It worked well from 21:12 to 08:53 this morning, but then the following happened:

Code:

2012-03-06T08:53:13: bus-0-0: ztex_ufm1_15d3-04A3469722: Error: bus=bus-0  device=\\.\libusb0-0003--0x221a-0x0100: Read hash data: libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.

: Disabling device

Then the second one followed at 10:29 when I plugged in my Icarus to the same USB hub.

Code:

2012-03-06T10:29:46: bus-0-0: ztex_ufm1_15d3-04A32E00E9: Error: bus=bus-0  device=\\.\libusb0-0002--0x221a-0x0100: Read hash data: libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.

: Disabling device

For the last one I didn't have to wait long:

Code:

2012-03-06T10:31:32: bus-0-0: ztex_ufm1_15d3-04A346CEC7: Error: bus=bus-0  device=\\.\libusb0-0001--0x221a-0x0100: Read hash data: libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.

: Disabling device
2012-03-06T10:31:32: Stopped thread for bus bus-0-0

Could that be a USB power issue or because the cheap USB hub interrupts when I plug/unplug other devices?

For the last two units connecting/disconnecting USB cables (connected to Icarus) seems to be the culprit, but I don't know what happened for the first unit at 8:53, I wasn't even near my computer at that time as far as I know (I may have logged in, but I definitely didn't touch the USB port/1.15x boards).

[ztex]

Code:

2012-03-06T08:53:13: bus-0-0: ztex_ufm1_15d3-04A3469722: Error: bus=bus-0  device=\\.\libusb0-0003--0x221a-0x0100: Read hash data: libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.

: Disabling device

That are USB connection errors. Typically caused by the power supply (loose contacts, instabilities if the PSU becomes to hot / output current to high) or by the USB hardware (cables, hubs, devices that draw to much USB power). A potential equalization problem is possible too.

[rupy]

Hi, can you gather temperature from the chip? Could we get a temperature/frequenzy controller as a complement to the error/frequenzy controller for passive cooling mining? My dream would be a -t <celsius> parameter which keeps the chip at that temperature!

[ztex]

Hi, can you gather temperature from the chip? Could we get a temperature/frequenzy controller as a complement to the error/frequenzy controller for passive cooling mining? My dream would be a -t <celsius> parameter which keeps the chip at that temperature!

No, chip temperature cannot be gathered.

[rupy]

Then can I get a parameter for specifying the initial frequency and another to disable initial step-up of frequency. You can cap the initial frequency parameter to max 200 since I'm going to use this to _lower_ the frequency for passive cooling during summer.

[Inspector 2211]

Then can I get a parameter for specifying the initial frequency and another to disable initial step-up of frequency. You can cap the initial frequency parameter to max 200 since I'm going to use this to _lower_ the frequency for passive cooling during summer.

Excellent idea, I second that.

Being able to specify the start frequency and the maximum frequency would be ideal for those of us who:
- have inadequate air conditioning
- want to make sure the FPGA has a long lifetime
- want to install a smaller cooled due to space constraints (i.e., putting multiple vertically arranged boards into an enclosure)

[Turbor]

Then can I get a parameter for specifying the initial frequency and another to disable initial step-up of frequency. You can cap the initial frequency parameter to max 200 since I'm going to use this to _lower_ the frequency for passive cooling during summer.

Hmmm i think the board can do this by itself ?! Sounds to me like reinventing the wheel or am i missing something ?

[rupy]

Yes, but then the chip will be really hot, hot enough to burn your fingers on the heatsink, and that's not good for longevity.

I don't mind hashing slower (I'm talking 100-200 range here), if it allows me to hash longer.

ZTEX, does the chip use 8W at 100MHz too? Or will the chip use like 4W and be half as warm?

I'm really just looking for settings to be able to passively cool the thing without having to worry.

It's a shame there is no temperature reading on the chip!

[Inspector 2211]

ZTEX, does the chip use 8W at 100MHz too?

No. Power consumption of a VLSI chip is the sum the static power (i.e. leakage), which is almost negligible, and dynamic
power, which is (by and large) proportional to the clock frequency.

Or will the chip use like 4W and be half as warm?

Yes.

It's a shame there is no temperature reading on the chip!

Putting analog circuits on an all-digital chip is more difficult than you think.
The particular semiconductor process chosen for FPGAs is an all-digital, high-speed process.
Adding analog elements like a thermal diode, its associated amplifier and an ADC on an all-digital semiconductor process is something like squaring the circle - at best, time-consuming, cumbersome and costly.
Just because Intel can do it, don't assume a fabless manufacturer like Xilinx can do it.

[Turbor]

Yes, but then the chip will be really hot, hot enough to burn your fingers on the heatsink, and that's not good for longevity.

I don't mind hashing slower (I'm talking 100-200 range here), if it allows me to hash longer.

ZTEX, does the chip use 8W at 100MHz too? Or will the chip use like 4W and be half as warm?

I'm really just looking for settings to be able to passively cool the thing without having to worry.

It's a shame there is no temperature reading on the chip!

Ok, i get you. I trust ZTEXs experience together with my extra fans.