Bitcoin Forum
September 22, 2018, 12:19:31 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
Author Topic: [ANN] Bminer: a fast Equihash/Ethash/Tensority miner for CUDA GPUs (10.3.0)  (Read 52714 times)
MiningTaken
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
February 01, 2018, 03:54:56 PM
 #621

[/quote]
I don"t know what is the issue with BMiner, but we are many people to see what you wrote (on same pool and same hardware) :
 1 - the miner hashrate is bigger with BMiner than DSTM, but the number of share is bigger with DSTM than BMiner : in my case, DSTM is more profitable than BMiner
 2 - dstm has lowest rejected shares than bminer.
[/quote]


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!
1537618771
Hero Member
*
Offline Offline

Posts: 1537618771

View Profile Personal Message (Offline)

Ignore
1537618771
Reply with quote  #2

1537618771
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537618771
Hero Member
*
Offline Offline

Posts: 1537618771

View Profile Personal Message (Offline)

Ignore
1537618771
Reply with quote  #2

1537618771
Report to moderator
threeflappp
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
February 01, 2018, 03:57:43 PM
 #622


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!


In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?
MiningTaken
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
February 01, 2018, 04:07:41 PM
 #623


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!


In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?


In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)
threeflappp
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
February 01, 2018, 05:56:11 PM
 #624


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!


In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?


In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)


I think you and the other guy is misunderstanding me. I don't mind devfee at all. I'm using DSTM where you can't turn off devfee.

I'm asking people to try out the no devfee option to see if they see any change in hashrate/share/payout.
chuckn3v3rsold
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
February 01, 2018, 07:14:23 PM
 #625

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!
realbminer
Member
**
Offline Offline

Activity: 240
Merit: 16


View Profile WWW
February 01, 2018, 10:03:27 PM
 #626


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!


In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?


In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)


It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

When Crypto-mining Made Fast. @realbminer on TWTR
realbminer
Member
**
Offline Offline

Activity: 240
Merit: 16


View Profile WWW
February 01, 2018, 10:05:39 PM
 #627

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!


This is expected -- The Linux version does not have this issue.

The reason is that I have to insert some delays to work around the bugs in the NVIDIA drivers under Windows. Without the delay the drivers will just hang.  Sad

However, I think there might be some opportunities to make it work better. Will look into it.

When Crypto-mining Made Fast. @realbminer on TWTR
gettilee
Newbie
*
Offline Offline

Activity: 51
Merit: 0


View Profile
February 01, 2018, 11:04:01 PM
 #628

It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

thanks for the explanation and i think it would be great if you took the time to write out how it all works and put it in your first post so everyone understands it when they download it.

i would love to switch over to bminer full time and ditch dstm, but i have a few concerns first:

1) accepted/invalid share/rejected share clarification would be great. confirmation if sending invalid shares penalizes, thats a big deal. test on flypool since its the largest?

2) if the total reported hashrate from bminer includes the dev fee, perhaps adding an addition line of just the dev fee hashrate so we aren't seeing as big of dependencies between miner and pool hashrate.

3) you still haven't detailed why Bminer contacting 104.31.68.221:443/104.31.69.221:443 regularly. runtime and licensing information is too vague to mean anything to us.
chuckn3v3rsold
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
February 01, 2018, 11:36:21 PM
 #629

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!


This is expected -- The Linux version does not have this issue.

The reason is that I have to insert some delays to work around the bugs in the NVIDIA drivers under Windows. Without the delay the drivers will just hang.  Sad

However, I think there might be some opportunities to make it work better. Will look into it.

Thanks for your answer and explanation.
zerimis
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
February 01, 2018, 11:41:38 PM
 #630

Have just started trying out bminer and have found it definitely squeezes out some additional hashrate.

One request would be to honor CUDA_VISIBLE_DEVICES, or to allow "-devices" to take the GPU's UUID.

I use some scripts to manage the miner processes and have mappings to what miners should be running on which GPUs. One annoyances with the index based settings of "0,1,2" is that the ID used does not match the ID from nvidia-smi. I found this the hard way and it isn't well documented. I could find a simple way to find out what the order was, but did find that CUDA_VISIBLE_DEVICES supports a comma-separated list of the GPU's UUID, so that was my solution.

With bminer, I had the env var set to the UUIDs, but it was trying to use all GPUs. When I used -devices, it was the same thing of IDs not matching the ordering in nvidia-smi or the order the NVML API returns them in.

Thanks!
MiningTaken
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
February 02, 2018, 12:28:47 AM
 #631


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!


In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?


In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)


It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!


Thank you very much for your answer, RealBminer. :-)
I think all of us would really appreciate your hard work and your honest & straightforward answers.

