OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[CommanderVenus]

I think you might already know about this issue but anyway..

I am using the Raspberry Pi and i got cgminer 3.2.1 working perfectly with one Block Erupter on my hub. Giving amazing results even, less than 1% HW issues.

I have been trying to run the same setup but with 4 block erupters and i keep getting issues. The block erupters keep being announced as SICK because they wont start, and if i happen to get all four to start somehow, they are running at a fraction of the hashrate they should be.

Im using the same hub and 4 block erupters but with cgminer 3.1.1 on windows 7 32 bit and they are going to town, hashing with no issues. So my hub and block erupters are playing nicely together.

Has anyone successfully gotten cgminer working with multiple block erupters on their raspberry pi yet?

[GoldBit89]

How do i set up to lower my discarded work due to a new block?

Also is there a way to increase my shares above target and decreasing

my shares below target?

here is a partial log report just completed for about 6 and a half

hours:

[10/06/2013 12:42:28 PM] Share below target
 [10/06/2013 12:42:33 PM] Share below target
 [10/06/2013 12:43:17 PM] Share below target
 [10/06/2013 12:43:24 PM] Share below target
 [10/06/2013 12:43:25 PM] New block: 9c769647a18857de... diff 41.8M
 [10/06/2013 12:43:25 PM] Stratum from pool 0 detected new block
 [10/06/2013 12:43:26 PM] Share below target
 [10/06/2013 12:43:31 PM] Share below target
 [10/06/2013 12:43:41 PM] Share below target
 [10/06/2013 12:43:51 PM] Share below target
 [10/06/2013 12:44:12 PM] Share below target
 [10/06/2013 12:44:25 PM] New block: 168ef66e83963534... diff 41.8M
 [10/06/2013 12:44:25 PM] Stratum from pool 0 detected new block
 [10/06/2013 12:44:27 PM] (120s):4.352K (avg):4.350Kh/s | A:25  R:0 

HW:0  U:0.1/m  WU:4.1/m

 [10/06/2013 01:07:32 PM] Started at [10/06/2013 06:35:54 AM]
 [10/06/2013 01:07:32 PM] Pool: stratum+tcp://ltc.allpoolz.com:8080
 [10/06/2013 01:07:32 PM] Runtime: 6 hrs : 31 mins : 37 secs
 [10/06/2013 01:07:32 PM] Average hashrate: 4.4 Kilohash/s
 [10/06/2013 01:07:32 PM] Solved blocks: 0
 [10/06/2013 01:07:32 PM] Best share difficulty: 6.32K
 [10/06/2013 01:07:32 PM] Share submissions: 25
 [10/06/2013 01:07:32 PM] Accepted shares: 25
 [10/06/2013 01:07:32 PM] Rejected shares: 0
 [10/06/2013 01:07:32 PM] Accepted difficulty shares: 1600
 [10/06/2013 01:07:32 PM] Rejected difficulty shares: 0
 [10/06/2013 01:07:32 PM] Reject ratio: 0.0%
 [10/06/2013 01:07:32 PM] Hardware errors: 0
 [10/06/2013 01:07:32 PM] Utility (accepted shares / min): 0.06/min
 [10/06/2013 01:07:32 PM] Work Utility (diff1 shares solved / min):

4.11/min
                                     920 discarded due to new work

requests
 [10/06/2013 01:07:32 PM] Stale submissions discarded due to new

blocks:

0
 [10/06/2013 01:07:32 PM] Unable to get work from server occasions: 0
 [10/06/2013 01:07:32 PM] Work items generated locally: 1555
 [10/06/2013 01:07:32 PM] Submitting work remotely delay occasions: 0
 [10/06/2013 01:07:32 PM] New blocks detected on network: 142

Current Settings:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1

"C:\Users\xxxxx\Desktop\guiminer-

scrypt_win32_binaries_v0.04\cgminer\cgminer-3.1.1-windows

\cgminer.exe" --scrypt -u xxxxx -p xxxxxx -o stratum

+tcp://ltc.allpoolz.com:8080 2>logfile.txt 3>sharesfound.txt --gpu-

