[GUIDE] GridSeed GC3355 5 Chip Setup/power/windows/linux/rpi by UnicornHasher

[BotwinBG]

Can you guys please keep the hashra and the rest of the stuff away from this thread?

Any word of bfg or cgminer supporting dual mining yet?

[1714790465]

1714790465

[1714790465]

1714790465

[1714790465]

1714790465

[1714790465]

1714790465

[bobby35ny]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

[wolfey2014]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

5 words come to mind..

comm port fifo buffer overload..... they fill up with bits of data that go no where and end up just disappearing into thin air, so the instructions 'port calls' go missing and the system ends up losing it's way, so to speak and quits. It's like losing the instructions on how to do something.

it takes time for them to become overwhelmed to the degree that enough data is lost and the system just spits dummy i.e. loses communication with some, most or all peripherals all together.

I believe that comm ports including USB were not designed for intensive full time two way traffic, so they eventually 'overflow' their buffers bit by bit 'litterally' and eventually clog up and stop functioning,,,to put it in layman's terminology.

Not even high speed ports can handle the traffic for very long before they spit dummy.

I need to learn more about USB technology to figure out what can be done about it.
I think there are high end USB cards for PC's that can handle such traffic as they are made for enterprise type operations like USB hard drive storage racks etc. Anyway, I'm just guessing here mostly.

Aren't there any USB serial communications experts out here?

Perhaps a new thread should be dedicated to this subject so we can all figure it out together.
It needs to be addressed and handled!

That's my 0.000002014 btc
Wolfey2014

Here, I just found this explanation. Makes sense and backs up what I'm saying in slightly different terms..



"The original UART chip used in IBM-PC designs was the 8250. It could store just one received byte while the receiver was busy receiving the next byte. That puts a high demand on the responsiveness of the operating system's serial port driver, responding to the "data received" interrupt. It must be quick enough to read that byte before the receiver overwrites it. Not being quick enough causes an overrun error and irretrievable data loss. High interrupt rates are also detrimental.

That design was improved upon by the 16550 UART chip. It got a larger buffer, the FIFO, giving the OS more time to empty the buffer before an overrun could occur. The serial port driver can program it to generate an interrupt at a particular fill level, thus reducing the interrupt rate as well.

But chips designs have the same kind of problem that software has, the original 16550 had a bug in the FIFO implementation. Fixed in the 16550A.

Problem was, the driver could not tell whether the machine had the buggy version of the 16550. So it provided a property page that lets the user turn the FIFO support off and bypass the bug.

The odds that today you'll have the buggy version are zero. Turning the FIFO off is no longer necessary."

Source: http://stackoverflow.com/questions/21164092/role-of-fifo-buffer-for-com-port-in-windows

[CartmanSPC]

Nice try on guessing the problem being USB wolfey2014 but on a Thinkpad with Ubuntu server I have run 20 miners uninterrupted for over 3 days strait.

BTW, the shipping fee (at least to me) from hashra is $150 for 20. Comes out to $157.50 each. Think that is the best price so far until the other guys meet or beat it

[bobby35ny]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

5 words come to mind..

comm port fifo buffer overload..... they fill up with bits of data that go no where and end up just disappearing into thin air, so the instructions 'port calls' go missing and the system ends up losing it's way, so to speak and quits. It's like losing the instructions on how to do something.

it takes time for them to become overwhelmed to the degree that enough data is lost and the system just spits dummy i.e. loses communication with some, most or all peripherals all together.

I believe that comm ports including USB were not designed for intensive full time two way traffic, so they eventually 'overflow' their buffers bit by bit 'litterally' and eventually clog up and stop functioning,,,to put it in layman's terminology.

Not even high speed ports can handle the traffic for very long before they spit dummy.

I need to learn more about USB technology to figure out what can be done about it.
I think there are high end USB cards for PC's that can handle such traffic as they are made for enterprise type operations like USB hard drive storage racks etc. Anyway, I'm just guessing here mostly.

Aren't there any USB serial communications experts out here?

Perhaps a new thread should be dedicated to this subject so we can all figure it out together.
It needs to be addressed and handled!

That's my 0.000002014 btc
Wolfey2014

Here, I just found this explanation. Makes sense and backs up what I'm saying in slightly different terms..



"The original UART chip used in IBM-PC designs was the 8250. It could store just one received byte while the receiver was busy receiving the next byte. That puts a high demand on the responsiveness of the operating system's serial port driver, responding to the "data received" interrupt. It must be quick enough to read that byte before the receiver overwrites it. Not being quick enough causes an overrun error and irretrievable data loss. High interrupt rates are also detrimental.

That design was improved upon by the 16550 UART chip. It got a larger buffer, the FIFO, giving the OS more time to empty the buffer before an overrun could occur. The serial port driver can program it to generate an interrupt at a particular fill level, thus reducing the interrupt rate as well.

But chips designs have the same kind of problem that software has, the original 16550 had a bug in the FIFO implementation. Fixed in the 16550A.

Problem was, the driver could not tell whether the machine had the buggy version of the 16550. So it provided a property page that lets the user turn the FIFO support off and bypass the bug.

