Quote:
Well, it has been a long time since I had to do these calculations. The limits are published by IEEE (assuming point-to-point in this discussion) - I would have to Google for the numbers.
---------- Post updated at 18:14 ---------- Previous update was at 18:03 ----------
Also, I forgot to mention that the theoretical maximum for point-to-point Ethernet (assuming no other network devices talking on the channel), is different, of course, than the practical maximum based on things like "length of cable run", "crimps in the cable" , "connector losses", etc.
I once was on a site where the entire performance of the network management system was terrible and the problem was a crimped cable (I think someone rolled their chair across it in the data center, LOL)
That is why I advise to focus on the network channel(s) when you are debugging performance issues on distributed applications.
If you really want to get into the weeds, the theoretical max bandwidth utilization of an unswitched Ethernet network is 32% of the nominal rate. The key word is "unswitched".
Once you throw switching into the equation, it's a lot easier to get higher rates. I can sustain 90+ megabytes/sec on a gigE point-to-point link, as long as it's dedicated traffic. Now, it takes newer hardware to do that as even a not-too-old IBM x305 that I've used as a WAN emulator (
WANEM : The Wide Area Network Emulator) starts falling behind at about 30 or 40 megabytes/sec. And that's a bit newer albeit smaller box than the Fujitsu PrimePower that's the subject of this discussion.
Also, what are the NFS settings? The NFS version? What are the TCP send and receive hiwat settings? Jumbo frames?
Is direct IO enabled?
What is the exact version of Solaris 9? I'd suspect it needs to be as recent as possible.
Also, was the IO utilization of the older fiber channel configuration ever measured? That'd be nice to know in order to solve this problem.
Knowing the IO utilization now would be good, too. If it's moving 3.8 gbps NOW over NFS, it'd be hard to go much faster than that.