platform 0 -d 0 -w 128 -v 1 -I 9 -g 1 -l 1 --shaders 1500 --thread-

concurrency 4064 --lookup-gap 2


as you can see 1600 accepted shares but only 25 of 64 difficulty

along with 920 that were being worked on when a new block was found

and was discarded.Whats even more disturbing is that only 142 new

blocks detected on network but yet 920 possible shares were

discarded.

Any suggestions on how i can improve upon this "Without" new

hardware?

[pirate1]

ckolivas, thank you.  I used the zadig utility and changed the drivers and now the new version is running fine.  I thought it was something simple I was overlooking and it was.  I was missing the obvious and was stuck so I really appreciate the answer you gave.  I expect to be receiving my new ASIC single from BFL this week so I wanted to have the latest version.  Now I do, once again thank you

[HellDiverUK]

I'm experiencing a very odd and blocking problem: was mining with CGMINER 3.1.0 on Radeon HD 5750, never had problem, with SHA256 nor Scrypt, all was fine.
At some point I tried CGMINER 3.2.0 and it crashed at start (could only see one line "Started CGMINER 3.2.0" and then crashed).
The odd thing is that from that point over even all other versions of CGMINER do the same!!! I cannot anymore use CGMINER! I've tried with 3.1.1 (that I'm succesfully using on another PC): crash. 3.1.0 that was working well before: crash. Today I tried even 3.2.1: crash.
I did a Dr. Mingw debug for you, hoping to understand what the hell is happening.

Code:

cgminer.exe caused an Access Violation at location 004312d2 in module cgminer.exe Reading from location 072ff1d3.

Registers:
eax=76709102 ebx=0445fd14 ecx=00000000 edx=00000000 esi=0445fc80 edi=00000000
eip=772de1a4 esp=0445fb58 ebp=0445fcd8 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

Call stack:
772DE1A4  ntdll.dll:772DE1A4  ZwWaitForMultipleObjects
76AE6AEB  KERNEL32.DLL:76AE6AEB  WaitForMultipleObjects
0045A362  cgminer.exe:0045A362
0045ACD7  cgminer.exe:0045ACD7
Registers:
eax=00000000 ebx=7fffffff ecx=00000000 edx=00000000 esi=ffffffff edi=0097c6d8
eip=772ddc34 esp=04d5f998 ebp=04d5f9d8 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

Call stack:
772DDC34  ntdll.dll:772DDC34  NtWaitForSingleObject
71F78599  mswsock.dll:71F78599  Tcpip4_WSHGetWildcardSockaddr
75140CCF  WS2_32.dll:75140CCF  select
0041C6B8  cgminer.exe:0041C6B8  socket_full  util.c:1057
0041C6FD  cgminer.exe:0041C6FD  sock_full  util.c:1069
0040F6B0  cgminer.exe:0040F6B0  stratum_rthread  cgminer.c:4962
00459F25  cgminer.exe:00459F25
7670906A  msvcrt.dll:7670906A  _ui64tow
76709147  msvcrt.dll:76709147  iswalnum
76AE8543  KERNEL32.DLL:76AE8543  BaseThreadInitThunk
7730BF39  ntdll.dll:7730BF39  RtlInitializeExceptionChain
7730BF0C  ntdll.dll:7730BF0C  RtlInitializeExceptionChain
XXXXXXXXXXXXXXXXXXXXXX
Registers:
eax=072ff1cf ebx=02008668 ecx=ffb8e50d edx=00000008 esi=01ff2e68 edi=02007c6a
eip=004312d2 esp=0028f4e0 ebp=0028f548 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
004312D2  cgminer.exe:004312D2  patch_opcodes  ocl.c:178
004333EF  cgminer.exe:004333EF  initCl  ocl.c:738
00430218  cgminer.exe:00430218  opencl_thread_prepare  driver-opencl.c:1332
00419410  cgminer.exe:00419410  main  cgminer.c:7691
004010B9  cgminer.exe:004010B9  __mingw_CRTStartup  crt1.c:244
00401284  cgminer.exe:00401284  WinMainCRTStartup  crt1.c:274
76AE8543  KERNEL32.DLL:76AE8543  BaseThreadInitThunk
7730BF39  ntdll.dll:7730BF39  RtlInitializeExceptionChain
7730BF0C  ntdll.dll:7730BF0C  RtlInitializeExceptionChain
Registers:
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000002 edi=0097afe0
eip=772df6b4 esp=048dfdec ebp=048dff84 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

