We've solved most of the performance issues, but NFS is still
eating a little too much cpu for my tastes. Unfortunately it is getting to
the point where a significant portion of the performance loss is occuring
in the network driver itself. Some of my cards eat 25% of the
On Wed, 15 Dec 1999, Matthew Dillon wrote:
Here's a general update on this bug report to -current. It took all day
but I was finally able to reproduce Andrew's bug.
You guys are going to *love* this.
NFS uses the kernel 'boottime' structure to generate its version id.
On Fri, 17 Dec 1999 00:55:26 -0800, Mike Smith [EMAIL PROTECTED] said:
the IP and UDP checksum guessing, but more that I think you'll find that
a considerable amount of the inbound NFS traffic handling is actually
performed in the interrupt context
If it is, then there is a serious bug.
...
(200-300 MHz) clients. That's *with* packet loss (for some reason when
my fxp ethernets pump data out that quickly they tend to cause packet
loss in other parts of my HUBed network, which I find quite annoying).
Interesting you should say that I've been playing with some
:On Fri, 17 Dec 1999 00:55:26 -0800, Mike Smith [EMAIL PROTECTED] said:
:
: the IP and UDP checksum guessing, but more that I think you'll find that
: a considerable amount of the inbound NFS traffic handling is actually
: performed in the interrupt context
:
:If it is, then there is a serious
Kenneth D. Merry writes:
Another advantage with gigabit ethernet is that if you can do jumbo frames,
you can fit an entire 8K NFS packet in one frame.
I'd like to see NFS numbers from two 21264 Alphas with GigE cards, zero
copy, checksum offloading and a big striped array on one
:On Fri, 17 Dec 1999 00:55:26 -0800, Mike Smith [EMAIL PROTECTED] said:
:
: the IP and UDP checksum guessing, but more that I think you'll find that
: a considerable amount of the inbound NFS traffic handling is actually
: performed in the interrupt context
:
:If it is, then there is a
:
:
: In message [EMAIL PROTECTED], Matthew Dillon writes:
:
: :NFS uses the kernel 'boottime' structure to generate its version id.
: :Now normally you might believe that this structure, once set, will
: :never change. The authors of NFS certainly make that assumption!
: :
: :Is
In message [EMAIL PROTECTED], Kevin Day writes:
Ack, I was using this very same thing for several devices in an isolated
peer-to-peer network to decide who the 'master' was. (Whoever had been up
longest knew more about the state of the network) Having this change could
cause weirdness for me
Matthew Dillon writes:
And so Andrews bug report comes into the light! His poor client
(and mine once I reproduced the bug) got into a state, due to the
server returning a different version id for virtually every packet,
where it resent the same write data over the
In message [EMAIL PROTECTED], Kevin Day writes:
Ack, I was using this very same thing for several devices in an isolated
peer-to-peer network to decide who the 'master' was. (Whoever had been up
longest knew more about the state of the network) Having this change could
cause weirdness for
Matt, you are a tenacious, fearsome bug hunter!
Matt
Matthew Dillon wrote:
Here's a general update on this bug report to -current. It took all day
but I was finally able to reproduce Andrew's bug.
You guys are going to *love* this.
NFS uses the kernel 'boottime'
In message [EMAIL PROTECTED], Kevin Day writes:
Ack, I was using this very same thing for several devices in an isolated
peer-to-peer network to decide who the 'master' was. (Whoever had been up
longest knew more about the state of the network) Having this change could
cause
Yeah, uptime is moving which makes it difficult for me too. When new
machines enter the network, they need to announce a number which is used to
decice who will become the master if the current master disappears. I could
just announce currenttime-uptime, but that's got a slightly different
:
:
:Yeah, uptime is moving which makes it difficult for me too. When new
:machines enter the network, they need to announce a number which is used to
:decice who will become the master if the current master disappears. I could
:just announce currenttime-uptime, but that's got a slightly
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: If people do a "settimeofday" we change the boot time since the
: amount of time we've been up *IS* known for sure, whereas the boottime
: is only an estimate.
There is one problem with this. The amount of uptime isn't the same
as the
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: If people do a "settimeofday" we change the boot time since the
: amount of time we've been up *IS* known for sure, whereas the boottime
: is only an estimate.
There is one problem with
: If people do a "settimeofday" we change the boot time since the
: amount of time we've been up *IS* known for sure, whereas the boottime
: is only an estimate.
There is one problem with this. The amount of uptime isn't the same
as the amount of time since the machine booted. How can
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: Well, I don't think anybody has seriously thought about what the right
: semantics for APM is, and consequently the code we have is rather evil.
Don't know if I'd go so far as to say evil, but there are some pola
issues.
: What to do is a
On Thu, 16 Dec 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] Tom Bartol
writes:
: IIRC it does update uptime properly after a suspend in 2.2.8 but does not
: do so in 3.X and -current on my ThinkPad 770.
define correctly. Eg, if I suspend for an hour it adds an hour?
Warner
In message [EMAIL PROTECTED] Tom Bartol
writes:
: I tried 3.0-current after this merge, suspend and resume worked fine on my
: 770 with the exception of uptime.
I can confirm that uptime, at least as reported by uptime(1), isn't
increased in the latest -current.
Warner
To Unsubscribe: send
On Thu, 16 Dec 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] Tom Bartol
writes:
: I tried 3.0-current after this merge, suspend and resume worked fine on my
: 770 with the exception of uptime.
I can confirm that uptime, at least as reported by uptime(1), isn't
increased in the
+[ Warner Losh ]-
|
| There is one problem with this. The amount of uptime isn't the same
| as the amount of time since the machine booted. How can this happen?
| When a laptop suspends, it doesn't update the update while it is
| asleep, nor does
On Thu, 16 Dec 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: If people do a "settimeofday" we change the boot time since the
: amount of time we've been up *IS* known for sure, whereas the boottime
: is only an estimate.
There is one problem
Matthew Dillon writes:
We're already testing a patch.
Thanks again Matt!
The latest rev of nfs_serv.c has fixed it.
I'm now seeing FreeBSD UDP client read bandwidth of 9.2MB/sec write
bandwidth of 10.9MB/sec. Solaris clients are writing over TCP at
10.1MB/sec (and that is across a
:Matthew Dillon writes:
:
: We're already testing a patch.
:
:Thanks again Matt!
:
:The latest rev of nfs_serv.c has fixed it.
:
:I'm now seeing FreeBSD UDP client read bandwidth of 9.2MB/sec write
:bandwidth of 10.9MB/sec. Solaris clients are writing over TCP at
:10.1MB/sec (and that
On Thu, Dec 16, 1999 at 19:28:34 -0800, Matthew Dillon wrote:
:Matthew Dillon writes:
:
: We're already testing a patch.
:
:Thanks again Matt!
:
:The latest rev of nfs_serv.c has fixed it.
:
:I'm now seeing FreeBSD UDP client read bandwidth of 9.2MB/sec write
:bandwidth of
:However, I'm seeing a showstopping problem when running newer kernels:
:When writing a large file via TCP, a Solaris 2.7 client pauses when
:closing the file, and appears to become stuck in an infinate loop.
:Eg:
:
:dd if=/dev/zero of=zot bs=64k count=8192
:8192+0 records in
:8192+0 records out
Matthew Dillon writes:
This is very odd. Does it lockup with UDP or only with TCP? And only
with a solaris client?
This appears to be solaris only. I just tried a UDP mount I see the
same problem. Is there anything else I can do?
...
:
:- UDP NFS write performance from
:
:
:Matthew Dillon writes:
: This is very odd. Does it lockup with UDP or only with TCP? And only
: with a solaris client?
:
:This appears to be solaris only. I just tried a UDP mount I see the
:same problem. Is there anything else I can do?
Yes, see if you can repeat the
:Also, while read performance has improved by 44%, write performance
:has degraded by between 50 - 70% (FreeBSD clients)! Here are some
:quick benchmarks. Note that the file size of 512MB is larger than
:memory on both the server and client. Also note that the disk array
:on the server will
Matthew Dillon writes:
:Also, while read performance has improved by 44%, write performance
:has degraded by between 50 - 70% (FreeBSD clients)! Here are some
:quick benchmarks. Note that the file size of 512MB is larger than
:memory on both the server and client. Also note that
Matthew Dillon writes:
:
:
:Matthew Dillon writes:
: This is very odd. Does it lockup with UDP or only with TCP? And only
: with a solaris client?
:
:This appears to be solaris only. I just tried a UDP mount I see the
:same problem. Is there anything else I
Here's a general update on this bug report to -current. It took all day
but I was finally able to reproduce Andrew's bug.
You guys are going to *love* this.
NFS uses the kernel 'boottime' structure to generate its version id.
Now normally you might believe that this
In message [EMAIL PROTECTED], Matthew Dillon writes:
Here's a general update on this bug report to -current. It took all day
but I was finally able to reproduce Andrew's bug.
You guys are going to *love* this.
NFS uses the kernel 'boottime' structure to generate its version id.
In message [EMAIL PROTECTED], Matthew Dillon writes:
:NFS uses the kernel 'boottime' structure to generate its version id.
:Now normally you might believe that this structure, once set, will
:never change. The authors of NFS certainly make that assumption!
:
:Is this another case of
In message [EMAIL PROTECTED], Matthew Dillon writes:
:NFS uses the kernel 'boottime' structure to generate its version id.
:Now normally you might believe that this structure, once set, will
:never change. The authors of NFS certainly make that assumption!
:
:Is this
37 matches
Mail list logo
