• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About berndl

  • Rank
  1. Considering that the driver comes with the controller, I think this is a rather silly point, no offence. Why bother splitting this hair? In all practicality you have to buy a controller that supports TCQ. Besides SR, notes that the differences between the S150 TX4 and the TX4200 lie only in the firmware realms. This implies to me that NCQ can be enabled in firmware/drivers as well. As for you performance concerns I think they are unwarranted. 1. ATA TCQ uses DMA to return the answered requests, just like NCQ, the CPU utilization isn't going to be different. 2. If you're taking issue with managing the registers for the commands and tags, or the overhead of the actual tagging I don't think there is enough information available to distinguish between the ATA TCQ and NCQ. Is your concern that ATA TCQ implementations use main memory space for the registers to store the commands instead of registers on the controller? I think it is likely that the implementation of NCQ on the TX4200 is just as 'software' an implementation of TCQ as ATA TCQ is on the same controller. I still disagree! Again, TCQ is a matter of drives supporting it and a TCQ capable driver. NCQ requires a NCQ capable drive (basically a TCQ capable drive), a NCQ capable controller, and a NCQ capable driver. TCQ does not use DMA to inform the host CPU about a served request, its a task of the host CPU (polling). NCQ is much smarter, since you just load a bunch of commands into the controller (to be precise: the host memory, a command chain) and wait for completion (indicated by an interrupt). You can entirely offload the processing of the command chain, in difference to TCQ where the host CPU has to find out, which request can be served, then arm the DMA engine of the controller. just my 2 cents... - berndl
  2. I started reading your article and after a few lines I have to disagree! TCQ (the 'parallel ATA tagged command queueing') does _not_ need a special controller! It requires a TCQ capable hard disc and a TCQ capable (SW) driver. That's a very big difference to NCQ (Sata native command queueing). Here the drive and the controller interact without SW-assistance. With NCQ you can start a bunch of DMAs (with different address and length) and the Controller and the Drive will serve this request until completion and a raised interrupt. With TCQ you can issue several Read/Write commands to the drive and, when the drive completed one request, you can 'arm' the Controller with the corresponding address and length. The CPU still has to do something for each of the issued commands. That's my understanding and in my opinion the biggest advantage of NCQ! Correct me if I'm wrong... - berndl
  3. berndl

    Sata Raid, Tcq, Etc.

    Well, thanks God that I don't use Windows ) I just don't want to intermix HW and SW issues, TCQ is really just a matter of SW/driver capabilities (and obviously the drive), wheras NCQ requires a special HD controller. As usual the HW guys are faster than the SW guys.... - berndl
  4. berndl

    Sata Raid, Tcq, Etc.

    AFAIK (parallel) ATA tagged command queueing is just a matter of 1.) SW drivers and 2.) hard disc capabilities. The drive can handle a number of commands in parallel, the SW has to poll the drive to get the information which outstanding request is currently served. The hard disc controller has nothing special to do, just serve the commands as usual. SATA native command queueing is basically the same for the hard disc, but it's very different from a SW and HD controller point of view. The controller and the drive exchange informations, which command is currently completed. The controller maintains a list of outstanding commands and starts the data transfer without CPU intervention. This completely offloads the processing from the CPU, which is just waiting for an interrupt when all requests are processed. AFAIK the Marvell HBAs and the Seagate drives are the only HW which support SATA native command queueing. I don't know about driver support... ATA tagged command queueing is supported by some IBM drives (don't know about the Hitachis). Any controller can do this, it just depends on the SW. hth, - berndl
  5. That's not 100% correct! The lane (one LVDS pair for transmit and one for receive) runs with a max. frequency of 1.25GHz. Since the 10 bit code is a NRZ (non return to zero) code, the max. freq. is half of the max. bandwidth, in this case 2.5GBit/sec. The 10 bit character (not packet, a packet can be several kilobytes long) does not consist of 8 bit data and 2 bit crc. The 8 bit data is encoded into a 10 bit scheme, 256 possible values are mapped into 1024. The reason for this is, that only the 10 bit patterns with frequent phase changes (0 to 1 or 1 to 0 sequences) are used to enable a reliable clock recovery in the receiver. About a dozen or so additional characters are used for 'management purposes', so called control characters (i.e. start of frame, ALIGN, HOLD, ...). Besides this not only the 256 data characters are used, but also their inverse value. This is to keep the 'DC-charge' on the lines balanced. -berndl
  6. berndl

    Sata To Pata Drive Converter

    have a look at the Marvell website. They definitely have a converter from sata to pata but i'm not sure if they sell it to the mass... Their 88i8030 bridge chip can do both, sata2pata and pata2sata... good luck, - berndl
  7. Hi, sorry, I do not agree. The parallel-ATA tagged command queueing requires support from the hard disc, the rest is just software (driver). The controller does really nothing! The driver-SW has to poll the drive to find out which of the queued commands can be serviced. A total different thing is SATA native command queueing. Here the controller-hardware plays an active role because the controller-HW maintains the tables and status bits required for NCQ (i.e. the descriptor tables for the queued DMAs). As stated above there are currently at least two controller families which support NCQ: Silicon Image (i.e. 3512, not the popular 3112) and Marvell (not the 88i8030 bridge!). From the HD side I don't know whether Seagate has all SATA drives with NCQ or just a few or none... just my 2 cents, - berndl
  8. 'opencores' has a source of some ATA controllers, max. functionality is multiword dma! The disc i/f is a different thing... I had the same problem 2 1/2 years ago and ended up writing an own verilog hard disc model. It isn't to much work, PIO and MWDMA are simple. UDMA is a little bit more tricky since the ATA spec isn't very precise (well it's precise but it's very hard to read/understand). You may try to get something from the hardisc vendors, but I guess you'll have to write your own... - berndl PS: Before you ask, I've left the company where I did this work and don't have access to the model anymore (
  9. berndl

    are LSI scsi cards any good?

    afaik, it is the same. The other intel raid controllers are based on their collaboration with icp vortex. The new ones seem to be based on their collaboration with lsi. just my 0.02 EUR
  10. Hi, you're right, the Raptors are PATA with converters. This means, they _might_ support the so-called ATA command queueing. This, if supported by the drive, is just a software thing (and no OS does it afaik). The only PATA drives up to now which could do this were the/some IBM drives. A very different thing is 'SATA native command queueing'. This requires add'l HW in your SATA controller (i.e. the new SiI3512, not the 3112). The only drive I know about support on this is the Seagate since it has a dedicated chip that handles the SATA to disc electronics stuff. All other drives I have seen are PATA drives with integrated converter (and a speedup to 150MB/sec). - berndl
  11. berndl

    quick reminder of why we come here

    Okay, I guess I spoke too soon then I'd say that it is deceptive to include the 2 bit error correction in the maximum transfer rate, even though it is technically true. Not really. I have never seen the 187.5MB/s number quoted anywhere. It is always 150MB/s when dealing with MB/s which is what is used on spec sheets. The only time the 1.5Gbps number is quoted is for interface throughput which is accurate. When describing drive throughput, the 150MB/s number is used. Hi, SATA transfers data with 1.5GBit/sec, your 8-bit data is encoded into 10 bits, giving you 1.5GBit/10 = 150MByte/sec transfer rate. From the drives cache you can now transfer DMA data with this max. speed, one DMA frame can have up to 8KByte of data (plus frame header plus CRC). All in all a good utilization, much more efficient than i.e. TCP/IP over 1GBit/sec ethernet. The reason for the 8bit to 10bit encoding is 'clock recovery' in the receivers. Picking 256 data characters out of 1024 possible allows you to a.) use 10bit patterns with lots of alternating zeros and ones and b.) allows you to use a 10bit pattern and its negated value (to keep the DC charge on the line small). Besides this you also need some 10bit control characters (K characters) for alignment on the bitstream. This 8bit/10bit transmission technique is used for fibre-channel as well... regards, - berndl
  12. Well, you need a bunch of ground pins for return-current! The ground pins are the longer ones (as stated before), the power pins are the shorter ones. But, you're right, the Raptor is a straight forward PATA drive, the Marvell chip just does the PATA-SATA conversion. The Raptor is fast, no question. But it is optimized for access time (with its small platters spinning at 10k rpm). I guess that each state-of-the-art IDE drive has an equal bandwidth (d.t. its higher bit-density). So you will end up with about 60-70MB/sec sustained bandwidth, comparable to the high-end SCSI drives, but still have a better access time (otoh you'll have only a fraction of the capacity of modern IDEs). In my opinion it's just a new design-point for IDE-drives. Since WD has no established SCSI business thats a new idea. Time will tell if it's successfull... - BerndL