If it gets 100 confirmations then it's yours - slush spots about 95% of these and fixes them but people have been known to benefit (or lose) from these block mis-calculations - the best I ever got was around 8 times normal payout for a block that went to 100 confirmations - but I've had several where I got next to nothing and the 100 confirmations passed - this time I'm down - but for you it's all good unless slush sees it

[EDIT] for the long term slush miner - it all evens out

Seems like Slush is reading the forum but stays in "radio silence"  , rounds were re-calculated:

19195   2013-07-20 14:28:49   0:05:05   8794745   9542   0.01586825   247569   25.07941640    96 confirmations left
19194   2013-07-20 14:23:44   2:02:34   39788670   37043   0.02297916   247567   25.18610000    94 confirmations left

Now #19194 is correct but #19195 is wrong again

9542 8794745 * 25.079 = 0.0272

mines wrong as it should be over 5000 shares not 2136

19194   2013-07-20 14:23:44   2:02:34   39788670   2136   0.00132505

all my miners connecting to 95.211.52.40 were not showing shares on the website so I changed them to 54.215.3.101

now 2 miners connecting to .101 are showing not connected for x minutes the X is a random number each reload.
So that says a backend server is not caught up with the others and since all my miners are going to .101 I have to assume he enabled some round robin back end and still 1 server isnt behaving.

it's determining hashrate via sucessfully submitted shares over a given time, i think ten minutes. thus, as you submit more shares, the relative speed increases. yes, it will continue to do so until it reflects the real rate.

I've joined with single 7850 GPU and making 0.01 BTC a day which isn't bad. There were two minor incidents that I'd like an answer to.

First, yesterday I heard my GPU cranking really loud and upon inspection I was getting several hundred stale (connections?) in GUIMiner. At this time my account showed 0 hash rate. So I restarted my miner and everything came back to normal. I'd like to understand what happened there and what I can do to avoid it or possibly burning out my GPU.

Second, today everything was humming along and at the end of my work day I checked my account and it sowed last share 7 hours ago. I don't think I had made any contribution during this time. However my GUIMiner was clicking just normal showing 352 MH/S - In statistics, I have no shares from 19195 to 19199 while GUIMiner seem to be running normal. So I'd also like to find out what happened here?

I'm getting some USB ASIC chips on Monday and plan on changing over to BFGMiner. Is this the right thing to do with slush's pool?

Appreciate any input and keep up the good work.

Just as a forewarning... I dont think using the direct IP is necessarily a good long term option.  From what I understand, Slush uses Amazon AWS. AWS offers load balancing, geolocating\geocaching, and failover based on availability zones.  If AWS is like the Azure platform (which I work with for my job), IP addresses are not dedicated.  When you set it up, you point your regular public DNS to your AWS FQDN and then the AWS system handles DNS\Routing from there which is what allows the above Amazon services to function with little to no setup.  By specifying a server IP address, you are circumventing this feature. This may temporarily resolve an issue such as today when a specific load balancing server is down or a specific geolocation\availability zone is malfunctioning in a way that AWS doesn't recognize the malfunction and remove the specific server from the rotation.  However, long term you don't get the benefits of those options, which would be crucial if the specific server you chose fails.  Also, without dedicated IP's, there is no guarantee that server will continue to be located there after an IP lease renewal or a server reboot. 

I could be totally wrong about this, but this is why I wont use direct IPs.  I experienced the issues earlier today and I resolved them by bouncing NIC's on all my machines to reset my connection and flush old\invalid DNS data. I also bounced the proxy software on 2 of my machines that use that.  I never stopped CGMINER or GUIMINER (on my windows machine... I know I know but CGMINER throws fits on that machine) and the network bounce took less than a minute.
Just my $0.02 

When I used guiminer, I found one or more gpu's needed a stop/restart about every 12 hours or they'd go off into never-never land, and a complete kill and reload of the app about every 3 days kept it from crashing.

Now I use cgminer for my gpu workers and bfgminer for my fpga/asic workers.  cgminer gives me the same start-stop control over my gpus that guiminer did, without guiminer's frequent hangs, plus other controls not directly accessible in the guiminer app like temp cutoffs per gpu and fail-overs.  Last I used guiminer, it would not support fpga/asic workers -- don't know if it does now -- so use bfgminer since it usually auto-detects fpga/asic devices, and if it doesn't, you can force it to scan any usb ports it missed.  I could use bfgminer for my gpus, too, but have been too lazy to change my cgminer .bat files to bfgminer.