What is the relationship between hash rate and accepted shares? Specifically this question is about Litecoin, but I suspect the answer would apply to both.

Say you have a rig mining at 700Kh/s (LTC). It seems that you get, more or less, a one or a few accepted shares per second.

My understanding is that when mining, you're iterating through 0 to ~ 4 billion for your nonce. One of those nonce's is the number you're looking for and will result in an accepted share.

On average, you'd expect to solve for the correct nonce in about 2 billion tries. But, if you're only mining at 700Kh/s, the math doesn't add up. If you're only trying 700,000 nonces per second, it will take about 45 minutes to find the right nonce.

What am I missing here?
There really isn't one when you are pool mining. Most pools these days use VarDiff to achieve the same number of shares per minute by changing your workers difficulty. Now, on a low end mining rig (lets say 20 kh/s) the number of shares accepted may vary greatly as you may have some great luck with your share or it may be bad luck. So as long as you have a "sane" level of hashing power you shouldn't see (m)any trends/changes (as long as the pool+VarDiff is properly set up).

That being said, when you are first connecting to VarDiff enabled pools you will start at a diff of 1, then it will adjust over a period of time to achieve a share per minute rate that was defined by the pool op.

Source: Me, I'm a pool-op

EDIT
At one time, the number of shares you submitted directly related to your hashrate, the more accepted shares, the faster you were hashing. AsicMiner products still use the protocol originally used by pools (and bitcoind) called "getwork". Most notable of the pool servers used at that time is pushpool.

With VarDiff you don't have the ability to calculate by the number of shares submitted. So you now calculate the hashrate based on the difficulty of the share submitted. I personally have found that when the hashrate calculation based purely on the number of shares submitted is slightly weighed in with your hashrate calculation based on the difficulty of the share submitted, the user's hashrate you calculate is more accurate than you would have if you calculated the hashrate purely on the difficulty of the submitted share.