If you don't mind, please do spend some time to write out how the whole thing works.
And also, there are some requests on more detailed information reported via the API (127.0.0.1:1880), like Net Hashrate, Miner's Uptime, etc.
It would be great if you would do that!
Thank you again.
CryptoWatcher420
Sr. Member
****
Offline Offline

Activity: 462
Merit: 258

Small Time Miner, Rig Builder, Crypto Trader


View Profile
February 02, 2018, 12:48:26 AM
 #632


1. Pardon me my friends; I don't mean to make any conclusion right now. In my case : I still cannot conclusively say which one is more profitable.
Right now, I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

2. In my case : rejected shares is merely the same between both. Once again : I just want to (sincerely and without any prejudice) query for explanation from the developer (RealBminer). :-)

Thank you all. Happy mining!


In the end, all that matters is accepted shares. Which is why a few people, me included, is a little skeptical of this miner hashrate.

Can you try to mine with devfee off and see if your hashrate or accepted shares or payout changes?


In my newbie opinion; there is nothing wrong for people to receive rewards for his/her good effort. :-)
I don't mind paying some fee for the developer (it's one's intellectual property right), as long as :
1. The fee is fair and honest. and,
2. The result / benefit is greater then the cost / fee.
Thanks anyway for your suggestion. :-)

@RealBminer : Back to my question; I just want to know your explanation about Hashrate and Accepted shares on Bminer. Thank you. :-)


It is difficult to explain in short statements, but I'll try.

