Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 294. (Read 837101 times)

QoS might help, but I think most routers don't give you enough options to differentiate between different types of traffic. HTTP file transfers and HTTP mining should not be handled the same.

What I do with Shorewall is limit my outgoing rate to a little below the limit I have with my ISP. This puts the bottleneck on my side, so that I control what goes first if things queue up. Then I give high pri to small ACK packets, SSH connections, etc. I give low pri to file transfers. And a middle pri to everything else. The high pri stuff gets guaranteed a part of the available bandwidth. I've been using it for many years now, makes a world of difference for me.

I use QoS on my router, but AT&T sucks so bad that it doesn't really help much (it also doesn't help that I'm almost 3 miles from my DSL center). I might have to look into Shorewall, but I doubt it'll help.

I do have to deal with it. Where do you think all that traffic is going.


Yep. When everything is implemented it may be possible to run a cluster of ASICs on a 14.4 kilobaud modem.

But also, if you are running a lot of other stuff on your connection, I would look into prioritizing traffic. For instance if you are running on Linux or sending your traffic through a Linux machine, have a look at this doc for the Shorewall firewall: http://shorewall.net/traffic_shaping.htm

Basically you want to avoid clogging up your outgoing pipe with high bandwidth traffic as that will give you really high latency. This can increase reject rate of proofs of work. It will also kill download speeds as it takes much longer to send ACKs to the computers you download from. You want to prioritize small ACK packets, interactive stuff like SSH, plus of course mining.

If you ever wondered why your downloads get painfully slow the moment you start to upload something, this is why. Same thing with playing games or typing on an SSH connection while uploading. Linux traffic shaping is what you need. I'm DrHaribo and I approve of this message.

You only say that because you don't have to deal with it.

My connection is constantly freezing because of overload and every little bit of bandwidth reduction helps.

That would not be a problem. A problem might be running a minirig on an old modem or non-3G cellphone connection.

The important thing is to reduce the rate of requests in time for ASICs. That's when this will really matter. It will get done on this pool.

Try using it on a 512Kbps upload DSL connection with a 150GB per month data cap.

Kano, you may have wonderful coding skills, but your public relations skills leave much to be desired. See the post above mine for a very nice example on how to disagree with someone gracefully, and perhaps even possibly change someones mind.

That's good, should be useful stats.

As for mini rig owners needing to avoid this pool. We have several of them and they use both BitMinter client and cgminer. Mining away happily.

What I'm working on right now is putting abusive miners with extremely low efficiency (proof of work to getwork ratio) on a slow response queue so they don't slow down the entire pool. Once that is done, rollntime will be enabled for everyone.

This isn't some dumb move to hurt cgminer. I'm temporarily disabling a feature to ensure pool uptime. It only means a little more bandwidth usage for miners. It's affecting the server much more, but even that's not too bad.

You had a bug in cgminer (happens in all software). It brought down my pool. Lukejr found the bug. It was fixed. Some miners upgrade slowly so affected versions of cgminer are still in use. I'm taking measures to ensure that's not a problem. That's all.

I never came to your forum thread to spread FUD about it like you are doing here now. I never told people not to use cgminer, like you are now hinting that miners should avoid this pool. I only asked miners to upgrade to the latest version where the bug is fixed. Sure it wasn't fun the pool crawling to a halt. But I'd rather focus on the positive side of it, now the server software will become better than it was before.

Thank you for the reply Doc.  This issue was occurring with the Singles hooked up to a lightly used server with dual quad-core Xeon CPUs and 8GB RAM.  The problem went away when I moved it to an idle Acer Iconia Tab tablet with a 1GHz dual-core AMD C-50 and 2GB RAM.  Weird.

Kano, its not really a big issue.. I think most of the minirig users on Bitminter are using the bitminter client, and thus have Roll-n-Time.

