Topic: Linux mining distro for the Raspberry PI - MinePeon - page 108. (Read 685140 times)

Discarded isn't shares, it's work, and when using stratum it's effectively meaningless (so it wouldn't really be of interest in the normal display)
Stale is probably what you mean ... which has "Difficulty Stale" ...

One time is one time too many if you ask me, that is why I implemented the change in 0.2.2 that totally exits the miner while switching config files.


Awww, don't be like that, forgive a grumpy old man.  You just annoyed me a bit when you suggested I go back to a method that I know does not work reliably.  (that and the exit button  )

Neil

Appreciate the feedback!
Humbled to be receiving direct input from somebody so directly involved while I'm definitely new. Sure is a flat org chart around here!

The comments between here and the git commit make more sense. I'm also studying the cgminer README - https://github.com/ckolivas/cgminer/blob/master/README

To summarize, it is best practice to not really use the accepted, rejected and discarded columns and better to focus on the Diff1Shares, Difficulty Accepted and Difficulty Rejected columns?

To convert this over to the code currently used on the minepeon pool stats section, attention should be focused on: " . $pool['Diff1Shares'] . ", " . $pool['DifficultyAccepted'] . ", and " . $pool['DifficultyRejected'] . " ?

This might come across as a silly question .. I was wondering why there isn't a discarded number for diff1shares? Perhaps hardware errors under the specific mining device are related to the discarded number?
I'm positive I'm missing something here, but just attempting to make the stats/calculations as accurate as possible

See my comment on the pull request
(also note that Accepted/Rejected etc should rarely if ever be used, they should use "Difficulty Accepted"/"Difficulty Rejected" etc ...)

Quick question on the percentages in the latest version, which is a great idea!
I've submitted a code adjustment for how the percentages are calculated under the Pool Stats table for the Rejects and Discards blocks/shares. https://github.com/MineForeman/MinePeonWebUI/pull/11

I was going to adjust the percents in the Device Status pool but noticed the terminology differences and wanted to clear things up.
The complete picture of possibilities includes, accepted, rejected, error and discarded? Or are error and discarded similar? Or is error a subset of discarded?

I submitted a commit to change the rejected % so that the rejected # is divided by the total # (accepted + rejected + discarded) instead of the prior calculation that was taking the accepted # and dividing that by the rejected #.

I might be completely misunderstanding the relationships between shares and the percentages so I wanted to post here to get clarification. Hope my commit is helpful and improving!

I tried many, many times to switch pools, using the "Switch to" buttons of the miner.php page of version 0.2.1 of MinePeon and I never had problems.

But regarding the pool switch you implemented, last week I received a alert email at 00:25 AM, alerting me that my miner was not working. The fact was that, after MinePeon killed the cgminer at the ending of donation period, the new cgminer could not access the USB Block Erupters. This happened only one time.

When I recommend a correction or a new feature, I don't think only about me but also about other users that would like the same feature or correction. It's why I write them here @ the thread and not PMing/SPAMming you.

