My Scrypt Sleep level is 80.46%,now in 68th.

Sometimes the video drivers got error,and the mining speed can't reach normal speed.
Uninstall the old one with amd cleanup util and reinstall the new video driver may help.

I have 2 r9 280X and 1 7950
I use external cgminer,and it always works fine about three months.

After update the wallet software yesterday,the speed is just like before.
Here is my cgminer.conf,r9 280x got 700~720kh/s,7950 got 520kh/s:


{
"pools" : [
   {
      "url" : "127.0.0.1:9332",
      "user" : "benhur",
      "pass" : "1"
   }
]
,
"intensity" : "13,13,13",
"vectors" : "1,1,1",
"worksize" : "256,256,256",
"kernel" : "scrypt,scrypt,scrypt",
"lookup-gap" : "2,2,2",
"thread-concurrency" : "8192,8192,8192",
"shaders" : "2048,2048,2048",
"gpu-engine" : "0-1050,0-1050,0-960",
"gpu-fan" : "30-55,30-55,30-55",
"gpu-memclock" : "1500,1500,1250",
"gpu-memdiff" : "0,0,0",
"gpu-powertune" : "0,0,0",
"gpu-vddc" : "0.000,0.000,0.000",
"temp-cutoff" : "95,100,100",
"temp-overheat" : "95,100,100",
"temp-target" : "60,60,60",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scantime" : "7",
"scrypt" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

what kind of gpu do you have and wahy are your setting? I can mine fine with mine with no decrease in hash speed so it is definitely something on your end.

Scrypt sleep is not functional @ the moment. Try an external gui-miner and see what kind of speed you get.

Are you mining with with guiminer external to Gridcoin, or internal miner?

Try that, that should work!

Most of the users know this but I reiterate : You still do have to find one block before you are in the integrated pool list.

Wallet hour:  You should be paid multiple times during your wallet hour; one share every time another poolminer finds a block in your wallet hour.  It is possible to have an 'unlucky day' when users don't find many blocks in your wallet hour but it should average out.  You can audit this by checking the boinchash for found blocks during the unixtimestamp range of your wallet hour for the previous day.

Grid
PS I have one poolminer running and received 4 payments last night - I believe they were 80grc each ; fyi.

New Version Available:
1.1.5.4/65/7.71; Upgrade from RPC: Yes

* We fixed the German leaderboard factor problem (found today) (please upgrade and wait 1 1/2 hrs for the leaderboard to update; then verify).
* Due to the bloated wallet problem where the wallet grows daily when pool mining, and recent growth and efficiency, we switched our pool
mining system over to pay your pool mining rewards during your wallet hour (this should drastically reduce the transaction count and bring
stability back to the wallet)- if your wallet is larger than 1.5megs, send your coins to a new wallet and start over at your convenience.
If you are a pool miner, please upgrade to this version as soon as possible.

Best Regards,
Grid
 

I'd like to roll out SQL in phases:
* Client synchronization for standard data, blocks, tx, leaderboard - existing information that we can use for transaction auditing - all info can be harvested from the existing chain
* Full p2p distributed ledger: In the future, the ability to roll out data structures that are fully replicated and synchronized among our p2p network automatically.
* PoW (or PoS) based on the dissemination of the data itself.  Useful for CPU miners and for validating the integrity of the data (rejecting any injected data not approved by the network)

We have partially finished #1- you can query blocks and credit information from boinc.
#2 and #3 requires an expanded SQL spec; replicating the schema is fine, but Im working on the mechanism that secures the synchronized "official" ledger state.

From a high level, I think if we roll out a cryptographically strong formula that locks each row to a block key and block time and rowhash, and prunes old data, it would work.
The process itself of creating the rowhash may be the key to the PoW required for SQL replication; For example, if it takes time and effort for a client to generate the rowhash for new data, that is part of the PoW required to add info to the sql tables in order to be accepted by the network.

Yes, in theory, the SQL future features may not only be able to store useful data for the coin (such as the data you referring to) but we may even be able to set up pointers to
  web resources to store things like files that everyone can download - obviously to resources that have no point of failure and no central authority; etc; but Id like to focus on the SQL replication first.

Thanks,
Grid

Suggestion for easy publicity (only the team captain can set this up) - join any/all relevant WCG team challenges as they come up. The team will inevitably win from time to time, and such wins (or near wins) can be publicized widely. They will also draw the attention of competing team members and some may be tempted to jump teams. Finally, our own team members might find it motivating to follow challenge progress - it provides one more reason to pay attention to the WCG site.

I was captain of a WCG team for a while and found this approach useful and fun. We (about six of us at the time) once beat a team someone had unwisely named "U.S. Army". We got a lot of bragging mileage out of that one.   

It takes about 10 minutes time once or twice a month for a captain to enter a team in all the challenges of the moment. Oh, BOINC challenges too, if you like, but in my experience they are more obscure, more geeky, and less valuable for PR purposes than the WCG challenges.

Challenges, ftw!