What kind of workload are you running. If you are you doing these measurements with some sort of "write as fast as possible" microbenchmark, once the 4 GB of nvram is full, you will be limited by backend performance (FC disks and their interconnect) rather than the host / controller bus.

Since, best case, 4 gbit FC can transfer 4 GBytes of data in about 10 seconds, you will fill it up, even with the backend writing out data as fast as it can, in about 20 seconds. Once the nvram is full, you will only see the backend (e.g. 2 Gbit) rate.

The reason these controller buffers are useful with real applications is that they smooth the bursts of writes that real applications tend to generate, thus reducing the latency of those writes and improving performance. They will then "catch up" during periods when few writes are being issued. But a typical microbenchmark that pumps out a steady stream of writes won't see this benefit.

Drew Wilson

Asif Iqbal wrote:
On Nov 20, 2007 7:01 AM, Chad Mynhier <[EMAIL PROTECTED]> wrote:
  
On 11/20/07, Asif Iqbal <[EMAIL PROTECTED]> wrote:
    
On Nov 19, 2007 1:43 AM, Louwtjie Burger <[EMAIL PROTECTED]> wrote:
      
On Nov 17, 2007 9:40 PM, Asif Iqbal <[EMAIL PROTECTED]> wrote:
        
(Including storage-discuss)

I have 6 6140s with 96 disks. Out of which 64 of them are Seagate
ST3300007FC (300GB - 10000 RPM FC-AL)
          
Those disks are 2Gb disks, so the tray will operate at 2Gb.

        
That is still 256MB/s . I am getting about 194MB/s
      
2Gb fibre channel is going to max out at a data transmission rate
    

But I am running 4GB fiber channels with 4GB NVRAM on a 6 tray of
300GB FC 10K rpm (2Gb/s) disks

So I should get "a lot" more than ~ 200MB/s. Shouldn't I?


  
around 200MB/s rather than the 256MB/s that you'd expect.  Fibre
channel uses an 8-bit/10-bit encoding, so it transmits 8-bits of data
in 10 bits on the wire.  So while 256MB/s is being transmitted on the
connection itself, only 200MB/s of that is the data that you're
transmitting.

Chad Mynhier

    



  

_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to