Cairnsmore1 - Quad XC6SLX150 Board

[ebereon]

I have one unit that have only 1.78 U/m and i saw it in MPBM that the unit sometimes had no COM connection, but the COM port was show up still in the device manager.

I changed the USB cable and now its working @~2.7 U/m and no more disconnects from MPBM since some hours now.

[norulezapply]

I have one unit that have only 1.78 U/m and i saw it in MPBM that the unit sometimes had no COM connection, but the COM port was show up still in the device manager.

I changed the USB cable and now its working @~2.7 U/m and no more disconnects from MPBM since some hours now.

How do you get it to log stuff like this in MPBM?

[ebereon]

I have one unit that have only 1.78 U/m and i saw it in MPBM that the unit sometimes had no COM connection, but the COM port was show up still in the device manager.

I changed the USB cable and now its working @~2.7 U/m and no more disconnects from MPBM since some hours now.

How do you get it to log stuff like this in MPBM?

Take a look here > https://bitcointalk.org/index.php?topic=78239.msg1030353#msg1030353

I have modified the statistic webpage of mpbm to see the U/m. To see the disconnects you have to watch the webpage of mpbm and you will see sometimes that the "Current MH/s" column show you "0".

[yohan]

To stop Kano's bitching, it might be a good idea to provide remote access to a device so that he can fix the cgminer bugs that the hardware seems to be tickling.
...

What cgminer bugs?
If there is one - yeah I'm happy to see what it is and fix it.
But there is also a thread for that and a way to report bugs so that they can be fixed.
I guess you need lessons about that too?

I don't see one reported other than crap about an old version having an issue when the internet connection is shit.
I'm sure everyone here using these boards and having problems has crap internet issues ... yeah good excuse that one ...

So far all that Yohan has been posting for the last while are fixes for problems with his hardware and the only posts I see here recently about using cgminer is that it works ... except this stupid comment about a hash rate issue with an old version when the internet is shit.

...
wildemagic, geez, I don't even know what to say. It appears that you have no idea what a monumental task it is to provide a complete hardware and software package. Perhaps you should be over at the Lancelot thread, moaning about how it hasn't even been delivered yet?

This hasn't been delivered yet either.
Working and reliable bitstreams happen be be rather important to FPGA mining - bookends and doorstops don't really cut it.
I wouldn't start bringing up some other hardware that ISN'T accepting money yet and complain about them not delivering ...

Kano I am not in any way having a go at CGminer or the CGminer team or the hard work that goes on there on your team. Any post on this thread is a mixture of telling our customers of what we know and also a way to gather data to see if it fits with customer experience. This is purely a process to make things better and also to help us here to find the source or sources of a bug. I don't even what to attribute blame as a certain person thinks. It's all about identifying what causes a problem and even then it will often be a blend of things. If by changing one thing that fixes an issue that is good enough by us and that doesn't matter if it's software, firmware or even hardware as long as we find a solution. That's how we work.

Personally I'm not the correct person to report a software bug. I know every little about the software side and so far I have not even gone as far as identifing the correct place to post the bug report. Unless you happen to come from Airbus there is always a possibility of a bug. The circumstances we had here yesterday were unusual for a landline broadband but not unlike 3G based broadband users might get. It does appear that version 2.5.0 of CGminer maight be a good move from customer response. The 2.4.3 choice was made 11 weeks ago and that probably made sense at that point when we did initial system design. Obviously thimgs have moved on and when the relkevant person is back in the office we we look at this more closely and contact you as appropriate. Part of what we are doing now could be called integration, support, or even round2 of system design and we have to pull together all of the different aspects of the system and make it all perform.

[Lethos]

I will however try tinkering with the time min read/write timeout function, since it could be triggering too early.

Tinkered with the min read/write timeout in the advance usb settings for the ports... no...
OMG, don't do it, it did nothing, and swear made it worse.
Also changing bauds rates / bits per second has no effect either.
I now agree with the others, I can't see any use in trying to tinker with the usb settings, it does not help.

I'm now testing it one on my linux laptop, while the other remains on my windows laptop.

[ebereon]

