As our samples are not retail, and instead OEM, variants we can not comment on the shipping container or accessories that ship with said drives. Quite honestly, we doubt that (m)any buers of a SkyHawk will care one whit what the box looks like our what accessories they come with. Instead, it is all about the sequential write performance.
Moving on. There are two key ingredients that make a SkyHawk hard disk drive series different from the rest of the Guardian models. These are 1) hardware, and 2) software tweaks to the general Guardian blueprint. Let’s start with the software. In the previous page we gave a quick primer on Multi-Tier Caching (MTC) Technology. Think of that primer as the ‘ten-thousand-foot view’ look at this cache + algorithm technology. As we went over in that primer the 256MB of onboard RAM cache is not necessarily treated like a single contiguous chunk of cache. Instead, this RAM can be divided into multiple smaller portions… almost as if the SkyHawk came with multiple small RAM ICs instead of one large IC.
While Seagate is mum on the specifics on how many smaller ‘chunks’ the SkyHawk’s cache has been cut into, based on the fact that it can handle 64 simultaneous HD data streams at the same time. So in all likely hood the MTC cache has been broken up into many, many more smaller chunks than the rest of the series. While we strongly doubt it is a 64-way split, it is enough chunks to basically handle a couple seconds worth of streaming data per channel… with very litter to no RAM cache set aside for read request buffering. Yes, this cache is configured to be nearly entirely write only in nature. Furthermore, it is almost entirely geared towards constant sequential write buffering and ensuring the data is written perfectly to the drive. First time, every time. To whit, the SkyHawk has been optimized to never, ever drop frames even when there are ton of data streams coming in… and consider read requests as figurative second class citizens – and it will get around to it when it has a free cycle or three.
This combination is what Seagate calls ‘Perfect Image’ firmware and these unique priorities is what makes the SkyHawk a master at surveillance storage. How it goes about flushing its cache while still ensuring not a single frame drop also requires some massive tweaking to the stock algorithms. Usually the cache buffer spends most of its time either buffering the occasional (and randomly sized) write requests or buffering the data ahead of a read request. Rarely will a general purpose drive encounter a write request that is so time sensitive as to not be able to wait a cycle or three for a bit of cache flushing (or being written directly to the platters). With the SkyHawk series, these drives’ have to buffer continuous incoming write requests, flush its data, and yet still not miss a single bit of incoming write request data. That is tough.
Once again Seagate is mum on precisely how they do this but in all likelihood the entirety of the 256MB cache buffer is not just chunked up into smaller clusters to handle the data streams, it is also been tweaked to never, ever be entirely filled. Instead, there are most likely low-level trigger events that when a certain percentage of a given cache chunk is filled… and it is flushed to the platters, while still accepting in ‘new’ write data packets. Since all the ‘chunks’ are expected to be continuously filled and emptied, there is most likely a cascading set of triggers. Where chunk 1 is flushed, and just as it is finished its writes, chunk 2 is flushed, etc etc. This creates a very efficient scenario where the R/W heads are constantly writing data to the platters, the arms are constantly moving, and explains the slightly lower power usage – as there is not ‘starts and stops’ instead everything is in continuous movement.
Of course, as there are expected to be many, many unique data streams if it just started at the outer edge of the platter and worked its way in the resulting files would be fragmented to hades and back. Most likely there are other specialized algorithms that virtually cut up the platters into chunks/clusters/zones – with each ‘zone’ holding all the data from a given data stream (or more precisely, chunk of cache). Given the fact that this drive always stays above 110Mb/s even when full the location of these zones impacts real-world performance not one whit. Each data stream will appear to be just as fast as all the rest, but in return for theoretical differences in performance users gain noticeably less write latency – as the arms are almost always pre-positioned in just the right place when they need to be.
To imagine how all this works, imagine 8 data streams coming in, and going to their own chunk of write cache. Maybe the first chunk has a write trigger even of 70 percent, the next 71 percent… and so on and so forth. After a few seconds the first chunk of cache hits its trigger event and the data is first organized into contagious data files per stream, then flushed to the platter while this cache chunk is still receiving new write data (and thus the less than 100 percent trigger event). Just as this data is finished being written, another trigger event occurs, and the arm moves to ‘zone 2’ of the platter. Just as the arm is in position… chunk 2 of the cache hits its own trigger event and is flushed to the platters. Rinse and repeat and you have a drive that is constantly writing to the platters in the most effective and efficient way possible. In reality there is a lot more low-level things going on behind the scenes… but that is the beautiful storage dance of the ‘Surveillance’ variant of MTC and ‘Image Perfect firmware’ in a nutshell.
Of course, the downside to all this is that the drive really does not have much in the way of free cycles for read requests. Most likely a small chunk of the 256MB cache buffer is set aside just for such rare occurrences and when a read request happens the data that would have been written gets shuffled from say chunk 1 of the ram to this chunk X. There probably is also a chunk ‘Z’ where the drive’s controller will also buffer a tiny bit of data located ahead of the read request. That way the drive can get back to emptying its buffer and continuing its low level write dance that was ‘so rudely interrupted by the end-user’ as quickly as possible. So, yes. Read performance will be low (and quickly tank) compared to sequential write performance. Given the fact that the SkyHawk is meant to spend the vast, vast majority of its life just writing data this unusual cache configuration makes it tailor-made for the highly specific, highly demanding requirements that are placed upon it.
That hardware portion of the SkyHawk is actually a lot easier to explain. In a nutshell Seagate took their NAS orientated standard IronWolf platform and modified it for the requirements of the surveillance marketplace. This claim, as Seagate will never give specifics, is backstopped by the fact that the endurance specifications are the same for the SkyHawk and IronWolf series; and is further reinforced by taking a close look at the drive’s PCB.
As you can see there may be a few modifications done to the PCB but it basically is an older gen IronWolf board. The same vibration sensors (with the same firmware backstopping them) and the same general component selection… just with a different form-factor PCB. Even how the SkyHawk is built is very similar to the standard IronWolf series (e.g. both ends of the spindle are attached to reduce vibrations and make for a more robust drive, etc.). This is not a bad thing as the IronWolf is a great series… and an 8 bay drive enclosure is an 8 bay drive enclosure. Be it in a surveillance appliance/server or a NAS appliance/server.
More importantly, this foundation means that the SkyHawk series is PMR/CMR based and not SMR. Specifically it is PMR+ with TDMR (Two-Dimensional Magnetic Recording). Typically, ‘surveillance’ is code-word for slow Shingle Magnetic Recording tech being used. The fact that the SkyHawk series is not SMR and instead uses this cutting edge Parallel / Conventional Magnetic Recording technology means that while read performance will be lower than other Guardian series options, the potential is still there for a rather decent drive. One that will have much more consistent performance potential than SMR based drives. It also places the SkyHawk head and shoulders above average for this corner of the marketplace. Color us impressed.
So what does all this mean? Well, the easiest way to ‘get’ the SkyHawk series, is that in general purpose scenarios think of it as a fairly big, fairly modern hard drive that lacks a large RAM cache buffer. Instead all (or at least most) read I/O requests are almost enviably going to be handled directly by the r/w heads and platters… as for all intents and purposes that is how it will routinely re/act. Rarely will you see it ‘waste’ much space of its precious buffer on things that may be important you and your typical system scenarios.
This is because the SkyHawk’s cache buffer and algorithms have been so highly tuned as to virtually ignore typical home usage, SMB, and even Enterprise demands. It only cares about what would make deep queue depth, sequential write performance better. As such it can brute force its way to reasonably peppy results outside its niche but, just like a master craftsman outside their area of expertise, the overall general-purpose performance it offers will be lower than even older generation multi-purpose models. Models that are not so narrowly focused on what gets stored in their RAM cache buffer. That is the key to understanding what the SkyHawk can and cannot offer potential buyers… AKA “Phenomenal cosmic power, itty bitty living space”. Choose wisely when thinking about these masters and what you plan on using them for.
