• Content Count

  • Joined

  • Last visited

Everything posted by mejv

  1. mejv

    What Is Sas?

    Hi balding_ape, You wrote : ==================================================== "WRT your comments on transfer rate performance: 3 gigabytes per second would have been no larger a performance jump than 300 megabytes per second, because it is purely a "maximum" value. Only one drive is on each "channel" (from what I understand), so until drives themselves exceed 300 MB/s in transfer rate, there will be no difference between SAS1 and 3GB/s." ==================================================== I just wanted to comment about no difference between 3 GigaBytes (GB) per second (note that SAS1 is 3 Gigabits (Gb) per seconds) and 300 MB/s. SAS was not developped to be used with 1 disk, but to be able to connect multiple devices via an expander (kind of switch). Therefore, an initiator connected to an expander could have many devices transfering at the same time... As noted, 15 K rpm disks can transfer at a max of 80 MB/s and a min of ~50 MB/s (sequantial) Imagine a server with 64 devices transfering at the same time, the link would be saturated very fast. If the link was at 3 GB instead of 3 Gb, or ~10 times faster, the limit would be lifted by that much or so... But for a home use, 320 MB./s SCSI or 3Gb SAS would not make much difference with a couple of drives hooked up... MEJV
  2. mejv

    What Is Sas?

    Due to issues of transmitting bits in parallele, the serial approach was a no brainer. SAS 1 is at 3 Giga bits per second. (or 300 MegaBytes per second). It is full duplexed dual port : can transmit AND receive data at full speed at the same time (parallele SCSI allows you to transmit OR receive on the bus at any time) Next generation is palnned to be at 6 Gb/s (600 MB/s) MEJV
  3. mejv

    Scsi Help

    Hi shep9999 ! You need to check : 1) termination : each end of the cable should be terminater properly. (If you do not have a terminator at the end of the cable, a device with termination enabled would be OK. No other device in the middle should have termination enabled) Also, the cable should not be longuer than 3 meters (~10 feet) 2) SCSI IDs : as you have 5 devices, you should check for SCSI jumper settings... SCSI IDs should be set between 0 and 6, assuming that the HBA uses SCSI ID 7 Each device should have a unique SCSI ID on the bus... 3) Good luck ! MEJV
  4. Hello all... I saw that Frys has an 8x DVD+-R(w) on sale for $79.99+tax... Emprex is the 'brand' name... Did anyone hear about this brand, or use it ? Does it even works ? It sounds too good to be true... What do you think ? MEJV
  5. Of the 2 thingy on the photo at the beginning, the one close to the actuator is a locking mecanism : to lock the arm when the platters are not spinning. The principle is simple : the air flow pushes the thingy, freeing the arm. The other thingy might be a head ramp to park the heads off the media... It allow for cheaper media (untextured landing zone)... MEJV
  6. gbb123, I'll have a shot at it... I assume that the test (random writes/reads) is long enough to fill up the cache of the Raid board (write-back case). Then the raid has to manage to get the data off the cache (to the disks) to make room for the new data coming in. The Raid cache acts then as a buffer, and the RAID controller has to manage getting the data to the disks the best it can... In case of write through, the raid controller has no choice but finishing the command only after it has been written to the disks, therefore, the raid cache algorythm used does not matter... but the speed of the driver/hardware does... The idea behind the cache on the Raid board is that they assume in real life situation the data would not come in as random and over a long periode of time... like IOMETER does. The faster the processor onboard a Raid card, the more memory and the more efficient design would have an effect on the performance ! MEJV
  7. mejv

    Removable Storage

    Because of the wear of the mecanical parts... It is an indication, not a garanty... MEJV
  8. In simle terms : write-back is faster than write through. The reason being that the write data is written to the cache of the raid card. The OS thinks it has been written to the disk, but the disk is getting the data once the raid card decides it is time to do it. This is why it is somewhat dangerous in case of power get removed, whatever is in the cache and did not get written to the disks is lost... Hope this helps... MEJV
  9. mejv

    How Do I Identify My Mainboard?

    An add-on ide card on the PCI bus should do the trick... MEJV
  10. Did you load the XP driver before installing the raid card ? If not, boot the old way and install new hardware, then install the card still booting the old way, after that, you can try to boot (if boot is suported by the raid card) with the raid card... Is this card supported by XP (check the microsoft web site). Just a few thoughts... MEJV
  11. mejv

    Maxtor Atlas 15k

    ============================ MaxtorSCSI Posted on Feb 27 2004, 04:47 PM QUOTE (mejv @ Feb 26 2004, 08:05 PM) Correct me if I am wrong, but I thought that on a SCSI bus like on a Fibre Channel link, when only a single Initiator and a single Target were connected, the initiator goes to a 'point-to-point' mode to optimize the use of the bus... Nope. SCSI and FCAL are "network" protocols. They both support "hot plug", you are able to add/remove devices from the network arbitrarily. Neither protocol can assume they have exclusive access to the network. ============================ I know for a fact that a Fibre Channel HBA (device driver) could decide to not send all the loop primitive once it discovers that only one target is out there, in order to improve the speed. If another device is connected, the link would be disrupted by a LIP (Loop Init) in order to force a discovery of the device on the link. If more than one device shows up, the HBA (device driver) would go to loop and arbitration associated with that state. I was under the impression that a SCSI HBA could behave the same way since the disruption of a new device on a SCSI bus would ne noticed at the hardware level and trigger a bus reset to 'discover' the devices on the bus... MEJV
  12. mejv

    Maxtor Atlas 15k

    MaxtorSCSI, You wrote "SCSI is a protocol in the truest sense of the word. To exchange data on a SCSI bus, the host and drive need to arbitrate for access to the bus (even when they're the only devices on the bus, that arbitration still occurs). " Correct me if I am wrong, but I thought that on a SCSI bus like on a Fibre Channel link, when only a single Initiator and a single Target were connected, the initiator goes to a 'point-to-point' mode to optimize the use of the bus... MEJV
  13. mejv

    Slow Scsi Performance

    gaviota, Check also the computer setup : PCI Latency clock... Recommanded values are between 32 and 64... Good luck, MEJV
  14. What do you exect from people paid $5/hour required to be able to read the FAQ and tryinf to match your question with some known problems... Anything besides that, they are lost... You need to get an experience tech support... These are not as cheap but there are not as many... that's why you don't get one when you call. MEJV
  15. mejv

    Should I Change To Sata From U320?

    twnichols, I do not know how the adaptec 320 setup is, but I would think it is similar to the 160 I have... The Synchronous should be selected, as well as wide, packetize, and 320 as speed... Make sure termination is auto and enabled... I would think you are familiar enough with the menu to find these options... Good luck ! MEJV
  16. I downloaded HDtach 2.70 yesterday... I remember seing that as a warning or so while installing or before downloading... They said it is only with w2k/XP and V3.00 will fix it... MEJV
  17. mejv

    My First Computer

    I started playing games on an APPLE III. 128KB, 5-1/4 inch floppy I think and an APPLE II emulation to play the games... MEJV
  18. Sorry Gribo. I was under the impression that you were getting confused when people are talking physical link or physical interface and logical interface... MEJV
  19. Gilbo. It has been many years since the firmware on a disk drive is locked up in a ROM... Firmware updates are available to restricted people to prevent massive RMAs due to improper updates done by end users. Since disk drives are manufactured by millions, if a significant problem that requires firmware update is discovered, the customer if the disk drive need to be able to update them at low cost. If they had to return the drives and wait for updated ones, a lot of money would be involved. This sound like a logical business thing to have... Also, since the Compaq, HP, Dell ... want certain features specific to them, there is a way to configure the firmware to enable/disable these... Like that a 'generic' (@ Frys, Computer City, CompUSA...) drive could be turned into a CompaQ, HP, Dell ... in a flash! Quantum used to have an FTP site where some firmware update were available... mostly for developpers like Adaptec, LSI... As for the TCQ, both disk firmware and controller driver/firmware would have to be modified... The physical link could care less... MEJV
  20. Well, that sounds logical but since the drive knows where the heads are located by reading the sector number, assuming these LBA 1000, 2000, and 1500 are on the same track, it can figure which one is the first coming up... it could be that 1500 and 2000 are coming up when 1000 already past. If they were located on 2 tracks either next to each other or on a different head, the firmware would calculate if there is enough time to switch head and access any one of them and back in the fastest order... Therefore your assumption is oversimplified. MEJV
  21. Sorry if I don't spend the time reading the lengthy posts, but I react when I read that the drive is not the one throtling the data coming from the host... for example... As far as I know, the disk can refuse commands by having a busy signal returned to the host, or simply by not requesting more data from the host (in case of writes). In case of reads, the disk is still the one delivering data as fast as it can, and under normal conditions, it won't fill its buffer. Another detail... "...OS does know that adjcacent sectors are adjacent and that the closer sectors are closer... Sectors are physically located on a disk platter, LBAs = Logical Blocks Address are what it says, logical. The OS deals with LBAs or blocks for short, a SCSI disk would translate that into physical location and would calculate the optimum way to write/read the data... with or without caching (since XP/2k SPx don't allow disk cache writes any more for what I gathered.) with minimum head movment. MEJV
  22. Gilbo, You seem to claim that the OS knows as well as the disk how to reorder the commands ... I don't think the OS knows where sectors are on the disk and how long it would take for the heads to get there. Yes it tries to optimize the commands, but the final say is done at the drive level. MEJV
  23. Gilbo, 1) a disk buffer can be used for buffering data before sending it on the bus in reads 2) a disk buffer is used for caching data for reads and writes. 3) the disk buffer is segmented however the firmware algorythm wants to buffer/cache data and all of the available buffer could be used for caching data in case of long sequential writes. And yes, the whole available buffer could be filled with data no yet written to the disk, and at 320 MB/s it could be on more than one od today's SCSI disk. Not that it happens very often, but it could. When I say the whole available buffer I mean whatever portion NOT used by the firmware to store its internal variables/data structures/code... 4) TCQ and packetize SCSI are 2 different things that work together on SCSI 320. The tag allows the host (=HBA=initiator controlled by the HBA driver) and the disk to act on a specific command at the discretion of the disk. The disk receives commands and a write command could be for 10000 blocks of 512 bytes = 5120000 bytes = 5Millions Bytes. These size of transfer would not be done in one packet transfer, but in multiple chunks, and the disk is the one controlling when to get the data, not the host (=HBA=initiator). The host is only telling the disk that it has this much data to get. There could be 64 or 256 similar write commands sent to a disk with a different tag (depending of the queue depth supported by the disk). The disk would be managing the requests on the bus according to its queing algorythm : minimize the movement of the heads. The way the data comes in (packets or not) does not matter much on the tag queing. The OS might have its way of ordereing the commands it wants, but it does not know how the disk layout is done, therefore the disk is the one doing the reordering of the commands it receives... 5) Fairness algorythm on the bus with multiple devices is meant to prevent starvation of a device if another would always be faster to grab the bus when it becomes free. I just thought I'd clarify that for you since you don't seem to fully understand fully the whole thing. MEJV
  24. Gilbo, You wrote : " In fact they won't ever fill their buffers unless there is some sort of strange bus contention occuring. The arbitration between the devices on the chain is conducted in such way as to prevent that very phenomenon because, of course, it would be detrimental to performance;" You claim that a drive would not ever fill their buffer... How would you know that ? If you have a single drive on the SCSI bus, and a it is sent 300 MB of data and the best drive today would be able to sustain write to the disk at 75MB/s the drive would have to cache as much as possible. But after a few moments, the drive would receive data faster than it can write and would have no option but to keep its whole buffer available filled to the max. The caching algorythm might or might not make use of the whole buffer available, but it is besides the point. Once the drive buffer reserved for the write caching is full, the drive would throttle the data coming in somehow... Otherwise the host (initiator) would keep sending data... In case of multiple disks write, the host would distribute data to the disks using the Tag Command Queing : send the command to the disks and disconnect, let each disk request data for the commands received. The fairness algorythm would prevent a single disk to have the priority for getting data... I am not sure about what you mean by "unless there is some sort of strange bus contention occuring"... MEJV
  25. Well, On the SCSI bus, or on any bus for that matter, the data transfer is done to one device at a time at a given moment. That said, in the same second, 15 devices could receive/send data. This is because each device send/receive data of a small size (512 bytes to 64 Kbytes). at 320 MB/s, this take a very small amount of time. Therefore, each device can get some data in the same second, but not at the same instant... Now, let's say you transfer 100 MB to each device on the bus, assuming that all device has the ability to transfer at 320 MB/s on the bus, the data is first stored in the device buffer (cache) and written to the media some time later. A device with 8MB of buffer would be able (in theory) to collect 8 MB in the buffer at 320MB/s so 0.025 second in theory. Real world figure would be much more due to overhead and the fact that the data is sent in chuncks... The buffer (cache) is used to buffer (!) the data to take the least amount of time on the bus, and let other device transfer instead of monopolising the bus for nothing. Hope this helps ! MEJV