... The 2.4.3 choice was made 11 weeks ago ...

I knew there was something wrong...

You was trying to use the version 2.4.3 but you took the wrong very old version 2.3.4. Did you noticed?

[yohan]

Any tips or advice on getting the hardware stable for more than 2 hours plus. It tells me that both of the units have failed.
I'll get an exact copy of the message next time it occurs. At first I figure maybe it was the usb slot was powering down or something.
But it's also happened in under 30minutes of me running it. I've also set all my usb slots to not turn them off to save power early on in testing these.

The com ports are often what disappears from the device manager, at which point I assume that is why they stop working.
Is their anything that that can help force them to stay... hmm maybe I'll go look.

I've solved all the software stability problems just by moving upto to Cgminer 2.5. That is far more stable than previous versions, good work on that Kano and the team (there is more than 1 of you right?)

No one appears to have a simple works for all solution for this. Basicly we just need to wait till enterpoint rolls out a stable controller. I fiddled with the usb-power saving settings also, but it made no difference. The problem is that the boards randomly dissapear from your device manager and you need to power them off and on (preferrably detatching the usb cable while doing it). You might want to try a different usb-port for the device dissapearing, make note of it the next time it happens. I've been able to get ~20hour sessions this way, but once you get there you might find an issue where one of the boards stops finding shares. Thusfar I have no workaround to that. If your leaving your boards hashing alone for a long time, you can minimize the mining time lost, by running them in separate cgminer instances. so that when one board dissapears, only the cgminer it's on crashes and the other one keeps hashing.

My findings are on 64bit win 7 using enterpoints cgminer, twin_test bitstream and controller version 1.2

I would recommend updating the Controller to Rev 1.3. For most customers this is an improvement. Rev 1.4 isn't far off and might also bring a few subttle improvements. I'm doing that in my spare time which pretty much non-existant so that is slow progress. There is also a software debug tool coming that will check an entire rig out for any coms problems. We are using a raw version of that here not to set up our big test rig already. We will try and make that customer friendly towards the end of the week.

[wildemagic]

The circumstances we had here yesterday were unusual for a landline broadband but not unlike 3G based broadband users might get.

It shouldnt really be an issue.  I use 3G and CGMiner copes with disconnects and reconnects/change of IP and also with devices being switched off and later switched back on.
The only real issue is loss of comms, it doesnt seem to recover with a serial port going 'weird' or being disabled.

You could try the --no-pool-disable to avoid CGMiner disabling the pool on loss of comms, also try this in conjunction with the --net-delay if the connection is unstable.

kind regards

[yohan]

... The 2.4.3 choice was made 11 weeks ago ...

I knew there was something wrong...

You was trying to use the version 2.4.3 but you took the wrong very old version 2.3.4. Did you noticed?

I must admit I hadn't. I'll try and check but is fairly academic if we recommend to go to 2.5.0 anyhow assuming I got that bit right. It does look like that is the best thing for everyone to do.

[ebereon]

... The 2.4.3 choice was made 11 weeks ago ...

I knew there was something wrong...

You was trying to use the version 2.4.3 but you took the wrong very old version 2.3.4. Did you noticed?

I must admit I hadn't. I'll try and check but is fairly academic if we recommend to go to 2.5.0 anyhow assuming I got that bit right. It does look like that is the best thing for everyone to do.

Good to know you noticed it now! That is what Kano meant, and that is the big problem i think with people that using you cgminer and have some problems with it. I think the correct or new version of cgminer will let dissapear a lot of problems.

eb

[yohan]

... The 2.4.3 choice was made 11 weeks ago ...

I knew there was something wrong...

You was trying to use the version 2.4.3 but you took the wrong very old version 2.3.4. Did you noticed?

I must admit I hadn't. I'll try and check but is fairly academic if we recommend to go to 2.5.0 anyhow assuming I got that bit right. It does look like that is the best thing for everyone to do.

Good to know you noticed it now! That is what Kano meant, and that is the big problem i think with people that using you cgminer and have some problems with it. I think the correct or new version of cgminer will let dissapear a lot of problems.

eb

