Linux mining distro for the Raspberry PI - MinePeon

[MineForeman.com]

Also, I love the new SSH menu, but it would be nice to have an option to see the IP address of the RPI (for instance via ifconfig).

I often miss the obvious, I will get that done for you.

Neil

[1714808145]

1714808145

[1714808145]

1714808145

[1714808145]

1714808145

[ct1aic]

I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.

Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's.

[MineForeman.com]

I searched through this thread and did not find anything. I'm curious if anyone has used MinePeon with a Gridseed Scrypt ASIC?

I have ordered one, hopefully it will be here this week and I will start supporting it.

Neil

Are you getting a usb or 5 chip one?

I am getting one of each (at lest I hope I am).  It is a bit difficult to find a reliable source for these things but I think I am onto one now.  Perhaps I should open "The Peon Shop" .

Neil

[MineForeman.com]

I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.

Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's.

That is a bit odd, MinePeon has no control over the mac address you router see's.  As such, the fix needs to be in your router not your MinePeon!

I will do a bit of further reading.  Is your router firmware upto date?

Neil

[ct1aic]

I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.

Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's.

That is a bit odd, MinePeon has no control over the mac address you router see's.  As such, the fix needs to be in your router not your MinePeon!

I will do a bit of further reading.  Is your router firmware upto date?

Neil

Ok, then the problem must be with my Linksys router (with DD-WRT) and my Fonera router and Microsoft Windows 2010 Enterprise Server's DHCP service.  

The Same RPI, with the old images and other distro's gives to those DHCP's the same 12 hexa digits, with the new 0.2.4.6 gives a 36 digits hexadecimal number...

[Mudbankkeith]

I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.

Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's.

That is a bit odd, MinePeon has no control over the mac address you router see's.  As such, the fix needs to be in your router not your MinePeon!

I will do a bit of further reading.  Is your router firmware upto date?

Neil

Ok, then the problem must be with my Linksys router (with DD-WRT) and my Fonera router and Microsoft Windows 2010 Enterprise Server's DHCP service.  

The Same RPI, with the old images and other distro's gives to those DHCP's the same 12 hexa digits, with the new 0.2.4.6 gives a 36 digits hexadecimal number...

Is this the difference between IPv4 and IPv6 addressing?

[MineForeman.com]

Is this the difference between IPv4 and IPv6 addressing?

I would not have thought so, MAC addressing is way down the OSI model from the transport layer.

Neil

[ct1aic]

I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.

Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's.

That is a bit odd, MinePeon has no control over the mac address you router see's.  As such, the fix needs to be in your router not your MinePeon!

I will do a bit of further reading.  Is your router firmware upto date?

Neil

Ok, then the problem must be with my Linksys router (with DD-WRT) and my Fonera router and Microsoft Windows 2010 Enterprise Server's DHCP service.  

The Same RPI, with the old images and other distro's gives to those DHCP's the same 12 hexa digits, with the new 0.2.4.6 gives a 36 digits hexadecimal number...

Is this the difference between IPv4 and IPv6 addressing?

The IPv6 address size is 128 bits. The preferred IPv6 address representation is: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx where each x is a hexadecimal digit representing 4 bits. IPv6 addresses range from 0000:0000:0000:0000:0000:0000:0000:0000 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.

32 hexa... I get a 36 hexa digits... but a good question...

[jedimstr]

Odd display issue with 0.2.4.6.

My list of devices on the webUI seems incomplete and variable on refresh.  When SSH'd in I see the proper amount of devices in BFGMiner and when accessing the API for my Miner-Dashboard.

I have 44 Block Erupters and 3 Antminers U1's so a total of 47 devices.
BFGMiner TUI and API both show 47 devices.

Here's from the Minepeon webUI:


And here's BFGMiner via SSH:


Then... a few minutes later I got this in the WebUI:



BFGMiner API and TUI both stay constant at 47 devices and ~ 20GHs

The Device List in Minepeon's WebUI varies on page refresh.  In the two examples it went from 33 to 27 devices and of course resulted in inaccurate hashrates on the bottom.  The charts above though seem accurate for the hashrate.

[MineForeman.com]

Odd display issue with 0.2.4.6.

At the moment if the device does not return a share after 5 minutes MinePeon thinks it's dead.  This may be a problem with old/slow devices running at a high diff.  They are still back there running though.

It might be an idea to let users set this timeout or perhaps even extending it.  I just want things to settle with the new version for a few days.

Neil

[jedimstr]

Odd display issue with 0.2.4.6.

At the moment if the device does not return a share after 5 minutes MinePeon thinks it's dead.  This may be a problem with old/slow devices running at a high diff.  They are still back there running though.

It might be an idea to let users set this timeout or perhaps even extending it.  I just want things to settle with the new version for a few days.

Neil

It's not the 5 minute timeout, because it happens still just a minute or two after startup/reboot.
BFGMiner shows all 47 devices at 1:20 uptime and in parallel refreshing the Minepeon WebUI shows 3, then 20, then 18.   All well within the 5 minute window.

Previous versions 0.2.4 and the defunct 0.2.5 pr2 took maybe a refresh or two to show 47 devices, but once shown, they stayed that way for me.  0.2.4.6 seems almost random.

