:Hmm, interesting. Do you have a 3C905B kicking around there somewhere
:that you could repeat the profiling run with? I must admit I hadn't had
:a chance to look at a profile dump using fxp, and this comes as a bit of
:a surprise.
I have two but they are both on slow machines (read: can'
> :That's interesting then, since your results are somewhat at odds with
> :what I've seen so far regarding interrupt load for network traffic. Do
> :you have any profiling results that point the finger more directly at
> :anything?
> :
> :--
>
> Ok, here is the kernel gprof output for o
>
> :< 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.
>
> No serious NFS traffic handlin
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
:< 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.
:
:-GAWollman
:
:--
:Garrett A. Wollman | O Siem / We
...
> (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 so
< 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.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all fami
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 i
>
> 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
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
> :bandwid
: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
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
>
>
> 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.
> >
> > Ther
+[ 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 i
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 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:
> : 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?
>
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
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
> : 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 c
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 wi
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
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 am
:
:
:>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 diff
>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
>m
>
> > 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
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]>, Nate Williams writes:
>> 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
Nate Williams wrote:
> > 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
> 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 wei
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 t
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 m
:
:>
:> 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 assumpti
>
> 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!
> >:
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 anoth
:>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 "lets assume the time of day is a random number" o
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 vers
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 structur
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 anythin
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 tha
: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 re
:
:
: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 th
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
: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
:
44 matches
Mail list logo
