I don't have and pretty charts or graphs to explain this next part, but I will share an observation I made during my fragmentation testing. When running my fragmentation tool, I observe IOPS drop as the drive becomes more and more overloaded with the task of tracking the random writes taking place. Here the JMicron controller behaved like all other drives, but where it differed is what happened after the test was stopped. While most other drives will stick at the lower IOPS value until either sequentially written, TRIMmed, or Secure Erased, the JMicron controller would take the soonest available idle time to quickly and aggressively perform internal garbage collection. I could stop my tool, give the drive a minute or so to catch its breath. Upon restarting the tool, this drive would start right back up at it's pre-fragmented IOPS value.
Because of this super-fast IOPS restoring action, and along with the negligible drop in sequential transfer speeds from a 'clean' to 'dirty' drive, it was impossible to evaluate if this drive properly implemented ATA TRIM. Don't take this as a bad thing, as any drive that can bring itself back to full speed without TRIM is fine by me, even if that 'full speed performance' is not the greatest.
This type of self-healing (i.e. without needing TRIM) is great for those wanting to run a few SSD's behind a RAID, since no RAID implementation is currently capable of passing TRIM from the OS to the arrayed SSD's. Better yet, considering this drive is tailored to the budget crowd who may very well still be running XP or Vista, it's good to have a few choices that don't require TRIM to maintain decent levels or performance.