Re: What exactly is our CRC algorithm?

On Fri, Nov 21, 2014 at 03:41:45PM +0530, Abhijit Menon-Sen wrote:
> At 2014-11-20 13:47:00 +0530, ams(at)2ndQuadrant(dot)com wrote:
> >
> > > Suggestions for how to address (b) are welcome.
>
> With help from Andres, I set up a workload where XLogInsert* was at the
> top of my profiles: server with fsync and synchronous_commit off, and
> pgbench running a multiple-row insert into a single-text-column table
> with -M prepared -c 25 -t 250000 -f script.
>
> Unfortunately I can't see much difference despite running things with
> slightly different parameters a few dozen times. For example, here are
> real/user/sys times from three runs each with HEAD and slice-by-8 on an
> otherwise-idle i7-3770 server with a couple of undistinguished Toshiba
> 7200rpm SATA disks in RAID-1:
>
> HEAD:
> 2m24.822s/0m18.776s/0m23.156s
> 3m34.586s/0m18.784s/0m24.324s
> 3m41.557s/0m18.640s/0m23.920s
>
> Slice-by-8:
> 2m26.977s/0m18.420s/0m22.884s
> 3m36.664s/0m18.376s/0m24.232s
> 3m43.930s/0m18.580s/0m24.560s
>
> I don't know how to interpret these results (especially the tendency for
> the tests to slow down as time passes, with every version). At best, it
> shows that the new CRC code doesn't hurt, at worst it's just irrelevant.
> Supporting the latter interpretation, using the hardware-CRC patch also
> gives similar results (but XLogInsert is not at the top of the profile).
>
> Hardware-CRC:
> 2m29.090s/0m18.652s/0m23.764s
> 3m30.188s/0m18.692s/0m25.332s
> 3m38.110s/0m20.424s/0m24.532s
>
> If anyone has other suggestions, I'm all ears.
>
> -- Abhijit

Hi,

This indicates that another part of the system is the resource limit,
not the CRC calculation. My money is on the I/O system. Try it using
an in memory filesystem and see if that matters. Even if it is still
the same results, at least the new version of CRC is no worse than
the current version.

Regards,
Ken