We will have a talk internally on Thursday/Friday when we have the relevant people back from holiday but it's more or less guaranteed that we will go to 2.5.0 of CGminer as the level we are working with.

[yohan]

Array FPGA pin constraints are now available for bitstream developers and customers on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html.

[Lethos]

Array FPGA pin constraints are now available for bitstream developers and customers on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html.

Thanks Yohan. This helps move my code forward quiet a bit.

[Isokivi]

This propably isnt the correct place to ask this, but im almost certain that asking anywhere else would result in 2 pages of questions, trolling, etc about how I use cgminer. So here goes:

How do I add a backup pool to this .bat im running to start my boards:

Code:

 cgminer -o http://pool.com -u me -p pass --disable-gpu -S noauto -S \\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31 -S \\.\COM34 -S \\.\COM35 

?

[Dargo]

This propably isnt the correct place to ask this, but im almost certain that asking anywhere else would result in 2 pages of questions, trolling, etc about how I use cgminer. So here goes:

How do I add a backup pool to this .bat im running to start my boards:

Code:

 cgminer -o http://pool.com -u me -p pass --disable-gpu -S noauto -S \\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31 -S \\.\COM34 -S \\.\COM35 

?

I believe you just add an iteration of "-o http://pool.com -u me -p pass" after the first with your backup pool info. You may also want to add "--failover-only" if you find that cgminer is leaking work to your backup pool and you don't want this. This, at least, is what you do for GPUs, and I don't think it's any different for FPGA. I use Ozcoin pool, and this pool does tend to lag enough that work gets leak to backups, so I actually have three pools servers with the first two Ozcoin and the third my real failover. With just one primary and a failover, I found I was getting around 2% stales, and was able to cut this in half by having a second backup server on Ozcoin with a non-Ozcoin pool as my third pool (failover). To add a third pool, you just iterate the pool info after the first two of course.

[Lethos]

This propably isnt the correct place to ask this, but im almost certain that asking anywhere else would result in 2 pages of questions, trolling, etc about how I use cgminer. So here goes:

How do I add a backup pool to this .bat im running to start my boards:

Code:

 cgminer -o http://pool.com -u me -p pass --disable-gpu -S noauto -S \\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31 -S \\.\COM34 -S \\.\COM35 

?

Personally I've always prefered to use the conf file for this stuff.
However page 1 (front page) of the CGminer thread, does give an example of how to do multiple pools.
https://bitcointalk.org/index.php?topic=28402.0

Multiple pool, dedicated miner:

Code:

cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password

[spiccioli]

After nearly one week of hashing I've got a stuck FPGA, controller rev. 1.3, ICA 7 is stuck, no more increasing A: and a slowly decreasing U:.

I'm offsite, right now, so I can't see leds.

ICA 9, while slower than the others, is still hashing.

Code:

 cgminer version 2.4.3 - Started: [2012-07-13 07:26:50]
