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

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Quote from: ztex on February 28, 2012, 12:25:50 PM

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 Huh

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

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Turbor on February 28, 2012, 12:00:38 PM

Quote from: ztex on February 28, 2012, 07:13:08 AM

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

legendary

Activity: 1022

Merit: 1000

BitMinter

Quote from: ztex on February 28, 2012, 07:13:08 AM

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

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Turbor on February 27, 2012, 01:28:31 PM

Quote from: ztex on February 27, 2012, 09:25:46 AM

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

legendary

Activity: 1022

Merit: 1000

BitMinter

Quote from: ztex on February 27, 2012, 09:25:46 AM

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.

CA Coins

donator

Activity: 305

Merit: 250

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

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Turbor on February 27, 2012, 06:23:11 AM

Thanks for the info. It looks like i can do nothing about that.

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

Quote

What is different with cgminer that it works (almost) without problems ?

Any mining software will produce overflows if the server is not reachable. The difference is propably that cgminer dows not report this overflows.

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Thanks for the info. It looks like i can do nothing about that. Local speed is ok. All other pools work fine with your software. What is different with cgminer that it works (almost) without problems ? Or what can Pirate change to make it work better ?

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Turbor on February 26, 2012, 03:52:31 PM

Code:

...
bus-0-0: poll loop time: 475ms (USB: 0ms network: 475ms) getwork time: 1730ms
...

Why is the poll loop time so much higher?

See your logs, it is caused by a slow network. Maybe the pool server is attacked.

Quote

What does the "Warning: jsonParse: Parameter `data' not found" mean ?

This means the pool server returns an invalid getwork response.

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Yes, i run the newest version.

CA Coins

donator

Activity: 305

Merit: 250

Are you running the latest 120221.jar? I checked my logs and I haven't seen this error since ztex fixed the LP bug. This is what I got before the bug was fixed:
"Error: jsonParse: Parameter `data' not found: Disabling URL..."

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Ping times are around 200ms for the pool... works well with my 3 GPUs and cgminer 2.3.1

CA Coins

donator

Activity: 305

Merit: 250

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

I have some problems here getting GPUMAX to run. Here is what i get with BitMinter.

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz, errorRate=0.02%, maxErrorRate
=0.74%, hashRate=208.0MH/s, submitted 18 new nonces, luckFactor=1.03
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz, errorRate=0.99%, maxErrorRate
=1.86%, hashRate=209.9MH/s, submitted 16 new nonces, luckFactor=0.94
bus-0-0: poll loop time: 15ms (USB: 0ms network: 15ms) getwork time: 144ms su
bmit time: 293ms
Total hash rate: 417.9 MH/s
Total submitted hash rate: 409.5 MH/s
--------
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz, errorRate=0.12%, maxErrorRate
=0.74%, hashRate=207.8MH/s, submitted 15 new nonces, luckFactor=1.03
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz, errorRate=0.46%, maxErrorRate
=1.86%, hashRate=211.0MH/s, submitted 9 new nonces, luckFactor=0.91
bus-0-0: poll loop time: 15ms (USB: 0ms network: 15ms) getwork time: 179ms su
bmit time: 280ms
Total hash rate: 418.8 MH/s
Total submitted hash rate: 404.5 MH/s
--------
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz, errorRate=0.26%, maxErrorRate
=0.74%, hashRate=207.5MH/s, submitted 11 new nonces, luckFactor=1.01
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz, errorRate=0.96%, maxErrorRate
=1.86%, hashRate=210.0MH/s, submitted 11 new nonces, luckFactor=0.91
bus-0-0: poll loop time: 16ms (USB: 0ms network: 16ms) getwork time: 187ms su
bmit time: 287ms

And now GPUMAX.

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: Using LongPolling URL http://gpumax.com:8332
/listenChannel
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=200.00MHz, errorRate=0.00%, maxErrorRate
=0.00%, hashRate=200.0MH/s, submitted 1 new nonces, luckFactor=0.36
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=200.00MHz, errorRate=0.00%, maxErrorRate
=0.00%, hashRate=200.0MH/s, submitted 0 new nonces, luckFactor=0.00
bus-0-0: poll loop time: 145ms (USB: 0ms network: 145ms) getwork time: 1416ms
submit time: 1078ms
Total hash rate: 400.0 MH/s
Total submitted hash rate: 71.6 MH/s
--------
Warning: jsonParse: Parameter `data' not found
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 204.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 204.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=204.00MHz, errorRate=0.00%, maxErrorRate
=0.00%, hashRate=204.0MH/s, submitted 16 new nonces, luckFactor=1.00
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=204.00MHz, errorRate=0.00%, maxErrorRate
=0.00%, hashRate=204.0MH/s, submitted 13 new nonces, luckFactor=0.77
bus-0-0: poll loop time: 475ms (USB: 0ms network: 475ms) getwork time: 1730ms
submit time: 2104ms
bus-0-0: Warning: 10 overflows occured. This is usually caused by a slow network
connection.
Total hash rate: 408.0 MH/s
Total submitted hash rate: 357.9 MH/s
--------
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 208.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 208.00MHz
New block detected by block monitor
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 212.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 212.00MHz
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 208.00MHz

Why is the poll loop time so much higher ? What does the "Warning: jsonParse: Parameter `data' not found" mean ?

CA Coins

donator

Activity: 305

Merit: 250

Great, thanks for the info. I will give it a test run if I get a chance.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: CA Coins on February 22, 2012, 11:34:48 AM

The 120221.jar seems to be running well with no-issues. I am not sure I want to artificially test the disable on downclock feature by turning off the fan, but it is a nice to feature to have. Does it measure the 2-clock down from the base 200Mhz or from what whatever the clock has been running at (I am mostly at 204 and 208)?

The reference frequency is the highest frequency which is stable for a while.

If you want to test it, there is a "ztex_ufm1_15d3a.ihx" firmware with 1.41 MHz frequency steps in the package. (Just for fun. Will be removed in future.)

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: CA Coins on February 21, 2012, 02:07:13 PM

Thanks for the new feature Ztex. Do you think capping the maximum frequency overclock may improve the longevity of the FPGAs?

Only if the FPGA gets very hot (>60 °C). In that case I would recommend a better cooling.

CA Coins

donator

Activity: 305

Merit: 250

The 120221.jar seems to be running well with no-issues. I am not sure I want to artificially test the disable on downclock feature by turning off the fan, but it is a nice to feature to have. Does it measure the 2-clock down from the base 200Mhz or from what whatever the clock has been running at (I am mostly at 204 and 208)?

Regardless, it is a nice safety feature to have. I am sure it will come in handy once the summer comes or one of those fans are bound to fail at some point. Thanks for programming it in and keep up the good work!

CA Coins

donator

Activity: 305

Merit: 250

Quote from: Turbor on February 21, 2012, 06:19:58 PM

Good feature, tnx a lot. What is the difference between 0 and 0.1 ? 0 is two clocks down and 0.1 ?

I am thinking 0 means shutdown when drop by 2 steps, i.e. 8 Mhz with d3a, and 0.1 means frequency drop by a factor of 0.1, or 10%, ie say 200 to 180Mhz.

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Good feature, tnx a lot. What is the difference between 0 and 0.1 ? 0 is two clocks down and 0.1 ?

Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 18. (Read 161727 times)