Call stack:
772DF6B4  ntdll.dll:772DF6B4  ZwWaitForWorkViaWorkerFactory
76AE8543  KERNEL32.DLL:76AE8543  BaseThreadInitThunk
7730BF39  ntdll.dll:7730BF39  RtlInitializeExceptionChain
7730BF0C  ntdll.dll:7730BF0C  RtlInitializeExceptionChain
Registers:
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=0469fe6c edi=00001cb4
eip=772ddc34 esp=0469fe28 ebp=0469fe90 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

Call stack:
772DDC34  ntdll.dll:772DDC34  NtWaitForSingleObject
753A10B4  KERNELBASE.dll:753A10B4  WaitForSingleObject
0FB90B1B  amdocl.dll:0FB90B1B  clGetSamplerInfo
0FB872A7  amdocl.dll:0FB872A7  clGetSamplerInfo
0FB87456  amdocl.dll:0FB87456  clGetSamplerInfo
0FB84362  amdocl.dll:0FB84362  clGetSamplerInfo
0FB96FD6  amdocl.dll:0FB96FD6  clGetSamplerInfo
76AE8543  KERNEL32.DLL:76AE8543  BaseThreadInitThunk
7730BF39  ntdll.dll:7730BF39  RtlInitializeExceptionChain
7730BF0C  ntdll.dll:7730BF0C  RtlInitializeExceptionChain
Registers:
eax=00000000 ebx=04b1f8a4 ecx=00000000 edx=00000000 esi=04b1f810 edi=00000000
eip=772de1a4 esp=04b1f6e8 ebp=04b1f868 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

Call stack:
772DE1A4  ntdll.dll:772DE1A4  ZwWaitForMultipleObjects
76AE6AEB  KERNEL32.DLL:76AE6AEB  WaitForMultipleObjects
0045A362  cgminer.exe:0045A362
0045ACD7  cgminer.exe:0045ACD7
753AEE71  KERNELBASE.dll:753AEE71  CreateEventExW
753AEE8C  KERNELBASE.dll:753AEE8C  CreateEventExW
753B3BFE  KERNELBASE.dll:753B3BFE  CreateEventExA
00458630  cgminer.exe:00458630
0041BD00  cgminer.exe:0041BD00  tq_pop  util.c:769
0040F9D0  cgminer.exe:0040F9D0  stratum_sthread  cgminer.c:5053
00459F25  cgminer.exe:00459F25
7670906A  msvcrt.dll:7670906A  _ui64tow
76709147  msvcrt.dll:76709147  iswalnum
76AE8543  KERNEL32.DLL:76AE8543  BaseThreadInitThunk
7730BF39  ntdll.dll:7730BF39  RtlInitializeExceptionChain
7730BF0C  ntdll.dll:7730BF0C  RtlInitializeExceptionChain
Registers:
eax=76709102 ebx=6b619070 ecx=00000000 edx=00000000 esi=029afe90 edi=00000000
eip=772de1a4 esp=029afd68 ebp=029afee8 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

Call stack:
772DE1A4  ntdll.dll:772DE1A4  ZwWaitForMultipleObjects
76AE6AEB  KERNEL32.DLL:76AE6AEB  WaitForMultipleObjects
6B608229  libusb-1.0.dll:6B608229  windows_clock_gettime_threaded
76709147  msvcrt.dll:76709147  iswalnum
76AE8543  KERNEL32.DLL:76AE8543  BaseThreadInitThunk
7730BF39  ntdll.dll:7730BF39  RtlInitializeExceptionChain
7730BF0C  ntdll.dll:7730BF0C  RtlInitializeExceptionChain

I hope that someone can lead me to the solution.... I'm now using bitminter java client, but I want a scrypt miner and I like so much CGMINER...!
Thank you in advance to who will reply!

