Your `where` condition that checks for equality for `utcdt` converted to a date is SARGable, but uses a [dynamic seek](http://sqlblog.com/blogs/paul_white/archive/2012/01/18/dynamic-seeks-and-hidden-implicit-conversions.aspx).

> The problem is that these hidden implicit conversions can result in inaccurate cardinality and distribution estimations at any stage of the plan.  So, even if you get a seek, the plan might be way off overall. - [Dynamic Seeks and Hidden Implicit Conversions - Paul White](http://sqlblog.com/blogs/paul_white/archive/2012/01/18/dynamic-seeks-and-hidden-implicit-conversions.aspx)

Try converting your `where` condition to an explicit range and see if there is any improvement:

    select *
    from Tick.X_H
    where Symbol = 'donkey'
      and utcdt >= convert(datetime2(7),'20110102')
      and utcdt <  convert(datetime2(7),'20110103')

Based on [this answer by Martin Smith](https://dba.stackexchange.com/a/34052/43889) the explicit range may reduce unnecessary reads.

References:

- [Dynamic Seeks and Hidden Implicit Conversions - Paul White](http://sqlblog.com/blogs/paul_white/archive/2012/01/18/dynamic-seeks-and-hidden-implicit-conversions.aspx)
- [Cast to date is sargable but is it a good idea?](https://dba.stackexchange.com/questions/34047/cast-to-date-is-sargable-but-is-it-a-good-idea)
- [SARGable functions in SQL Server - Rob Farley](http://blogs.lobsterpot.com.au/2010/01/22/sargable-functions-in-sql-server/)