Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 60. (Read 286370 times)

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

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.

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?

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.

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.

Take a look here > https://bitcointalksearch.org/topic/m.1030353

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".

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

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.

None of them have this, so not sure why you are advising that.
I know I'm looking in the right place, since my blackberry has it's own com port (tethering it) and it has that option in the advance tab.

These FPGA's have not, instead a whole array of other things. None of which relate to Fifo, or buffers.

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

So it's mostly luck right now, until a new control can improve stability? However I will try a few different usb settings just in case it helps.
I'm sure others have no problems at all, I seem to have the performance, but not the stability.

Later I will try my Linux rig, in case their is any difference there, it doesn't do much most of the time, so it will be far more dedicated to mining than this windows laptop is.

After reading some of the comments being bounced around on the last couple pages I thought I had better give a rundown on my own experience. I'm assuming by the number of boards shipped and the number of people posting in the thread that I'm one of many customers who have a batch of boards hashing away with no problems.

When I placed pre-orders for the boards I was under no illusion that they would be anything more than development boards. ie I would have to get them working off my own back, get a bitstream from a 3rd party or pay to have one developed in the short term. As far as I was concerned the boards would be no different than if I sent schematic's over to a pcb manufacturer and asked them to fabricate me the boards.

Have Enterpoint delivered on what they promised when I placed the pre-orders? Absolutely. In fact the boards I have are better than expected and the option that their is a channel for support even though I haven't used it is more than I was expecting at this current point in time.

I currently own 25 boards with that number increasing to a lot more as and when batches of pre-orders get shipped. Every board I currently have are working 100% which for a development board being sold at probably what is around cost price I can't complain at all.

All my boards just work. I've tried various pc's to get a feel for compatibility issues and besides a small issue with x58 boards (was expecting it tbh) I've got no problems.

Cable wise i'm using pre-tested right angle usb cables along with dlink 7 port powered usb hubs.

My first batch of boards have been hashing for over 2 weeks rock solid on the twin test bitstream. They are all showing around u2.62 with confirmation from the pool over this time of around 385Mh/s per board.

I've yet to have a single lockup/crash or any issue. I'm running the original controller software and I haven't updated it yet. I know the new versions fix a few bugs and provide a few new features but I'm a firm believer that if it's not broken don't fk with it so i'll leave my boards hashing at 385 until a 4 core bitstream is released as then the juice will be worth the squeeze as they say.

I'll make another post in the next couple day's when my next batch of boards hopefully arrive and I start fitting them to a rack solution. I'll give a little more of a rundown from unpacking boards to ending up with hashing boards and a few more details on the setup I use.

A tip for stability, make sure you disable the fifo on the fpga com ports, go into your com ports under device manager and select advanced, then disable the 16550 uart.

kind regards

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

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?)

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.

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 ...

I'm a little confused.

How can cgminer have a bug with hardware that it doesn't even support?

I do, I simply asked questions to begin with, as a customer I might add, then yohan proceeded to attack and ridicule.
So I withdrew my order and purchased alternate hardware.  Im now here merely to shine a light on the bullshit being peddled.

There are still plenty of people being enticed by the $640 price tag that likely dont know of the hardware faults.
There are plenty of fanbois in here that are only hoping their cheap hardware will work, their faith in Yohan is based completely on the price, not on the delivered promises.

kind regards

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.

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?

Kano, Yohan is just grasping at straws trying to string along potential customers.

His inability to admit his hardware is flawed has lead him to instead try and blame everything else.

He has even gone as far as saying that all hardware is fully tested before shipping, even tho NONE of the hardware works as planned.
They dont even have a bitstream that works, so clearly they cant be sure the hardware is working properly.

The fact that his outbursts have increased under further scrutiny leads me to believe that he knows his hardware has issues.
I hope for CM1 customer's sake this is not the case, but its increasingly apparent that it may be.

I was going to suggest he RTFM, but its doubtful that he would read the manual to help solve a problem that he knows isnt related to CGMiner software.

Heck, how many FPGA/pc system and OS combinations work fine with CGMiner?

How many FPGA hardware vendors try to get their customers to cut up their USB cables on a whim?

Its a pity he has resorted FUD instead of admitting the issues are in the underlying hardware.

Then he jacks up the price based on another untruth about Elden's tricone bitstream working.

kind regards