Had the same problem, even with fresh install of Windows.  Fresh install, installed 12.8 drivers, crash.  Another fresh install, 13.4 drivers, crash.  Another fresh install, 12.8 drivers, SDK, crash.  

Seems GPU mining is ignored now, developer is like a bitch in heat over USB mining bollocks.

Gave up with not getting any answers on here, tried latest BFGMiner with 13.4 and it's working no problems.    

[-ck]

Had the same problem, even with fresh install of Windows.  Fresh install, installed 12.8 drivers, crash.  Another fresh install, 13.4 drivers, crash.  Another fresh install, 12.8 drivers, SDK, crash.  

Seems GPU mining is ignored now, developer is like a bitch in heat over USB mining bollocks.

Gave up with not getting any answers on here, tried latest BFGMiner with 13.4 and it's working no problems.    

Thanks.

P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0

[HellDiverUK]

Had the same problem, even with fresh install of Windows.  Fresh install, installed 12.8 drivers, crash.  Another fresh install, 13.4 drivers, crash.  Another fresh install, 12.8 drivers, SDK, crash.  

Seems GPU mining is ignored now, developer is like a bitch in heat over USB mining bollocks.

Gave up with not getting any answers on here, tried latest BFGMiner with 13.4 and it's working no problems.    

Thanks.

Plenty of people apart from myself have pointed out the issue, and you can see in the thread it's totally ignored.  Then someone asks about some jippy USB thing and there's an instant response.

How about actually looking at the issue with GPU mining?  The issue where cgminer just crashes instantly on run.  Or crashes once it's compiled the .bin files.  Or the issue where it just gives up mining and sits there farting about at 20kH/s for no reason.

I've asked plenty of times.  Tell us exactly what we need to install.  What SDK version?  What Catalyst version?  Any other dependencies?  What is cgminer expecting on Windows?

As I said, I've got 3 identical in every way machines.  I install Windows off the same USB stick, install the same updates off my WSUS server, install the same drivers off a network share, extract the same .zip of cgminer, copy in the same .config file, and 1 out of the 3 machines will actually mine.  Then it's another crapshoot if I decide to change hardware.  A machine running perfectly will suddenly stop working if I add another card, and even stripping off cgminer in total and reinstalling it will leave the machine unable to mine.  Then it's a 50/50 chance it'll mine after a reinstall.

There's too much of a crapshoot in getting cgminer working now.  Old 2.11.x just worked.  Now 3.x is impossible.

[HellDiverUK]

P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0

I'll try that. 

[HellDiverUK]

P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0

I'll try that. 

Heh, what do you know?  That worked.  hotplug was set to '5' in the .config file (not set by me). 

Perhaps that should be set to 0 by default in future versions?

Thanks for that.  Seems my rant got through.    Sorry I had to do it. 

[freshzive]

I have been trying to run the same setup but with 4 block erupters and i keep getting issues. The block erupters keep being announced as SICK because they wont start, and if i happen to get all four to start somehow, they are running at a fraction of the hashrate they should be.

This happens to me using 3.2.1 on just a normal Ubuntu box. The erupters all connect fine and start hashing, but then they go "SICK" because they haven't produced any work in 60s. A few seconds later, they reconnect and submit shares, this happens over and over, but overall the hash rate is much much lower for each erupter than it should be.

They work fine on 3.1.1 however.

[-ck]

I have been trying to run the same setup but with 4 block erupters and i keep getting issues. The block erupters keep being announced as SICK because they wont start, and if i happen to get all four to start somehow, they are running at a fraction of the hashrate they should be.

This happens to me using 3.2.1 on just a normal Ubuntu box. The erupters all connect fine and start hashing, but then they go "SICK" because they haven't produced any work in 60s. A few seconds later, they reconnect and submit shares, this happens over and over, but overall the hash rate is much much lower for each erupter than it should be.

They work fine on 3.1.1 however.

Maybe you can try disabling hotplug too? --hotplug 0

[freshzive]

Maybe you can try disabling hotplug too? --hotplug 0

