SQL Server tempdb on SSD showing IO
I would highly recommend that you test your new T:\ drive using Crystal Disk Mark.  Check out the guide from Brent Ozar here:

How to Test Your Storage with CrystalDiskMark

Compare the results from the T:\ drive with


the old RAID 5 disk (where tempdb used to be)
your machine


If the SSD is slower than those other two devices, and nothing else has changed* in your setup, it's likely there is a problem with the disk itself, or with the driver being used, or the controller for the array this disk sits in, etc.

*things that might have changed since you moved tempdb:


the number of tempdb files for the database increased or decreased (someone said "hey, why not, since we have to restart the database to move tempdb anyway")
maintenance tasks were rescheduled to coincide with the now-slow nightly job (especially those that have potential to hit tempdb hard, like index rebuilds or checkdb)
the maintenance window to move tempdb was also used to deploy new code (for the nightly job, perhaps) that makes heavier use of temp tables, or has queries with bad spills, etc




Next Steps

Since it seems like the disk is reasonably fast (per the benchmarks you shared), I think it would be a good idea to log the contents of sys.dm_io_virtual_file_stats before and after the nightly batch job you mentioned.  This will tell you how much I/O is happening on tempdb during that process.  This is important, because maybe there really is more I/O than the disk can handle.  So here's what you do:


Run this query right before your nightly batch job is scheduled to run:

select * 
from sys.dm_io_virtual_file_stats((select DB_ID('tempdb')), default);

Save the results somewhere (like Excel or something - probably not in tempdb :P)
Wait 7 hours (until the job finishes)
Run the same query and save the results
Edit your question to include the results


We can then take the difference of the two snapshots and determine how many bytes were read / written during the job.  You can also use those numbers to calculate overall latency during that period.

Note: a more granular approach would be to log the results of that query to a table every 5 minutes (or less if you want)