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

My first linux installation was Slackware back in the 0.93 days (circa 1991 or '92), so it is good that "expectations are low".

And do, please, let me know if you get cgminer going.

Last time I installed a linux distro was c.2001, so my expectations are low. I am thoroughly looking forward to a lot of progress bar watching, a little cursing, deciphering online unix 'guides' and some man pages. My competence level is 'tenacious hack stabbing in the dark' rather than 'CS major' so it's a good job I've got no work on this week. Cheers for the heads up you've saved me installing a few other distros already.

Well, just a bit of advice. *Don't* try Ubuntu. Go straight to the Wheezy Debian installation.

Although, I don't have cgminer working yet. Seems to be doing OK with MPBM.

I have an old mac mini g4 I was going to use as a host when my board arrives, it's relevant to me

spiccioli, the post I quoted was tremendously helpful, thank you. (IMO, that info should end up on whatever 'tips and tricks' documentation Enterpoint eventually puts together.)

A question however, while following the steps you suggested the USB ports get correctly recognized, enabled and mapped but are not accessible until I do a "sudo chmod a+rw /dev/ttyUSB*".

Do you have a suggestion so that, from a USB unplug/plug, the ports are usable without that manual step?

FYI, I'm running the Debian 7 beta release as the OS. (Seems the Debian 6 stable wasn't quite good enough. Needed a newer revision kernel to get the USB stuff to behave.) And, shouldn't be relevant, but 'just for kicks' I'm doing it on a PowerPC G4 bit of hardware.

I have a theory. Tossing it out for a sanity check and to see if other's observations might track.

I've now had continuous operation for 20 hrs. (Yes, I know, too short to be definitive.)

Base Conditions:
1) running makomk's 'e' version 210mhz (overclock)
2) one board generates about 0.2% invalids
3) second board generates about 2.25% invalids

New test setup:
1) put boards into 'daisy-chain' configuration
2) connected single USB cable to the board with 0.2% invalids

Results:
No drops so far. Will report back after longer duration of success. (Or, upon next failure.)

The Theory:
Even though I expected the controller to be independent of the 'worker/hashing' FPGAs, perhaps there is some sort of 'feedback' scenario where a glitching 'worker' FPGA can stimulate a failure in the controller/USB circuitry.


Looking forward to y'all's thoughts and observations.

Yep, there is a problem with the CM1 USB hardware or firmware.

After 17 hrs of uptime, both my CM1 boards dropped offline. Required unplugging the USB cables and a power cycle of the boards to get them mining again.

[63025.014801] hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...

This is a powered hub. Only CM1 devices are plugged into it. This hub has operated for years with no problems with a variety of other devices. No other USB activities were being done at the time - seeing as how I was asleep.

-- edit --
And they just now dropped again after about 5 hrs of uptime.

[85301.798738] hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...

Nice it's working for you now and thanks for the coins 

eb

I didn't have time to change #0017 from dcmwd4e-190/180 to glasswalker-175, which will be my next step.
After that, I'll flash dcmwd4e-200 or above to #0620-1 & #0621, and a slower one to #0620-0 because of low U/m.

I hope cm2 use ethernet to comunicate instead of this "problematic" usb.

things i did to reduce almost to zero  usb probs.

1. new usb cables and usb hubs.

2. very important!!!.  control your temperatures. lots of my usb disconnections were temp issues. adding some extra fans and reducing the bitstream frecuency can solve your problems if you live in a hot place.  

3. important!.  disconnect as much other usb devices as you can.  one usb IR receiver for a remote was causing me even BSOD and usb disconnections. Now
 my rig was running for days without probs.

4. use "chain mode"  if you can . I can't say it had helped me but  I guess that less usb cables cannot be a bad thing.


Regards.

PS: yohan, will be temp control released in next controller version?


 

If I get the board from ... someone

Speaking of USB problems, think I just saw my first one. cm1 fell off the USB bus and had to be physically unplugged and reconnected. Even then it only came back up at USB 1.1 speeds.