Still getting these

 [2013-06-11 07:58:35] AMU3: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU3: Attempting to restart
 [2013-06-11 07:58:35] AMU4: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU4: Attempting to restart
 [2013-06-11 07:58:35] AMU6: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU6: Attempting to restart
 [2013-06-11 07:58:37] AMU2: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:37] AMU2: Attempting to restart
 [2013-06-11 07:58:39] AMU0: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:39] AMU0: Attempting to restart
 [2013-06-11 07:58:41] AMU1: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:41] AMU1: Attempting to restar

[-ck]

Maybe you can try disabling hotplug too? --hotplug 0

Still getting these

 [2013-06-11 07:58:35] AMU3: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU3: Attempting to restart
 [2013-06-11 07:58:35] AMU4: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU4: Attempting to restart
 [2013-06-11 07:58:35] AMU6: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:35] AMU6: Attempting to restart
 [2013-06-11 07:58:37] AMU2: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:37] AMU2: Attempting to restart
 [2013-06-11 07:58:39] AMU0: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:39] AMU0: Attempting to restart
 [2013-06-11 07:58:41] AMU1: Idle for more than 60 seconds, declaring SICK!
 [2013-06-11 07:58:41] AMU1: Attempting to restar

Thanks for trying it at least. We have a call into libusb on that platform that never returns (which shouldn't happen). We're still investigating...

[TheSwede75]

I feel like this is pretty nooby, but I fell into a Bitforce SHA256 and want to try it out. What commands do I need to run CGminer with the FPGA (BFL)? It's on COM7 currently and I get 'you need to install USB driver for BFL 7' as error (easyminer finds it and diagnosis works 100%)

[os2sam]

I got my Block Erupter's today.  So I sat down with the ASIC Readme and braced myself for all of the trouble everyone else seemed to be having with them.

Well per the readme I installed WinUSB via the Zadig utility and then popped in an Erupter and kicked off CGMiner-nogpu and it just started mining.  I popped a second one of the fly and it populated the list and started mining that as well.

I'm mining with 4 of these plugged directly into my Win7 32 Bit mining rig w/CGMiner 3.2.1 and they are all off to the races.  When I receive my USB Hubs and fans I'll get the other two working as well but for now 4 is all I could get to fit into my rig.

It couldn't have been easier.  Thanks guys for making this so easy.  But I do miss the complicated setups and the trial and error, but it's nice to just have it work too.

Thanks,
Sam

[ISAWHIM]

Seems 3.2.0 and 3.2.1 have a greater number of rejections of "valid" blocks.

On faster systems, this is multiplied exponentially.

EG, (No other target-block in range) Reject rate about 25-50% submitted 456K, 125K, 214K, 100K, on a 100K rate. (Takes 120K-101K, but seems to reject exact targets, and over-targets, randomly.) Reject rate on a 7K hash-rate, is nearly 75%-80%... Thus, the decaying rates of all scrypt-coins at the moment. (EG, estimated earnings 100 coins returns a real-world earning of only 20 coins. Once again, with no target blocks being the "cause of the rejection".)

This is NOT present with 3.1.0 but that program is no longer compatible with new wallets/servers. Something dramatic changed, and it rejects 100% of those blocks, if it even connects at all. EG, using 3.1.0 and a compatible wallet, this does not happen, but the older wallets are no longer accepted with the network.

This is NOT limited to scrypt mining. This is happening to sha256 also, and I assume bitcoin... thus, the value remaining steady and the "rate" not rising proportionally with the work-load, because the work-load is only producing 80-75% valids that the network is accepting. (Either they are not actually valid, but the miner thinks they are... or they are, and they are not being delivered and confirmed correctly on the wallet/server side.)

Run a test with a difficulty of 7K... Solo, and with a mini-network. (Using compiled windows programs, as I can not confirm these results with linux, where they might not exist. Present on Win7-64bit and Vista-32bit. Same results.)

CGminer 3.1.0 and lower works on wallets versions 6.3 and lower. CGminer 3.2.x only works on wallets 6.4 and higher. (It has been a scramble to upgrade all the networks, and now they are all failing due to this issue. Falling difficulties yielding lower returns than higher difficulties, which results in even lower difficulties and even higher losses. Since even less coins are mined with each lower difficulty, not more, as expected.)

Though it is the same results... "Vista 32-bit" has 50% valid rejects, while "Win7 64-bit" has closer to 80% valid rejects. (Partially a 64-bit incompatability issue? Using calls with invalid LONGS... 32-bit and 64-bit do not operate the same. Seems like one call causing trouble, or TCP delivery failure, making it invalid, when it is actually valid.)

[mdude77]

Seems 3.2.0 and 3.2.1 have a greater number of rejections of "valid" blocks.

On faster systems, this is multiplied exponentially.

EG, (No other target-block in range) Reject rate about 25-50% submitted 456K, 125K, 214K, 100K, on a 100K rate. (Takes 120K-101K, but seems to reject exact targets, and over-targets, randomly.) Reject rate on a 7K hash-rate, is nearly 75%-80%... Thus, the decaying rates of all scrypt-coins at the moment. (EG, estimated earnings 100 coins returns a real-world earning of only 20 coins. Once again, with no target blocks being the "cause of the rejection".)

This is NOT present with 3.1.0 but that program is no longer compatible with new wallets/servers. Something dramatic changed, and it rejects 100% of those blocks, if it even connects at all. EG, using 3.1.0 and a compatible wallet, this does not happen, but the older wallets are no longer accepted with the network.

This is NOT limited to scrypt mining. This is happening to sha256 also, and I assume bitcoin... thus, the value remaining steady and the "rate" not rising proportionally with the work-load, because the work-load is only producing 80-75% valids that the network is accepting. (Either they are not actually valid, but the miner thinks they are... or they are, and they are not being delivered and confirmed correctly on the wallet/server side.)

Run a test with a difficulty of 7K... Solo, and with a mini-network. (Using compiled windows programs, as I can not confirm these results with linux, where they might not exist. Present on Win7-64bit and Vista-32bit. Same results.)

CGminer 3.1.0 and lower works on wallets versions 6.3 and lower. CGminer 3.2.x only works on wallets 6.4 and higher. (It has been a scramble to upgrade all the networks, and now they are all failing due to this issue. Falling difficulties yielding lower returns than higher difficulties, which results in even lower difficulties and even higher losses. Since even less coins are mined with each lower difficulty, not more, as expected.)

Hmm.  Not sure I understand all this.  But I can say I found using 3.1.1 against Bitminter gives me more rejects directly than if I funnel them through the stratum proxy.  I prefer using the proxy because it kicks in the variable difficulty and only one machine is connecting to the pool instead of all 4, reducing my (and pool ops) bandwidth usage.

Getting 4 difficulty thru the proxy, I get hardly any rejects.  Whereas with 1 difficulty with each miner going there individually, I do see more.  I can't quantify it, and it might just be because there are more diff 1 shares submitted than diff 4 shares, therefore I'll see more rejects. 

Just my $.02 worth.

M

[ISAWHIM]

So that may confirm it is a TCP thing... (Delivery)... Since stratum is a separate TCP controller. (Eg data not being "packed right, loosing data, or clipping due to "MTU transmission limits reached". Or a missing terminator or terminator that is being "seen" as part of the submitted data, thus, corrupting the valid, making it look invalid.)

However, even pools with stratum are facing this issue. (They are assuming it is the pool-program, but I have confirmed it is a wallet/miner issue, through every single coin, and the difficulty charts confirm it. The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

[os2sam]

The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

The difficulty adjusts every 2,016 blocks.  According to Bitcoin Watch we still have 891 to go.

[-ck]

The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

The difficulty adjusts every 2,016 blocks.  According to Bitcoin Watch we still have 891 to go.

As os2sam said:
15605632.68129 | Next Diff in 889 blocks | Estimated Change: 20.3644% in 4d 21h 56m 38s

All looks fine to me.

[Mobius]

However, even pools with stratum are facing this issue. (They are assuming it is the pool-program, but I have confirmed it is a wallet/miner issue, through every single coin, and the difficulty charts confirm it. The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

You might want to lay off the caffeine or whatever else your sipping on.

http://allchains.info/ shows 18M in ~5 days.