<span class="gmail_quote">On 03/01/2008, <b class="gmail_sendername">Christian Smith</b> <<a href="mailto:csmith@thewrongchristian.org.uk">csmith@thewrongchristian.org.uk</a>> wrote:</span><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Probably not such a good idea. eSATA cable lengths are not great and<br>controller and client are not peers, with the client only responding to<br>commands from the controller (I may be wrong on this.)</blockquote><div><br>
I figured this could be the case. I skimmed the SATA spec, but I couldn't understand it sufficiently to figure out what the implementation could/would have in it.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What you may be thinking of is the encoding of the data over the physical<br>layer is the same, namely 8b/10b encoding used by most new serial<br>interfaces (including PCI-e) now that it's patent has expired.</blockquote>
<div><br>I hadn't thought of that... <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SCSI is inherently multi-master, allowing either end to initiate transfer.
<br>Plus, SCSI of it's day was significantly faster than the equivalent<br>ethernet, so IP over SCSI made sense for high bandwidth, low latency<br>links.<br><br>SATA has less of an advantage over current ethernet, so IP over SATA would
<br>not be worth the effort even if it were possible.</blockquote><div><br>Ok, so my suspicions were correct.<br><br>Thanks,<br><br>Richard<br></div><br></div>