If you preallocate your thin devices the unwritten to preallocated tracks will appear cold to FAST VP and will be demoted to the lowest tier.

You did not say what Enginuity release you were running.

What is your workload analysis period set to?  If it is the default of 1 week, you may want to consider increasing it so that workload statistics don't decay as quickly.

Enginuity is running 5876.229.145.

We only have about 1 TB preallocated, and about 800 Gig of that is in use.

I can't get to the Workload Analysis Period in the Optimizer dashboard, I get a message saying "Optimizer Get Status Failed, The requested feature is not supported for this Engiuity or SYMAPI version".

Under Performance, Settings, System Registrations, Data Collection Policies Details, I see Collection Recovery set at 24 Hours and Diagnostic Interval set to 5 minutes.  I'm not sure if those settings are related.

5876.268 was just made "target" code, AFAIK.  Previous was 5876.251.  I would recommend getting to more recent code.  I'm pretty sure there were some fixes in later releases that resulted in less data being demoted to SATA in some cases.

Also if you are having trouble setting or seeing the FAST VP parameters, you should probably open an SR to get that addressed.

The following CLI command should show your Workload Analysis Period:

symfast -sid xxx list -control_parms

The week period sets the decay rate.  The most recent activity will have the highest scores.  The workload a few days old will have decayed significantly.  You may want to increase the workload period to two weeks in order to keep active devices in higher tiers longer.  It won't stop the most recently active devices from having the highest scores for promotion, but could slow demotion. 

The workload analysis period is 168 hrs/1 week.  I wouldn't think data would get cold after a week, the only week we see little activity is end of December and weekends.  I'm going to look thru the release notes to see if I can find the issue that mentioned earlier.

Here is the full result of the command.

Optimizer and FAST Control Parameters:

Data Movement Mode                : N/A
Max Simultaneous Device Moves     : N/A
Max Device Moves Per Day          : N/A

Optimizer, FAST and FAST VP Control Parameters:

Min Initial Workload Period(hrs)  : 8
Workload Analysis Period(hrs)     : 168

FAST Control Parameters:

Swap Not Visible Devices          : N/A
Allow Only Swap                   : N/A

FAST VP Control Parameters:

FAST VP Data Movement Mode        : AUTO
FAST VP Data Relocation Rate      : 5
Thin Pool Reserved Capacity(%)    : 10
VP Allocation By FAST policy      : Enabled
FAST VP Time to Compress          : Never
FAST VP Compression Rate          : 5
FAST VP Compliance Mode           : N/A

Thanks for the explanations.  I have a SR that has been escalated to Level 2 about the error message.  I decided to set the time window for monitoring performance to 8 am to 5 pm, being that is time of day that we care about performance.  Maybe having the window at the default of 24 hours with little to no activity outside of server backups could have been an issue.  I'm hoping to see a difference in a few days by changing those settings.

Restricting the monitor window will likely result in more demotions, not less.

I'm guessing you just have a workload with a high skew - that means a small amount of data doing the vast majority of the work. Since FAST VP works sub-lub,  if you have only a few chunks of data doing most of the world it would attempt to move the cold data down.

You can engage your EMC pre sales team to look using tier advisor,  and that will tell you the skew in your workload.