The odds that today you'll have the buggy version are zero. Turning the FIFO off is no longer necessary."

Source: http://stackoverflow.com/questions/21164092/role-of-fifo-buffer-for-com-port-in-windows

I was told to try the HASHRA image based on bfgminer. I'm testing it now.
I see issues already, You cant get into the Pi and set ip addresses. But I still want to see if its stable.
-Bobby

[edonkey]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

When you say it crashes, are you talking about the cgminer itself, or your Raspberry Pi?

If it's the Raspberry Pi, you should probably check that you've got the "slub_debug=FP" hack in place. This has been discussed in other places, but to save you searching time, here's what you need to do (if it's not already in place):

sudo nano /boot/cmdline.txt

Add the following code at the end of the first line (on the same line as the other text, DO NOT add new line!)

Code:

slub_debug=FP

Save the file then reboot your Raspberry Pi.

What the above does is basically enable some kernel debug mode on the Raspberry Pi. I have no idea why debug mode prevents the system kernel crash, but there's a lot of anecdotal evidence that it does work. In my case, I couldn't run for more than an hour before my Pi would crash.

I suspect that there's a kernel bug that cgminer is somehow triggering. I don't know if anyone has seriously investigated this, given that most people just want a work around so that they can keep mining reliably. But if you're interested, here's a related thread that I found:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=55370

If the issue is that cgminer is crashing, not your Pi, doesn't it get restarted by the Scripta /etc/rc.local?

I've seen cgminer crash too. I got about 48 hours the last time before it crapped out. I'm using the dtbartle version that I built myself from the git sources, and I've got 10 GridSeed units.

This morning I decided to run cgminer in text only mode under daemontools. I've been running my Dual Miner version of cgminer like that for weeks on another rig and have never seen a crash of either the Pi or cgminer (and I don't have the slub_debug hack enabled on that Raspberry Pi, either). There's a lot to like about daemontools, including logging. And I see no need to have a terminal output in a detached screen process when Scripta does a nicer job of giving me visual miner status.

I have no idea if running cgminer in its default terminal mode under screen is in fact problematic or not. The stability problems might just be in the gc3355 implementation of cgminer. But I like how my other rig is running and it's nice to keep things consistent.

Anyway HTH...

[jjj0923]

I'm ready to order another 10 gridseeds and I'm ready to buy today - want to buy from someone in the U.S. - who has got the best price?

thanks

[bobby35ny]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

When you say it crashes, are you talking about the cgminer itself, or your Raspberry Pi?

If it's the Raspberry Pi, you should probably check that you've got the "slub_debug=FP" hack in place. This has been discussed in other places, but to save you searching time, here's what you need to do (if it's not already in place):

sudo nano /boot/cmdline.txt

Add the following code at the end of the first line (on the same line as the other text, DO NOT add new line!)

Code:

slub_debug=FP

Save the file then reboot your Raspberry Pi.

What the above does is basically enable some kernel debug mode on the Raspberry Pi. I have no idea why debug mode prevents the system kernel crash, but there's a lot of anecdotal evidence that it does work. In my case, I couldn't run for more than an hour before my Pi would crash.

I suspect that there's a kernel bug that cgminer is somehow triggering. I don't know if anyone has seriously investigated this, given that most people just want a work around so that they can keep mining reliably. But if you're interested, here's a related thread that I found:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=55370

If the issue is that cgminer is crashing, not your Pi, doesn't it get restarted by the Scripta /etc/rc.local?

I've seen cgminer crash too. I got about 48 hours the last time before it crapped out. I'm using the dtbartle version that I built myself from the git sources, and I've got 10 GridSeed units.

This morning I decided to run cgminer in text only mode under daemontools. I've been running my Dual Miner version of cgminer like that for weeks on another rig and have never seen a crash of either the Pi or cgminer (and I don't have the slub_debug hack enabled on that Raspberry Pi, either). There's a lot to like about daemontools, including logging. And I see no need to have a terminal output in a detached screen process when Scripta does a nicer job of giving me visual miner status.

I have no idea if running cgminer in its default terminal mode under screen is in fact problematic or not. The stability problems might just be in the gc3355 implementation of cgminer. But I like how my other rig is running and it's nice to keep things consistent.

Anyway HTH...

I already did the slub, otherwise it will crash in 10min...
Testing the hashra with bfgminer now.
Its the Pi for sure, it loses Ethernet and dies after 10 hrs or so when using 20 seeds.
Someone said they have been running 20 seeds on the Hashra for a few days now without issue, if thats true, it might be a cgminer issue.

-bobby

[jjj0923]

I'm running 20 gridseeds - no mods - 850 MHZ, rasberry pi and running cpuminer

I have a 24 port hub and the only time I've had a problem is when I tired to compile cgminer for myself - I'm running the compiled one listed here in this thread right now.

I was happy with cpuminer but there's no api and I want to monitor them and my rig from one program

[miaviator]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

Cgminer seems to use way to many threads/resources for the PI.  CPUminer will run 20-40 on a pi easy.  I've migrated to linux boxes with extra USB host controllers and stuck the Pi's in a drawer.

[miaviator]