--------------------------------------------------------------------------------
 (5s):8053.2 (avg):7381.1 Mh/s | Q:1251980  A:461192  R:463  HW:0  E:37%  U:50.8/m
 TQ: 20  ST: 21  SS: 12  DW: 16222  NB: 985  LW: 1059  GF: 794  RF: 6
 Connected to http://pool.abcpool.co with LP as user ....
 Block: 000006b34a33513bc9eb387c3868ad63...  Started: [14:36:38]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 379.7/369.0Mh/s | A:23785 R:25 HW:0 U: 2.62/m
 ICA 1:                | 379.9/369.2Mh/s | A:21985 R:21 HW:0 U: 2.42/m
 ICA 2:                | 379.9/369.3Mh/s | A:23616 R:25 HW:0 U: 2.60/m
 ICA 3:                | 379.9/369.1Mh/s | A:22531 R:24 HW:0 U: 2.48/m
 ICA 4:                | 379.9/369.1Mh/s | A:23555 R:20 HW:0 U: 2.60/m
 ICA 5:                | 379.9/369.2Mh/s | A:23276 R:18 HW:0 U: 2.56/m
 ICA 6:                | 379.8/368.9Mh/s | A:23412 R:18 HW:0 U: 2.58/m
 ICA 7:                | 380.0/368.8Mh/s | A:19404 R:25 HW:0 U: 2.14/m
 ICA 8:                | 380.0/369.1Mh/s | A:23357 R:27 HW:0 U: 2.57/m
 ICA 9:                | 379.9/369.0Mh/s | A:20225 R:20 HW:0 U: 2.23/m
 ICA 10:                | 379.9/369.1Mh/s | A:23369 R:28 HW:0 U: 2.58/m
 ICA 11:                | 379.8/369.0Mh/s | A:23479 R:18 HW:0 U: 2.59/m
 ICA 12:                | 379.8/369.1Mh/s | A:23569 R:23 HW:0 U: 2.60/m
 ICA 13:                | 379.8/369.1Mh/s | A:23568 R:24 HW:0 U: 2.60/m
 ICA 14:                | 379.8/368.9Mh/s | A:23718 R:26 HW:0 U: 2.61/m
 ICA 15:                | 379.8/369.1Mh/s | A:23572 R:22 HW:0 U: 2.60/m
 ICA 16:                | 379.9/369.1Mh/s | A:23605 R:21 HW:0 U: 2.60/m
 ICA 17:                | 379.9/369.1Mh/s | A:23636 R:23 HW:0 U: 2.60/m
 ICA 18:                | 379.9/369.0Mh/s | A:23864 R:28 HW:0 U: 2.63/m
 ICA 19:                | 379.9/369.1Mh/s | A:23667 R:27 HW:0 U: 2.61/m
--------------------------------------------------------------------------------

 [2012-07-19 14:42:27] Accepted db79cec0.6baf9979 ICA 15 pool 0
 [2012-07-19 14:42:27] Accepted ed056591.9f6352fb ICA 11 pool 0
 [2012-07-19 14:42:28] Accepted 450ac3a5.68c071a5 ICA 10 pool 0
 [2012-07-19 14:42:29] Accepted 2da3d070.81b5abfa ICA 0 pool 0
 [2012-07-19 14:42:31] Accepted cf2cae0d.324cfbb1 ICA 3 pool 0
 [2012-07-19 14:42:31] Accepted e581471c.2e5f3f08 ICA 0 pool 0
 [2012-07-19 14:42:34] Accepted 136bbf74.b7345085 ICA 2 pool 0
 [2012-07-19 14:42:37] Accepted c1997113.91085fe7 ICA 3 pool 0
 [2012-07-19 14:42:37] Accepted 378bec29.4aa35877 ICA 9 pool 0
 [2012-07-19 14:42:38] Accepted 14bad6b8.19cfc4e0 ICA 5 pool 0
 [2012-07-19 14:42:41] Accepted 9baa0cb9.6eb66538 ICA 12 pool 0

spiccioli.

[Lethos]

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

[dietwice]

Just wondering:

Newly arrived Quad Cairnsmore1 board shows me something like this:

 ICA 0:                | 360.0/361.2Mh/s | A:279 R:3 HW:0 U:2.37/m
 ICA 1:                | 364.7/362.3Mh/s | A:295 R:3 HW:0 U:2.50/m

Whilst the old GPU rig shows a bit different:

 GPU 0:  68.0C 5210RPM | 383.5/404.7Mh/s | A:60299 R:896 HW:0 U: 5.55/m I: 9
 GPU 1:  59.5C 3016RPM | 281.3/328.2Mh/s | A:48870 R:736 HW:0 U: 4.50/m I: 9

Isn't it strange that almost the same Mh/s values of GPUs give about twice more shares per minute than the Cairnsmore1?
So the real effectiveness of the device is about a half of what it shows.

Can somebody explain me that?

All values were captured from cgminer 2.5.0.
The 2.3.4 version from the support materials shows almost the same.
Controller version is 1.3, connection is fast and stable.

Thanks.

[LazyOtto]

Just wondering:
...
So the real effectiveness of the device is about a half of what it shows.

Can somebody explain me that?

Yes, with default cgminer settings the MH/s on these things show about twice reality.

IIRC, somewhere back in this long thread there is a command line switch or other work-around to rectify that.

Time to hone your search-fu skills.