FC over IP ?

[Harald Doevenspeck]

We have disks connected to HP-Risc servers over FC (also the root disks). We would like to move some of the storage to another location and we would then like to use FC over IP (only temporary). This will increase the latency of course, even if we make sure the bandwith is sufficient.

So I would like to know what the max. latency is for a FC link between an HPUX server and its disks.

Thanks for your help.

[Michael Steele_2]

Hi

Latentcy. Oh my. This your going to have to test yourself with a big ftp file transfer.

I can show you how to find the link speed of the HBA, which should be 1 or 2 GB/second:

fcmsutil /dev/fc##

And then read down the report to the link speed data field.

Any latentcy formula will be compared to this link speed constant.

##################

Quite frankly, I don't know how you're going to do this though. An HBA doesn't not have the internet protocols to talk to a switch or another NIC, which are going to be at most, 1 GB/second. Thereby nullifying your 2 GB/second HBA, IF, it could talk IN ETHERNET, which it can't.

If there is something out there that allows this HBA to ethernet communication, then please write about it.

Note: A network has many hops and many nodes so your max speed from one server to another via crossover cables will be optimum. But once you connect to a switch and then a router and adding hops, its all going to go down.

[Duncan Edmonstone]

There are no "defined" max latencies that I am aware of, and HP-UX can cope with some pretty horrendous latencies (for example I can mount a DVD in my laptop at home, VPN to work over ADSL and then use iLO vMedia to install HP-UX on an Integrity blade - it works but it's slooooow)

I think I'd just work off what we usually consider as "bad latencies". Any disk access that takes over 10ms ain't so good, and anything over 20ms is _really_ going to suck.

Unlike Windows, HP-UX doesn't have an aggressive paging algorithm so you don't get a lot of disk access related to virtual memory in the same way you do on windows, however you'd also better be pretty damn sure you don't have any page-outs happening (i.e. plenty of free memory), or your system will be pretty much unusable.
HTH

Duncan

[Duncan Edmonstone]

Thinking about this, the other thing to consider is whether the boot console handler will even "see" these remote LUNs when the PA-RISC system trys to boot. The FC code in BCH and in the firmware of the FC cards is pretty basic compared to what you get once the OS is loaded. I've see plenty of cases with more "esoteric" SAN configurations where you could see LUNs from within a booted HP-UX OS, but the boot handler refused to boot off these same LUNs.

I hope you have a way of testing/proving this before you start migrating...

If this is really temporary I'd be tempted to get my hands on some old SCSI HBAs and disks and just do local boot until your migration is completed.

HTH

Duncan

[Michael Steele_2]

Hi Again

Could you provide more information about the application and HW that you are using. This doesn't come up much and I'd like to document it for other forum users.

Thanks in advance!

[rick jones]

From TCP, or any other window-based flow-control protocol we have:

Throughput <= EffectiveWindow/RoundTripTime

When I give this spiel in the context of TCP one of the components of the "EffectiveWindow" I mention is "How much data the sending application is willing to send at one time before waiting for a response from the remote"

In this case, if this magic FC over IP device truly makes things transparant to the FC host (correct term?) then I would think the EffectiveWindow (or Weff) would be the depth of your FC device queue, but I start to get out of my depth here.

Now, there are some disc I/Os that do not allow applications to "fire and forget" - while increasing the HBA's I/O queue can allow one to hit bandwidth with higher latency, and so have bulk read and write rates perhaps remain as before, it won't do anything for metadata lookups and the like - those will probably slow-down in direct proportion to the added latency.

And none of this addresses the latency spike one might get from lost IP datagrams - that will depend heavily on the behaviour of the FC over IP device.