cgminer wasn't exactly working that great when I first got my minirigs, and I have pretty much avoided it for BFL devices. a few days ago I gave 2.7.4 a lengthy run and am happy to report nothing bad happened.. the bitminter client has been working flawlessly for me for weeks at a time without any intervention.  the only time I have stopped using it is to test cgminer...

But relax man!  Doc is working on it, im sure he will have cgminer roll-n-time working on the bitminter server soon...   we all want it to work as im sure it will help boost the pool hash rate as the die hard cgminer guys with mini rigs show up.

... cgminer already monitors the pools performance and logs it ... and that can be seen from the API 'stats' command.

I guess anyone using your pool with cgminer should look and see the numbers and see how it fares according to your belief that ~700 requests back and forth per minute is trivial ...

I have been adding such information to cgminer stats for that very reason - so people can make informed decisions about their pools ...

I guess they reconnect as the same USB device and are not seen as "new" devices. May not be the best behavior. You could try in settings choosing on startup to start automated devices, and under automated devices put a tickmark on all the FPGAs.

Also a dirty hack would be to set up a scheduled action to start automated devices every 5 minutes. It's not meant to be necessary though.

I should look at always doing the "new device" thing even if the device has been seen before.


That's not going to kill you, but yes, it uses some more bandwidth. I am working on this right now.


Sure, Java 6 runs BitMinter client just fine. Also you could disable java (not javascript) in the browser and instead start the miner from the commandline with Looks like Oracle learned from Microsoft. Wait a long time for the regularly scheduled update even while security holes are being exploited.

Hi DrHaribo!

How is the Bitminter Java client affected by this zero-day bug?

https://bitcointalk.org/index.php?topic=104164.0;topicseen

Can I use an older version of Java to avoid it, without taking a performance hit?

Meh... I would if I could 

Well ...
That says for every 20.67 shares I have sent so far, I have done 1 getwork.
Yes that is VERY good for the pool, but it is also good for me to have to do 1 getwork for every 20.67 shares, instead of 20.67 getworks (or more) for every 20.67 shares

Interestingly, that number almost exactly matches my U: also, so it says that I only do ~1 getwork per minute from the pool for 1.491GH/s

With a MiniRig, mining on a pool without roll-n-time, it needs to do over 350 getworks per minute.
It also needs to send ~350 shares per minute.
i.e. ~700 requests back an forward per minute.

I guess you should now see why with roll-n-time that would be MUCH better for the MiniRig since it would probably only do ~351 requests back and forward per minute ... and why I'd guess that maybe people with MiniRigs may prefer to avoid your pool ...

Edit: of course, higher difficulty shares would reduce that 351 number also
e.g. roll-n-time + 2xdifficulty shares would mean ~176 requests back and forward per minute for a MiniRig ...

Hi Doc,

Would it be possible to add a re-scan interval to the BitMinter client that checks for devices that are sitting idle and to start them if it finds any?

I have a PC that's hashing with 5 BFL Singles.  Two of them occasionally get dropped from the list and then re-added by the re-scan interval, but for some reason, every time I remote into that computer to check why the hash speed is has dropped, it's due to one or two Singles sitting idle.  If I hit the start button next to the ones that aren't hashing, they start up like nothing is wrong.

I have BitMinter set to start a new device every time it connects, so I'm not sure why they don't start up every time they get re-detected.

Thanks,
WP

I am working on a new server version with rollntime for all miners. Not finished yet though.

It's mostly for the server this is important though. I don't think the bandwidth reduction is that great for one miner?

rollntime is implemented but only enabled for bitminter client and diablominer

how is it bad to simply turn rollntime on for cgminer?

it's because of the way my server works
...
well, it's complex making it go that fast, I'm tweaking a lot of stuff
...
no, it's not because of competition from cgminer, it has to do with internals of the server software
...
I will have rollntime for all miners very soon

Keep up the good work Doc. Full steam ahead fellow minters!

Is nrolltime fixed for cgminer? Can you enable it for 2.5.0 and later?