1. Bminer reports total hashrates for your GPUs. It includes all shares (accepted, rejected and the devfee). As a result, turning on / off devfee does not affect the numbers the disabled optimization on various places does affect the payout, which you might see less hashrate on the pool side.
2. The pool estimate the hashrate based on the number of accepted shares and the *difficulties* of the shares. Essentially hashrate = the number of accepted shares * difficulty. Pools control the number of RPCs sent to the pools by varying the difficulties. Therefore, it is quite normal to see that all miners report roughly the same number of the shares to the pool, but due to the differences in difficulties the payout could be very different.
3. Bminer right now does submit some invalid shares. My understanding is that there are benign and will not affect the payout. I got good results on nanopool / miningpoolhub, but at the same time I suspect that there are times that the pools are penalizing it. I'm looking into it in more details.
4. There is no points for miners developers (at least that's my view) to cheat / scam or whatsoever, as it is relatively straightforward to verify the payouts and to migrate between different miners. Cheating will not go far. My mission is to develop the most efficient miner available to help the users to get more hashrates from their GPUs.

Since the questions have come up from time to time I might spend some time to write out how the whole thing works. Stay tuned!

I can call bullshit on that number 4 comment you aren't here for us, if you were how bout you lower your dev to to say 1 percent or maybe .5 percent, youll get more people to use your program to make up for the difference, your not here to really help us as much as you are helping yourself, you devs do nothing but cheat us miners and spit bullshit. yall don't update stuff hardly even enough to merit what we PAY YOU each month PER rig, you are no different than claymore, yall are only here to benefit yourself, numbers speak for themselves man. cheating does go far and you and every other dev is proof of that

6pin to EPS 12v 4+4pin w/pigtail & 2.5mm barrel plug for Pico Psu for SERVER PSU ONLY GPU MINING RIGS! | Donations: BTC-  | Join Me on Discord! https://discord.gg/VDwWFcK
apiontek
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
February 02, 2018, 01:06:46 AM
 #633

New 5.3.0 still won't work on my two Windows 10 machines with GTX 1070s. No output, regardless of option provided or no option provided. And the lack of debugging info, advice, attention by the dev speaks volumes.

I don't really care anymore. It reports higher hashrates on my Linux machines, but given other people's experiences, I'm suspicious, so I won't use it there.

Amusingly, it does run on Win10 on an old laptop I have that's powering a GTX 970 via external expresscard adapter. But it reports a lower hashrate than dstm so.... there's no point there.
dkmontague
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
February 02, 2018, 01:21:44 AM
 #634

On my 6 * 1080Ti, everything is the same( 240h/s). On dstm's ZCash 05.8 and ewbf miner 0.3.4b everything is fine.
With similar settings. In the furnace this miner.

Your issue appears identical to mine... have you found a solution?
cryptoyes
Member
**
Offline Offline

Activity: 176
Merit: 10


View Profile
February 02, 2018, 02:21:48 AM
 #635

It seems Bminer initialize the cards on my 14 GPU rigs very slowly ( minutes ).
I have experienced this "issue" with ccminer too, but a "--cuda-schedule 12" command solve the problem without high CPU usage (if I use any other number as 12 my CPU usages go to the moon but with 12, it's ok).

Any idea for that? realbminer?

Thanks!


This is expected -- The Linux version does not have this issue.

The reason is that I have to insert some delays to work around the bugs in the NVIDIA drivers under Windows. Without the delay the drivers will just hang.  Sad

However, I think there might be some opportunities to make it work better. Will look into it.

It most certainly does too under Linux. 40 seconds driver init time for 13 cards under 384.xx drivers, and a whopping 80-90 seconds for the same 13 cards under 387.xx and 390.xx drivers ... Nvidia is making it worse and worse. I fu**ing hate working with Nvidia cards, especially under Linux. Fu**ing bastards and their shitty idiotic drivers and software (that also require you to run X in order to overclock).

If you know of a way to get rid of this long driver init time under Linux, then please, by all means, do share!
orangesherbet0
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
February 02, 2018, 06:14:46 AM
 #636

Guys, bminer has been shown to inflate its reported hashrate. In the code (which nobody can see) this is really easy to do - and why wouldn't you inflate it 10% if it meant 10x more people downloading your program (which you make a lot of profit from)?

The problem is, somebody benchmarked it and showed it to be no faster than DSTM ZM, which shows a much lower hashrate.

https://forum.z.cash/t/new-miner-bminer-a-fast-equihash-miner-for-cuda-gpus-5-1-0/26197/12

Please stop spreading this scam miner, and by god don't install it.
anotherwave
Newbie
*
Offline Offline

Activity: 39
Merit: 0


View Profile
February 02, 2018, 10:37:56 AM
 #637

I was very skeptical as well for a long time and then I did a 48hr test on 3 1070's on the same rig with the exact same OC's. One running bminer, bminer -nofee and dstm. So bminer seems to start a little slow but by the end bminer was ahead of dstm by a bit so it seems very comparable if not a little faster but who knows exactly with miner luck and what not.. In the case of 1080ti's i find it runs better than dstm.. Thats what i got from my tests... I still like running dstm on my rigs for stability with a monitoring program keeping a eye on it.  
ltc_bilic
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
February 02, 2018, 11:55:01 AM
 #638

@realbminer: Because all the miners control miner/gpu crashes differently I prefer to do my own pool switching in simple loop and task scheduler keeps my gpu healthy. Now here's the problem, according to you're reference guide:

Quote
-gpucheck uint   90   The interval in seconds that Bminer polls whether the CUDA devices have hung. Set to 0 to disable the checks.
-max-network-failures   -1   Number of consecutive attempts that Bminer tries to recover from network failures. Set to -1 to keep on recovering.
-watchdog   true   Automatic restart to recover from hung GPUs. Bminer exits itself in case of errors if watchdog is disabled.

In order to achive this,...to control everything our selves,...the following should work:
Code:
-max-network-failures 5 -gpucheck 0 -watchdog=false

But unfortunately it doesn't bminer.exe keeps running even if you kill it manually with admin privileges. I've tested it with 5.2 version, haven't had the time to test 5.3 yet.
Can you please elaborate how to effectively control it our selves. I've tested it on Win 8.1 and Win 10. On ewbf miner --eexit 1 works perfectly.
MagicSmoker
Full Member
***
Online Online

Activity: 294
Merit: 136



View Profile
February 02, 2018, 12:39:56 PM
 #639

I just started a head-to-head comparison of dstm 0.5.8 and bminer 5.3.0 mining ZEN to separate wallet addresses on luckpool.org with each getting a GTX 1080 that were tuned to have matching hashrate on either miner (ie - the hashrate reported by bminer was the same on each card, not that the hashrates for bminer and dstm were the same).

Test started at 6:00AM my time and will run for 24 hours so I can use the average difficulty on minethecoin to evaluate how accurately each miner reports its hashrate and, of course, to see which one comes out on top.

I should note, however, that I had some issues with bminer locking up my computer so hard I had to hit the reset button when I tried to exit it while I was setting up the test; not a promising start, really, but it seems to run okay if left alone.

DES_MX
Member
**
Offline Offline

Activity: 163
Merit: 13


View Profile
February 02, 2018, 01:10:15 PM
 #640

Following this with great enthousiasm
Do keep us posted
What's preliminary assessment?

I just started a head-to-head comparison of dstm 0.5.8 and bminer 5.3.0 mining ZEN to separate wallet addresses on luckpool.org with each getting a GTX 1080 that were tuned to have matching hashrate on either miner (ie - the hashrate reported by bminer was the same on each card, not that the hashrates for bminer and dstm were the same).

Test started at 6:00AM my time and will run for 24 hours so I can use the average difficulty on minethecoin to evaluate how accurately each miner reports its hashrate and, of course, to see which one comes out on top.

I should note, however, that I had some issues with bminer locking up my computer so hard I had to hit the reset button when I tried to exit it while I was setting up the test; not a promising start, really, but it seems to run okay if left alone.



Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!