Topic: [ANN] cudaMiner & ccMiner CUDA based mining applications [Windows/Linux/MacOSX] - page 317. (Read 3426936 times)

On average a DDoS attack can drain 40Gb/s of download
The best way to keep your server safe is to set the router to limit to incoming data to an amount your server can handle

Even then, your router needs to be able to handle huge amounts of data without crippling

I have over 150MB home/business service via FIOS.

I also have servers running at 3 different data centers plus a few Amazon and Azure boxes.

Not sure yet where I plan to run it.  Depends on what I need to do...

Carlo

Well your choices are a nice industrial router with DDoS protection, doesnt always help though because the amount of bandwidth coming in would stop access to the network, although it could save your server from being overloaded.
Their are online DDoS companies like CloudFlare which help but if you know the servers IP then you can still get to it.

How big of a Downstream trunk are we talking? Home network i would guess? So maybe 40Mb/s?

Yes physical servers in my control.


Yes, I've had a lot of problems with that pool also.  Actually a lot of the CN pools have had issues lately with DoS or DDoS.  Could just be a bad stratum implementation also for all I know.

However, if possible I'd like to get some protection in place PRIOR to rolling this out.

Carlo

ddos or bad implementation ?
Most of the time I can't even connect extremepool (too bad, this is where the blocks get validated, while on other pool they all orphaned... fishy whatever is happening)

It would depend on if you have physical access to the server or not. and if you did, how much of a budget? if not, cant the host provider implement DDoS protection on the ports?
And websites arent that easy trust me, most online tools can be worked around if you know the servers ip address

BTW, on a slightly different topic.  A lot of pools (especially CryptoNight) have been getting DDoSed to death lately.

I've never dealt with this for anything other then websites which are easy.  If anyone knows of any protection methods that can be used by stratum servers I'd appreciate it if you could PM me any info.

Thanks,
Carlo

For now windows only.  But all the smarts are on the backend.
I also have a console version of this that I've been using.  The windows version just looks nicer and allows you to edit the JSON config files.

So it shouldn't be overly hard to create a Linux version.

Yes, on my todo list for phase 2, along with maybe power figures.  What I'm planning on doing is allowing the Server to send back the hash rates it is seeing instead of what the miner sees.  After all if you have a miner that shows 10K hash but the server only gets 6K then you get paid on the 6K hashs.  This will help figure in Orphon and all other issues that affect your "true hash".

I had edited my post so to keep you from having to go back and read it. Here is the additional info I added:
The client stores all information locally in JSON files but can be directly edited via the form as you can see.

The clients sends the algo and the hash rate to the server/backend where the most profitable algo is determined.  The server returns the most profitable stratum address and port to the client.

The server will do all the switch among say x11 coins for that particular algo.  Same with X13 or any other algo. The only time the client needs to do any switching is when a change of algo is needed.  For example switching from X11 to JHA to CryptoNight. Smiley

At present all payments would be made to a Bitcoin address.

The backend should also be able to switch between conventional pools and "leasing" services if they are the most profitable.

The client is rather "dumb" in that all the "smarts" are located on the backend.

This can control ccminer, cgminer/sgminer or cpu miners.  So basically any GPU or CPU mining program.

Carlo

Wow, nice! Windows only or Linux too?

Another thing that might be good is if you can grab the output of ccminer/cudaminer, to maybe set up a hashrate grabber.
So a button you press, it runs x amount of runs, probably in becnhmark mode. Gets the average, and stores it in the program

if like me you never know what your hashrates were on set things it would allow anyone to grab the program, test their cards for what they get, then use those to calculate
Not an easy task but possible im sure

Awesome new tools guys, congrats...
NVIDIA mining is getting bigger and better each day.

 

Niiiiice

A Little Tease



The client stores all information locally in JSON files but can be directly edited via the form as you can see.

The clients sends the algo and the hash rate to the server/backend where the most profitable algo is determined.  The server returns the most profitable stratum address and port to the client.

The server will do all the switch among say x11 coins for that particular algo.  Same with X13 or any other algo. The only time the client needs to do any switching is when a change of algo is needed.  For example switching from X11 to JHA to CryptoNight.

At present all payments would be made to a Bitcoin address.

The backend should also be able to switch between conventional pools and "leasing" services if they are the most profitable.

The client is rather "dumb" in that all the "smarts" are located on the backend.

This can control ccminer, cgminer/sgminer or cpu miners.  So basically any GPU or CPU mining program.

Carlo

Also tread carefully here... someone will begin demanding that a new thread be started or some bullshit.

Name changes can really upset some people's apple cart.

That would no longer be 'vacant' now would it.

Maybe it is more accurate to call it c_miner?

You mean vacant position on ctminer?

Excellent news, Sir! We managed to be faster. But I don't think I should publicly state by how much...

Let me know if you want the vacant position as a co-author on ccMiner

Did you have to merge in some of the changes from https://github.com/LucasJones/cpuminer-multi to get the protocol support
for cryptonight (e.g. JSON RPC v2)?

Christian

Another good-news-bad-news post.

The good: It compiles successfully under Windows and actually works.

The BAD: The kernel is so slow that TDR (driver timeout detection and recovery) kicks in and kills it before it can finish, unless you run stupid low amount of work on it. It also absolutely positively makes it impossible (well, almost impossible) to do anything on the computer while the miner is running. If you thought the earlier ccminer releases were making your desktop lag... Well, this is orders of magnitude worse.

The somewhere-between: The TDR problem can be worked around by fscking around the registry and increasing the timeout values so that the OS doesn't get quite so trigger-happy quite so fast, allowing the kernel to run its course.

Overall I'm definitely not liking what I'm seeing. Also quite surprised to see what GPU-Z had to show, it does seem to be running at full GPU load with memory load being much lower than I expected to see. Might of course be a case of the driver considering waiting on memory I/O as GPU load but I'm not entirely convinced considering the Asus card with its default 5400 MHz memory clock is pushing almost same hashrates as the Palit cards on my Linux rig with their 6000 MHz memory clocks. Color me puzzled.

Sounds familiar. It happen to me for AMD miner when i use 290 and i use mid setting for gpu engine it will crash driver display. I can use the same setting with no problem on 270. My solution was to remove gpu engine parameter and it work perfectly. Not sure if this information helps.