cancel
Showing results for 
Search instead for 
Did you mean: 

FC over IP ?

Harald Doevenspeck
Occasional Contributor

FC over IP ?

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.
5 REPLIES
Michael Steele_2
Honored Contributor

Re: FC over IP ?

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.
Support Fatherhood - Stop Family Law
Duncan Edmonstone
Honored Contributor

Re: FC over IP ?

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

HTH

Duncan
Duncan Edmonstone
Honored Contributor

Re: FC over IP ?

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

HTH

Duncan
Michael Steele_2
Honored Contributor

Re: FC over IP ?

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!
Support Fatherhood - Stop Family Law
rick jones
Honored Contributor

Re: FC over IP ?

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.
there is no rest for the wicked yet the virtuous have no pillows