[...]
Can somebody explain me that?
The effect was correctly explained, i.e. what cgminer reports as hashrate needs to be halved to get the correct value for the CM1 operating with the
twin_test.bit bitstream, while the U factor is correct.
Alas, the root cause is not related to the timing settings that are floating around, it is more a result of how cgminer and the Icarus driver work and the fact that one FPGA of each pair is not operable. If you don't care the details, skip to the tl;dr line.
Heh - well then someone should read the FPGA-README in cgminer that I wrote quite a while ago:
The Icarus code currently only works with a dual FPGA device that supports the same commands as
Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
correct hash time nanoseconds value
So yes I stated this when I wrote the code that it required a pair of FPGA (hashing half each)
If these boards are only hashing half the range on a single FPGA then the MH/s value will of course report double what it really is.
The code itself simply doubles the count of hashes completed each time since it knows EXACTLY how many hashes were done and how long it took and assuming there are 2 FPGA (as I said above) then double ((nonce & 0x7fffffff) + 1) is of course correct - NOT an estimate AT ALL.
Cgminer Work Processing
To understand the numbers, it is important to understand how the work is processed between pools/bitcoind and the worker: work is fetched from pool(s) and provided to the related driver in chunks of a whole nonce ranges (2^32 hashes). The working unit (being it CPU, GPU, or FPGA) calculates the hashes and reports back valid shares and how much hashes have been processed.
Close ... Icarus simply reports back a nonce value (as stated above) and nothing else
(also in the case of GPUs the miner breaks the work up into tiny bits (seriously tiny) and feeds them to the GPU)
Using Icarus driver for CM1You need to know the Icarus API to understand the numbers. The API to the Icarus provides no status queries: there is no command to ask the board if it is present or how far it is in processing the nonce range. The only function supported is: you sent it work and it reports you the nonce generating a share - thats it.
As a result of this limited functionality, two workarounds are used in cgminer:
- To detect whether an Icarus is attached to a serial line, you feed it with work containing a 'golden nonce', that is known to be found very soon (say after some milliseconds) in the range. If an attached device reports what you expect, you found an Icarus, otherwise you see a warning that an unexpected nonce (or nothing) was reported.
- Being unable to query the process in the nonce range requires some timeouts, in case there is work containing zero valid shares. For that you need to know how long the Icarus is busy crunching the work package, which is easily calculated by (2^32 / hashrate). If after that time you did not hear from your board, you just give it something else to work on. If the timeout value is too long, you risk the FPGA idling around, if it is too short you are aborting nonce ranges and feeding more work than required, which impairs efficiency due to serial line communication delays.
Underestimating the abort time is not a big issue.
The serial I/O per nonce range is approx 5ms or ~0.1% so if you are aborting at 50% of the range it's still only an extra ~0.1% per share.
...
Hashrate
The hashrate is calculated as (hashes reported by driver / elapsed time). cgminer fully relies on what the related driver reports and has no means to verify that the work has really been completed - one can easily write a driver that reports 10TH for a device. It is a tribute to the established MHps measure, but a not exactly precise and controllable one.
Read the FPGA-README ...
When a CM1 FPGA-pair is fed with work, it only operates the first half of it, but reports that the whole range was done. As a result, the reported MHps value is exactly doubled. A side effect of this fact is that twice as many getworks are required. It is possible to modify the reported hashes in a dedicated CM1 driver to correct the hashrate displayed, but given that the Icarus bitstream is only an interim solution, it is easier to add some brain-work and just halve it.
Utilization Factor U
This is the real performance factor, since it reports the average accepted shares by the pool per minute. It is what you get as income and calculated by cgminer independent of the underlying driver. For a CM1 this should be somewhere ~2.5/m per FPGA, a board should provide you 5/m.
Unless the FPGA's perform worse than the Icarus, they should get ~2.65/m and the board ~5.3/m
Of course, as I stated before, it can take days to start to converge to that value.
Icarus Timings
With CM1 operating with the twin_test bitstream, there is no need to adjust the timings as the clocks are the same as with Icarus. This is only required when the clocks change (like it was for the shipping_test bitstream).
However, unless they really are the same (and all the numbers quoted so far by everyone are incorrectly low) you should run --icarus-timing long to confirm that the hardware is indeed the same speed and the Hs value will tell you if it is - again all the numbers reported so far say it is less.
The Icarus Hs value is 0.0000000026316 (2.6316ns)
Tl;drWhen operating CM1 in Icarus mode (twin_test.bit)
- the reported hashrate must be halved and should be around 380 MHps per board
- the reported U is correct and should be somewhere around 5/min per board
- no timing parameters are required
HTH
Halved: yes (since it does seem half the FPGA are idle doing nothing and U: shows that)
U: again - don't pay too much attention to U: unless it been running for at LEAST a few days ...
As long as these things are hashing at the same speed as an Icarus, then there is no need for timing parameters, however if they do hash slower, then setting the parameter will increase performance, but only ever so slightly
If they do hash more than 384MH/s (or really more than 192MH/s per FPGA) , then using the default Icarus parameters will slow it down.
.. but for now Im going with the temporary flash.