We have seen USB ports be lost when something else is plugged in like a memory stick. We also think that sometimes a surge of current taken from the USB also causes a disconnect and a power USB hub seems to help here. It might be the plugging in of something else is actually a power problem. We have seen some machines (particularly laptops) prone to this and it sort of suggests maybe a dip on a shared internal power rail in the laptops might be a cause. Short of analysing every combo out there it's going to be very hard to totally identify this issue and our preference is to reduce the dependency on USB if not remove it totally with our rack controller concept.

If anyone has seen a benefit if cutting 5V on the USB wire as input to their CM1 we would like to know. We have been short on people to look at our test boards properly where we have done effective the same at board level so any data on the effect would be useful to us. We should be back to full staffing strength later this week for the first time in 10 weeks but there is something of a backlog to catch up on so it will still be a bit slow here for a few weeks.

I told ya your brain was tooooo big!

I updated from the other makomk's shortfin_icarus bitstream to the dcmwd4e variant. Now my 2 boards are 48 hours stable at U: 5.8...a solid 1690 MHs at deepbit. Now to expand the system or what for ASIC...thinking another 2 would be a good step (discount price still)

As a man of my word, I have sent you 0.5BTC as a token of my gratitude.

Regards,

Cranky

Sounds good to me.

For those of us with less than 50 boards , it is a minor inconvenience to deal with the multiple direct connections.

Still direct USB to the board, no chaining yet. I'm thinking about it. The "real" protocol changes are still a ways off, so I either switch to the hashvoodoo core now, and worry about that for the next several weeks, and then once that's "done" look at protocol (for likely several more weeks) putting us quite a ways away from chaining them using the up/down port...

Or I put in a "temporary" protocol now, to make people happy, and allow chaining the boards, to reduce USB connectivity. Knowing it will be replaced later.

I've been thinking on this, still unsure which way I'm going to go. For the immediate future, Getting it hashing over 200MHash with dynamic clock is the core focus, then I need to decide what's next.

Glasswalker, will this require one direct USB cable to each board, or can it work with a set of 'daisy-chained' boards using the ribbon cables and master/slave(s) settings.

Just a quick update post. I have successfully fixed dynamic clocking on HashVoodoo

It now allows software control of the hashing clock rate in 2.5Mhz increments. (specifically it allows the software to set the multiplier used on the DCM)

My fork supports this functionality and it's working on my dev board now (though at a fairly low clock speed because it was a test build of the bitstream).

My fork of MPBM on github also adds one new feature (I have a pull request in for it to get merged into TheSeven's official fork). It's an initial Warmup period where it ramps up the speed faster, then it slows down the rate at which it adjusts speed to allow better stabilization.

Kano: If you get the time, there is interest from others to use cgminer to achieve the same thing. I won't have time to update cgminer myself. Let me know if there is anything you need from me to achieve this (protocol specs, or whatever). You can of course use the source code for the cairnsmoreworker module in mpbm as a template.

Right now I'm running a test version that only closed timing to 140Mhz, so it's slow (though even this one reaches 180MHash/s with the dynamic clocking on one chip, 170MHash on another, and 160 on the other two).

During initial rampup it increases speed quickly until it encounters invalids, then backs off. Then switches to normal (slower) change mode. Overall it should stabilize around 2% invalids (depending what you set the thresholds at, they are configurable in MPBM). With the defaults of 100/2 it should result in about 2% invalids after it's had time to stabilize

I'm running smartxplorer now to drive up the timing. Once that's done, I'll do an official release of this bitstream (so a couple days likely). If it reaches a speed faster than 175, I'll likely do a quick zip upload just so people can begin testing it out on their own. Otherwise I'll wait until the SX run is finished and has it's "best" run so I can release that.

Right now, board #0017 produces only invalids, no accepted shares at all.
Also 0620-0 has low U/m.

I think MPBM count 10 diff1 shares for one diff10 share. That's why it takes longer for the stats to stabilise since i use the diff10 server from EMC, but looks really nice after 3 day's.

eb