[ct1aic]

As I can't reserve the IP address of the RPI at my Router, with this new version of MinePeon, how can I configure the ETH0 with a Static IP without reverting to dynamic IP after RPI restart?

I tried ifconfig with versions 0.2.4.5 PR2 and 0.2.4.6 and there is a new in the new version (ifb1:):

[minepeon@minepeon ~]$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.110  netmask 255.255.255.0  broadcast 192.168.1.255
        ether b8:27:eb:48:b4:83  txqueuelen 1000  (Ethernet)
        RX packets 97785  bytes 7112877 (6.7 MiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 113706  bytes 8903494 (8.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 3572  bytes 2089331 (1.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3572  bytes 2089331 (1.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[minepeon@minepeon ~]$

[minepeon@minepeon ~]$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.213  netmask 255.255.255.0  broadcast 192.168.1.255
        ether b8:27:eb:a3:0a:09  txqueuelen 1000  (Ethernet)
        RX packets 5303  bytes 5042137 (4.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4247  bytes 1295969 (1.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ifb1: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        ether 2a:cb:56:94:21:f6  txqueuelen 32  (Ethernet)
        RX packets 4  bytes 1568 (1.5 KiB)
        RX errors 0  dropped 4  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 438  bytes 275667 (269.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 438  bytes 275667 (269.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[minepeon@minepeon ~]$

[raystream]

for static IP setting have a loke ove here
http://www.minepeon.com/forums/viewtopic.php?f=19&t=1297

[ct1aic]

for static IP setting have a loke ove here
http://www.minepeon.com/forums/viewtopic.php?f=19&t=1297

Thanks.

New problems with 0.2.4.6 version:

The defaults for miner startup settings (both BFGMiner and CGMiner) don't include the date/time code that is included in previous version and also in this new version, before selecting the defaults buttons.

I have a strange reaction with one of the RPI's: I have 2 Mitsai 7 port HUB's with several USB Block Erupters and Blue Fury and also, connected to each of those HUB's 2 D-Link 7 port HUB's with a mix of USB Block Erupters and overclocked Block Erupters, with a total of 6 HUB's and 24 Block Erupters & 3 Blue Fury. All HUB's have 5 to 8 amp. 5 volts PU's. With the old version of MinePeon & BFGMiner 3.10.0, all miners are mining with no problems. But with the new version of MinePeon & BFGMiner 3.10.0, only the miners connected to the 2 Mitsai directly connected to the RPI are working with no problems. Regarding the other miners, connected to the D-Link HUB's, start working and after several seconds, light the green LED's for more or less, restart mining for some more seconds and keep repeating this behavior.

UPDATE: this strange behavior is only detected with the overclocked Block Erupters and not with the others, in same HUB's. With this new image, I can't get more than 335 MH from each overclocked Block Erupter, instead of the 440 MH I got with previous version of MinePeon (with same version of BFGminer). Perhaps something with the compilation of the BFGminer?
 
The RPI with 36 Block Erupters connected via a 49 Port USB 2.0 HUB are working fine and also the RPI with the 7 Jalapeños connected via 2 Mitsai HUB's, with this new MinePeon version.

To Neil, Mariogrip and to the other guys that are working for one of the best programs I ever used, my thanks for your wonderful work.

[mikerbiker6]

ct1aic,
Did you add those miners over time?
Otherwise what is the point of buying so many usb miners, for that money you can better buy one big machine IMO.

[ct1aic]

ct1aic,
Did you add those miners over time?
Otherwise what is the point of buying so many usb miners, for that money you can better buy one big machine IMO.

Hi, mikerbiker6.

I bought the majority in pre-order, when there was almost no other miners for selling. At that time, we only had the ATI/AMD top graphic cards, with higher price and using 100 times the energy of one or 2 USB Block Erupters, to get the same hashing rate.

Now, I don't have courage to stop mining with them.

[Mudbankkeith]

ct1aic,
Did you add those miners over time?
Otherwise what is the point of buying so many usb miners, for that money you can better buy one big machine IMO.

Hi, mikerbiker6.

I bought the majority in pre-order, when there was almost no other miners for selling. At that time, we only had the ATI/AMD top graphic cards, with higher price and using 100 times the energy of one or 2 USB Block Erupters, to get the same hashing rate.

Now, I don't have courage to stop mining with them.

erupters still have about a months worth of useful hashing ( currently returning about 2.5/1 over electricity (UK) cost )

[tripppn]

Has anyone ever tried CPU mining with a RPi or BBB?

[tripppn]

Has anyone ever tried CPU mining with a RPi or BBB?

Neil,
I was just thinking...  I don't know if it's even possible but you could use the extra CPU power to mine CPU mine able coins for your donation.  I know 1 wouldn't do much of anything but how many dls do you get a week?  a couple thousand?  Imagine 2 thousand of these mining CPUcoin for you.  That could really add up.

Just a thought...

[necro_nemesis]

ct1aic,
Did you add those miners over time?
Otherwise what is the point of buying so many usb miners, for that money you can better buy one big machine IMO.

Today I have to use antminer S1's 1:1 in place of USB block erupters. I'm just waiting for the 49 antminer s1 hub to come out.