I'm not demanding you to do what I'm writing (after all, I'm not your boss), but only to give you some ideas that I thought being positives for the project. If you would like them, you could implement them in a future release. If you don't like them, you can always disregard them as stupid ideas and move forward.

But as I can see, you don't like this type of comments. No problem for me. I'm STOPPING right now to give you any further comments or asking you anything else or even SPAMming you.

I rest my case and I'm going to move to other programs, even though those 3rd party programs will never be as good as your's.

Best regards and good luck to MinePeon and to yourself.

How do you know this?  I set two pi's up with miners and scripts, one to try switching pools via restart and one to do it via the API every 30 seconds for over a day to find the most reliable method.  What tests did you run?


Can you PLEASE stop asking for new features whenever they occur to you!

I am sorry, and I don't want to appear snarly but if I just start to through things in whenever the fancy takes me this whole this will turn into a buggy, wonky bit of s**t in no time flat!

The way I (and a lot of other developers) work is we slowly chip away at he code, we release one thing, let it sit and test it for a while with the testers, perhaps go back and make improvements, then once we are happy and the code appears good we release another thing (and the development cycle continues).

I will get to the features you want, you just need to let me do it in my own methodical systematic way.

Neil

P.S I am not really grumpy, its just every post you make there is something new!  I also have to hold down my full time job so I can do this for you .

That's a good placement, Neil. Or you could put the button near the "kill the cat" one, as the Settings page is full of space. No need for a sub-page there.

Also, regarding the "Donation Period", I tried to reorder the pools using the "Switch to" buttons of the miner.php page and what they do is to switch the pool, without killing the cgminer program, as you can see in the following image (I did a switch from pool 0 to pool 1 and again a switch from pool 1 to pool 0). The cgminer is still running.

Why don't you fix your donation pool as pool 'n' and at donate time, do a switch command to your pool, doing again a pool switch to user's pool at end donation time, instead of killing the cgminer program, launch a new instance with your pool and then, @ end donation time kill it again and launch again the cgminer with user's pools? Killing cgminer 2 times a day is risky (one time, last week, cgminer refused to detect both USB Gizmos) and info is lost, like running time, best share, Hardware Errors, etc...

I'll re-flash that build (0.2.1) on an alternate SD and test it tomorrow when I head up to the DC. I'll post results when done.
It is very strange that (3) will run at 60GH/s, then plug in the 4th and they all drop to around 30GH/s. I even split the load between (2) of the Satechi UH-12P USB 2.0 Hubs, plugging into each USB port on the Pi. If I had (2) on one hub and (1) on another hub, as soon as I plugged in the 4th they would drop speed. Very puzzling. 

EDIT: And yes I tried various reboots and stop/start the cgminer service.

Yes.

For the rPI's we collocate the best setup is to have a powered usb hub powering the pi and any peripherals, so you only need 1 power port and 1 network cable - with 24/7 power control you can always hard-boot it (although too many of those will trash teh SD card, so we advise clients send a configured spare to be kept with their pi

That is indeed odd, I doubt it is the hub if it was working before.

What makes it really strange is that it is only if you plug 3 or more in!  There were a few changes to cgminer between MinePeon 0.2.1 and 0.2.2, nothing huge though and I did not really think anything of it.

Any chance you could put the binary from 0.2.1 back and see if it fixes itself?

Neil

It has it's own power, and properly rated for it.

also how are you powering your pi are you using the hub?

Hmm, it says on the package "Satechi UH-12P USB 2.0 Hub with Power", I guess I could try another brand. It's just odd that it works fine with (6) Single SCs plugged into it, and plugged into a PC running the same version of cgminer 3.3.1 on Ubuntu Server 13.04. I will play more tomorrow when I go back to the data center.

You can use the usb ports on the pi or even get a non powered usb hub. BFl products have power supplies so they do not draw power from the hub.

"P.S. Every time you set donations to zero a kitten dies. Kitten Killer!"

^^^ that plus the sounds was hilarious.

Has anyone been mining with MinePeon (0.2.2) with more than (3) BFL Single SCs? The trouble that I am having is that if I go more than (3) they all go half speed. (30GH/s vs. 60GH/s) I am using a Satechi powered USB. http://www.amazon.com/gp/product/B0051PGX2I/ref=s9_hps_bw_g147_ir011 The Pi is the newer 512MB version.

Cool, I will have a look at it later.  Two problems with it though, Restart is not 100% reliable (its more like 99.999% reliable, but that means 1 time out of 1,000 cgminer goes off to la la land).  Quit however seems 100% reliable, but the supervisory process will detect a dead miner and restart it anyway!

However, we can use the quit button as a restart button.  To make a quit button is something else altogether, it requires access to systemd and the httpd process does not have that (I have no idea what scenario people are thinking of that they will actually need to stop the miner though).

As to where to put the buttons, I am not sure.  I am against adding buttons for the sake of having them, especially when they serve no practical purpose whatsoever, it just starts to look messy.  I do plan to add a submenu under settings for 'Advanced Settings' where all the fiddly settings go like API port and subnet and such, perhaps we can put them there.

Neil

Just throwing this out there, I don't know if it is possible or how much overhead it would create for you to manage but I think it would be cool if there was a "key" code that if you donate directly you could have issued to you. Like paste it in a field under settings or something. This would be another method to stop the killing of kittens. 

I understand the pool rotation thing is easy, and I know it would be extra work to create the "key" mechanism code. I would just like to give you BTC directly. I'd prefer the comfort level of knowing what my rigs are doing and when. No offence implied, I trust you, it's just sometimes machines/code has a way of breaking. Plus when I am on a pool, I like to stay on it unless it is broken. There are lots of variables that happen jumping around on pools. If I see dips in my graphs at my pool, is it "donate" mining or something wrong with the pool? Stuff like that.

Maybe you could offer different levels of features that are enabled with your assigned key? Email alerts, VPN, Central Monitoring, etc. Like Basic, Standard, Pro, or something like that, some people might not need all services.

It's just something to think about for the future. Love watching this project grow and evolve. 

Perfect. I submitted a pull request for some simple code that adds a restart and quit button to the bottom of the status page. https://github.com/MineForeman/MinePeonWebUI/pull/10
I wasn't sure if you had UI layout preferences. If you want these somewhere else, or want to group some differently, feel free.