Cisco Switches :: SG300 Port Counters Via SNMP / Do They Work

I've got an SG300-10 connected back to back (trunked) with a Cisco 3560X switch, across a fibre link and am seeing some big inconsistencies in terms of unicast data transferred across the ports between them.
 
During a night time window of 4am - 6am I run backups which involves a large copy of files, that almost saturates a GigE link - we can see from the 3560X end that the link is running at a bit over 800MBit/sec of throughput, sustained.  The duration of this transfer is consistent with the size of the files being transferred (ie just over an hour, and is what I'd expect for a data transfer of about that amount).  Back-of-the-envelope calculations indicate that the 3560X is measuring this data throughput correctly.
 
However on the SG300 end of the link, which is also being polled by the same application (Cacti), I'm observing spikey counts of only around 20MBit/sec during that window.  These counters are very obviously incorrect - there's a huge amount more data moving across the port than that.  The incorrect calculations are showing on both the trunk port out of the SG300 (uplink) as well as the interface where the NAS is connected in (which is an access port).
 
Cacti is polling the OID:  .1.3.6.1.2.1.2.2.1.16.57  which translates to IF-MIB::ifOutOctets.57 = Counter32.I'm running version 1.3.0.62 but this problem is not new to this release - previous releases and 1.2 based releases also had this problem.
 
It looks like multicast traffic may be being counted correctly (that's only a suspicion though), however what I am certain of is that there is a very large discrepancy with the unicast traffic counts.Is this OID the correct one to be using for this switch?