Nice try on guessing the problem being USB wolfey2014 but on a Thinkpad with Ubuntu server I have run 20 miners uninterrupted for over 3 days strait.

BTW, the shipping fee (at least to me) from hashra is $150 for 20. Comes out to $157.50 each. Think that is the best price so far until the other guys meet or beat it

You realize there are two or three sellers who state they will meet or beat any valid quote?

[miaviator]

And thanks for this: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=55370 posted above.

Now it makes more sense

[jjj0923]

With 10 seeds the raspi runs for days without issues, However when running 20 seeds it will crash around 12 hours.
Anyone have the fix or advice for this?
Running whezzy/scripta/cgminer.

Cgminer seems to use way to many threads/resources for the PI.  CPUminer will run 20-40 on a pi easy.  I've migrated to linux boxes with extra USB host controllers and stuck the Pi's in a drawer.

just don't stick the pi's in an oven - LOL 

[usao]

I'm ready to order another 10 gridseeds and I'm ready to buy today - want to buy from someone in the U.S. - who has got the best price?

thanks

I think GAW miners offer $185 including shipping.

[mastah_ob1]

HI! i have a Gridseed Wiibox controller ( looks like this http://www.scrypt-hash.com/wp-content/uploads/2014/03/wiibox-150x150.png )
And i am supposed to power it with micro USB? Like a phone charger/ microusb-usb and plug it to my usb hub?
Thing is there's a green light and it's on for like 3seconds then it goes black every time i plug in the wiibox controller. Is it broken?
Do i need to plug in internet + miner for the light to be green all the time? Should it not light? I don't find it on my router when having it powered + internet connected.

TYVM!

BTW sorry but
Part 4: Setting up the controller
Sucks...

[usao]

HI! i have a Gridseed Wiibox controller ( looks like this http://www.scrypt-hash.com/wp-content/uploads/2014/03/wiibox-150x150.png )
And i am supposed to power it with micro USB? Like a phone charger/ microusb-usb and plug it to my usb hub?
Thing is there's a green light and it's on for like 3seconds then it goes black every time i plug in the wiibox controller. Is it broken?
Do i need to plug in internet + miner for the light to be green all the time? Should it not light? I don't find it on my router when having it powered + internet connected.

TYVM!

BTW sorry but
Part 4: Setting up the controller
Sucks...

Im interested in how these things are suposto be connected as well.
Got several in my order, but not sure what the wiring is suposto be.

[miaviator]

HI! i have a Gridseed Wiibox controller ( looks like this http://www.scrypt-hash.com/wp-content/uploads/2014/03/wiibox-150x150.png )
And i am supposed to power it with micro USB? Like a phone charger/ microusb-usb and plug it to my usb hub?
Thing is there's a green light and it's on for like 3seconds then it goes black every time i plug in the wiibox controller. Is it broken?
Do i need to plug in internet + miner for the light to be green all the time? Should it not light? I don't find it on my router when having it powered + internet connected.

TYVM!

BTW sorry but
Part 4: Setting up the controller
Sucks...

Im interested in how these things are suposto be connected as well.
Got several in my order, but not sure what the wiring is suposto be.

Micro USB power

USB to hub

Ethernet to ethernet.

https://bitcointalk.org/index.php?topic=482352.msg5529845#msg5529845

[mastah_ob1]

HI! i have a Gridseed Wiibox controller ( looks like this http://www.scrypt-hash.com/wp-content/uploads/2014/03/wiibox-150x150.png )
And i am supposed to power it with micro USB? Like a phone charger/ microusb-usb and plug it to my usb hub?
Thing is there's a green light and it's on for like 3seconds then it goes black every time i plug in the wiibox controller. Is it broken?
Do i need to plug in internet + miner for the light to be green all the time? Should it not light? I don't find it on my router when having it powered + internet connected.

TYVM!

BTW sorry but
Part 4: Setting up the controller
Sucks...

Im interested in how these things are suposto be connected as well.
Got several in my order, but not sure what the wiring is suposto be.

i found some neat pictures, https://www.dropbox.com/s/yes569a9y8d6ybi/HASHRA%20SET%20UP%20GUIDE%20FOR%20WIIBOX.pdf (page 4)
but mine's broken...:/ can't find it on router and green light isn't on for more than 2sec

[bobby35ny]

And thanks for this: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=55370 posted above.

Now it makes more sense

Have you tried differents HUBS? Think it matters?

-bobby

[miaviator]

HI! i have a Gridseed Wiibox controller ( looks like this http://www.scrypt-hash.com/wp-content/uploads/2014/03/wiibox-150x150.png )
And i am supposed to power it with micro USB? Like a phone charger/ microusb-usb and plug it to my usb hub?
Thing is there's a green light and it's on for like 3seconds then it goes black every time i plug in the wiibox controller. Is it broken?
Do i need to plug in internet + miner for the light to be green all the time? Should it not light? I don't find it on my router when having it powered + internet connected.

TYVM!

BTW sorry but
Part 4: Setting up the controller
Sucks...

It's a community guide at this point.   So sorry but Your fault

Give me whatever should go in there and I'll change the OP