Your configuration looks fine. So I think you need to pay attention to and do the following:

1) It needs time (generally around a few minutes) for ntpd to "warm" up. This is because ntpd needs to gather enough 
samples from the time resources in order to make decision on , e.g, if the time resoures are of good quality. So, make 
sure if the 6min difference is still there after you make sure the server and the client are in ntp-working state. The 
how-to is the following. 

2) On your client box, you may run ntpdate -d your_server (or simply ntpq -p your_server) to check if the server is 
ready to sync to. The ntpdate with -d option will do only the check and will not really adjust your system time. You may
 run ntpdate -d 127.0.0.1 to check if the client's ntpd is in normal working state. 

3) Most of the cases, if the larger the time difference between your server and client, the longer time for your client 
costs to sync with your server. So in practics, people run "ntpdate" first to sync with the servers and then run ntpd. 
If you look into initial config files on such as *BSD or Linux, you may see a rc.d script that parses /etc/ntp.conf and 
run ntpdate to sync with servers there.

4) no matter how good quality the outside time resources are, you have to have a relatively good quality (I mean clock) 
client box. So on your client side, you'd better have your "local clock" be one of the time resources. You'd better put 
its stradum a lower value, say, 12 for example, so the client ntpd would put more emphasis on higher stradum resources 
(say your server, it is of 7 as you defined) than on itself.