Topic: [ANN] MiningRigRentals.com - Web pool manager - Easy Mass Rentals - Algos! - page 26. (Read 71309 times)

Is the site currently offline?
Whats problem?
i cant connect to it from Russia
Ip 178.187.....

Thanks for your reply. That sounds great!

I'm currently implementing support for several popular mining services in Awesome Miner, and for MiningRigRentals I will display the current BTC/MH/Day when the rig is rented.

Sorry about the delayed answers, although we have support over the weekends, we tend to wait until all of us are available during the week to tackle questions.

1. Yes we do have plans to continually evolve the API (development work is ongoing).
2. It will be made compatible with GET

Curiously does anyone know if it's possible to make miners lockup more with bad pools? I've noticed when my rigs are rented out sometimes they lockup a lot more, but when I'm mining with them on pools I know, it seems like they don't lockup at all. Of course this is with the same settings and algos as the renters are using.

Please consider a 'scroll down' feature to view more rigs instead of pages. When you have content and you aren't available on the first page, then people don't always start flipping pages. If you could scroll down and it does a endless scroll till all the rigs are on the screen, that'd be nice. Sorta like what google images does.

I have two questions about the API.

1) Will there be a public API method to get the following per algorithm: Lowest cost/MH, Last rental cost/MH
Getting lowest cost can probably be done today by requesting the complete list, but that's not too efficient.

2) What is the reason for using POST requests instead of GET?

Thanks for a great service!

We appreciate the kind words and support.

The hashrate graph is very much like "WU" it's luck based and averages out over time. It's accepted share rate just displayed as hashrate/graph.  Without API we can't see hardware errors, we do see rejects but the rejects could be the rig or they could be the pool so it's a little trickier.

I agree, I think ratings only go to hurt miners (...or possibly your competitors, I do own and rent rigs myself). There are quite a few rigs that I've seen having a bad day, but otherwise hash perfectly fine. I could see ratings being important if you don't have any sort of quantifiable metrics, but we do with the hashrate graph. Other services don't have that so they have to rely on user feedback.

Something that may be more appropriate is a 'quality' indicator instead. Where if a rig hasn't been putting out the correct amount of hashrate for a certain window of time it will degrade. This could be good/bad/poor or maybe a percent, depending on what you want to do. There are a lot of different ways to work with that. Overall it seems like something that depends on user experience and more on what is actually happening. If there was more customer service happening I could see a rating being more important.

I think the most important thing is that it's not permanent and rather a short lived snippet on the rigs themselves. If you guys can view rejects and hardware errors that would also add into this, especially hardware errors. Hardware errors are almost exclusively reliant on the miners themselves so it would directly reflect their hardware and how well they manage it. Errors reduce your hashrate even if it looks like you're getting a good hashrate and are usually caused by too much overclocking or a bad miner. Either way, it's something the renter should have access to and could weigh in with a overall quality indicator.

If you guys have access to the WUs as well, that would be very important for a renter to see, as it shows what you're actually receiving for work sent to a pool. A miner with more rejects and hardware errors will have a lower WU, so it almost completely includes those (although a bad pool can influence WUs too). All of these I think should be made available to the renter on a certain level as it directly influences their purchase, perhaps if they dig a bit more. Most of these a miner can fix or improve on as well, so it's not completely unfair.


Honestly it really doesn't matter what the competitors do if you offer a superior service, that's why I'm here and not over there. A hashrate graph is definitely a step up.

I'll avoid the quotes to keep the post from growing too large.

- I see what you're saying about geolocation now. I think you have a valid point and idea. We have a few ideas on how to tackle this.

- Ratings has been a sticking point for us for awhile now. We really only added ratings in because we feel the user base has grown accustomed to ratings due to similar services.  A lot of feedback we receive suggests that renters care a lot less about ratings than rig owners. Our only thought for the time being is to default 4-5 star ratings based on 90% to 100%+ performance tracked by our current system. Currently we default to no rating and it doesn't reward a well performing rig. Penalizing rig ratings takes a lot more data (cncr04s does have just about every piece of data passed to our logging system for our admin team's review). We will not use automation to ever negatively impact rig ratings.

- We just put the auto cancel/refund system in place and while we can test in beta format, it's much more telling when it's live. So far it's been working as intended and we do plan to expand on this.  We're putting data tracking in place to see where we can further improve upon issues such as offline rigs.

- Average hashrates are shown on completed rentals. You can find a "view" button on completed rentals and or through the transaction logs. This is a relatively new feature (approx. 1 week) so not everyone has noticed it.  Only rig owners and renters of the rental in question can view the average hashrate.  Time extensions do effect the average hashrate so keep that in mind.

- The threshold of warnings is a good suggestion. We'll add this to our todo list

Thank you for all of the feedback. We appreciate you using our service!

So, for instance Dedicatedpools has two stratums. A euro and a US stratum. When someone sets up a rig, they flag their rig for a location. When I set up pools for renting, I add pools. I would then add a geographic region of the pool or leave it as 'default' or whatever. So if there are two pools, MRR will point a euro miner at a euro pool and a US miner at a US pool, if available.

Priorities have to be taken into account. So if they're both labeled with the same priority the closer pool would take precedence. Coin mining/pool preference > geographic location.


1a. CoinAUS Supool
1b. CoinAEu Supool
2. CoinAUS Poopool
3. CoinAEU Whateverpool

(This wouldn't be automatically done, user would set their own priorities)

This would definitely be helpful for mass renting, where different geographically located miners are lumped together. MRR would direct all the miners for Euro to 1b and all the US miners to 1a. if 1b goes down, all the miners are thrown on 1a, and vice versa. Either way, how close miners are to the stratums determines how smooth mining will be and how many rejects (within reason) a user receives. This would help reduce the 'error' in the graphs caused by miners being directed to pools in different locals.


On a different note I also agree with automatic ratings instead of user ratings. They're very polar. You either have a good experience or a bad experience with rigs, there really is no in between. It's pretty straightforward, miners advertise hash rates, customers buy it, they either get the hashrate or they don't. So you end up with five stars or one stars. Although what causes the reduced hashrate would definitely be questionable and figuring out how exactly it happens and what causes it. Figuring out what exactly went wrong would be problematic. Was it a bad pool? Did the miner go down? Was it one of a few miners? How many errors are the miners spitting out? How many rejects do miners have (I don't know if MRR can actually see this)? Is the pool really far away from the miner (part of what the above idea would help with)? Did the renter not setup pools? Were pools offline?

Earlier tonight I rented a rig as well and it was offline. I was reimbursed immediately for this, but the rig went back up as available immediately after this happened. Rigs really should get flagged as offline and require miners to re-enable them if they're offline.

Also consider adding average hashrate for overall to each rental contract. Right now it shows 5/30/hour, but it doesn't show the average over the whole rental, which would be more useful at the end of the mine for future reference.

It would also be good to add the ability for MRR to send a automated message to rig owners if their hashrate drops below a certain threshold. Like if it's 20% below average or 10Mhs less then average. You could configure it so users can turn it on or off and set thresholds for it.

First suggestion: Region specific pools. I'm not sure I fully understand your suggestion.  Are you saying if a renter selects "Dedicated pool" (example only) and they mass rent rigs, you want the rigs that are in Europe to point to the Dedicated European located stratum?  While this would be technically possible, we would have to build a large database of each pool's stratums IP addresses.  Perhaps you are asking us to reconnect a rig owner's rig to a regionally specific MRR server based on the renter's pool choice? If that's the case it likely wouldn't provide better results as the rig would still be regionally located where the rig owner "should" have specified in the listing. However, we have considered "suggesting" a primary MRR server for rig owners upon rig setup by using geolocation.

Second suggestion: Renter side extensions. This is something we've considered (slightly different concept but with the same result) and have on a future todo list.

Thank you.

There should be a way to set geographic regions for pools. So if you rent out EU rigs and US rigs, you can direct the US rigs to the US pools and the EU rigs to the EU pools. Most big pool websites have multiple pools. This could even be automated by MRR with a simply ping to a location. Further away pools would obviously be in a different geographic region or it could be done through a trace. Either way, it should be done and would help out both renters and owners.

Please add the ability to 'add more time' to existing rig rentals. So once the rental finishes it would re-rent it, only of course if it's still available for the same price, time wanted, and still set as online at the time the rental contract ends.

We have added in automatic rental cancellations. If you rent a rig and it's offline at least 20 minutes of the first 30 minutes of the rental, it will automatically cancel and refund you.
We've also added in "rent now" links to your profile page. Profile pages are found here: https://www.miningrigrentals.com/u/your_account_name_here

Hello,

This occurs when the renter's pool choice(s) are not responsive. Please keep in mind we recommend the following:

Set at least 2 MRR servers in your local config along with a pool of choice

1. Closest MRR server to your location
2. Second closest MRR server to your location.
3. Your pool of choice

With the above configuration you will have redundancy on the MRR servers (if the first one fails the second one will resume) and if both MRR servers do not work then the renter's pool is likely unresponsive and you will begin mining at your 3rd pool selection. Provided your pool is listed locally in your config file, you will end up mining for yourself.  This allows you to communicate with the renter (ask them to set more than one pool and or switch pools) and it allows you to compensate the renter without incurring a loss (should you decide to).

I keep getting this messages in sgminer for the last few hours:


The rig is rented. Tried all five servers, they all ping fine, and telnet to port 3333 works fine, too, but I don't get any work, so rig stays idle.

Is this issue specific to this particular rental, or what? Will I have to refund renter for the idle time?

Thank you for taking the time to address my concerns and double check this with me.

1. I can't speak for all pools/stats implementation, but I'm confident that most store a difficulty along with each individual share in their database.. so the difficulty associated with the username is irrelevant. Stats should be accurate regardless of using multiple workers or a single worker with different speed hashing..
2. Difficulty is determined at the connection level, so this is incorrect
3. If the stratum has ALLOW_EXTERNAL_DIFFICULTY=true, the difficulty will be pulled from the database, otherwise it will start at the configured difficulty in config.py

Again, there may be some pools out there who do vardiff incorrectly, but the stratum implementation you linked would properly handle various speed rigs connecting under the same worker name and properly hand them different difficulties based on their hashing speed.

We also understand that users would like the ability to track their rented rigs individually at their pool, thus we are implementing (in the near future) a method to allow you to template worker names in your profiles... such as merc.{ID} or merc.{COUNTER} etc -- but the current implementation should cause no issues at pools

Where connection is the a pubsub connection from stratum?

Am I then correct in thinking then
1. all stats will be wrong since they are based on worker name?
2. if the difficulty is too high, say you have a 150MH worker and add another 2 MH worker, that the 2MH worker will not be able to submit any shares for it's difficulty to be adjusted down
3. if the 'big rig' disconnects it will get the starting difficulty of the last session saved diff from another rig to start, instead of it's own?

In the stratum implementation you linked the sample config comes with vardiff defaulted to true, which loads this file to control the share difficulties
https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/basic_share_limiter.py

The code you linked in pushes the present sessions difficulty to the connection during the authorize process, that difficulty then changes based on the speed in which the connection submits shares

Can you confirm that this is with workers all having an identical username, for example all "pfennig" as opposed to "pfennig.worker1" "pfennig.worker2".

See for example: https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/service.py#L86


If three workers all have the same worker name, then it is impossible for them not to reference the same value, at this level.

Thank you.