Michael van Elst | 1 Apr 2010 09:16
Picon

Re: Two SpeedStep issues

denbrok <at> uni-bonn.de writes:

>One is equipped with a Core2Duo E8200. NetBSD reports 800 700 600
>as the frequencies available. I think this should be 2666, 2333
>and 2000 or similar. I don't know whether this makes a practical
>difference, but it irritates me a little.

That's probably correct. The speedstep frequency parameter is
scaled by the bus clock and it is likely that the driver does
not identify this correctly. If you build the kernel with
options EST_DEBUG you will get some information about the
data found.

However, this shouldn't affect how EST works. Configuring
800, 700 or 600 should result in real clock values of 2666,
2333 and 2000 respectively.

>The other one, a ThinkPad R50e, is equipped with a Celeron M 1400.
>I didn't really expect it to have SpeedStep support at all, but
>OpenBSD (in practice) claims to lower its frequency to as low as
>367 MHz, claiming the battery would then last about 6 hours.

Celeron M was used for many different CPUs. What does the
kernel (or cpuctl identify) say? Enhanced SpeedStep is
signaled with the EST flag in the features2 register.

If the there is the EST flag but the est driver doesn't
recognize SpeedStep then it is because the CPU reports
minimum and maximum clocks to be the same. This is
Intels way to say: don't play with it but use the
(Continue reading)

Dennis den Brok | 2 Apr 2010 20:34
Picon

Re: Two SpeedStep issues

Michael van Elst <mlelstv <at> serpens.de> schrieb:
> That's probably correct. The speedstep frequency parameter is
> scaled by the bus clock and it is likely that the driver does
> not identify this correctly. If you build the kernel with
> options EST_DEBUG you will get some information about the
> data found.
>
> However, this shouldn't affect how EST works. Configuring
> 800, 700 or 600 should result in real clock values of 2666,
> 2333 and 2000 respectively.

Hm, it seems something is quite messed up there in
sys/arch/x86/x86. First, on three consequent boots, I got three
different CPU frequencies:

cpu0 at mainbus0 apid 0: Intel 686-class, 2673MHz, id 0x10676
cpu0 at mainbus0 apid 0: Intel 686-class, 3742MHz, id 0x10676
cpu0 at mainbus0 apid 0: Intel 686-class, 3208MHz, id 0x10676

The bus clock is indeed wrong:

est_init_main: bus_clock = 10000

It seems this is because intel_busclock.c does not take the
extmodel into account. My Core2Duo has model #6, which originally
appears to have been some P3, but extmodel #1, which is ignored...
I'm not sure this model# is even correct; wikipedia says it should
be 23!?
Consequently, the rest of the data collected by est_init_main is
interpreted wrongly:
(Continue reading)

Jukka Marin | 2 Apr 2010 22:13
Picon

nfs server performance (netbsd-5)

Hi,

I had to upgrade my file server to netbsd-5 (to be able to run i386PAE
kernels with Xen) and now nfs is acting funny.  First, with only 500 kB/s
load, nfsd is using 10...20% of CPU (2.6 GHz).  Most the of time used is
system time (eg, 19% with 1% interrupt time and 80% idle).  Dom0 is 98-99%
idle.

I never even noticed the load when running NetBSD 4.0 on the same
hardware.

Second, when an NFS client writes to the server (every 1.5 seconds or so),
all other processes pause for a noticeable period of time.  I can see
this while typing this mesasge, for example.

Third, when accessing two different disks on the server, it seems that
accesses to one disk only are being serviced and there is absolutely no
data flowing to or from the other disk.  This is causing serious problems
with real time video and audio recording. :-(

This is how I start nfsd:

nfs_server=YES          nfsd_flags="-t -u -n 16"

I can see only one nfsd process (maybe this is normal; under NetBSD 4.0
I saw 16 processes (or threads)) in top or ps.

The nfs server is a domU with 2048 MB of RAM and the disks are mounted
with softdeps (not brave enough to try out log).

(Continue reading)

Thor Lancelot Simon | 2 Apr 2010 22:27
Picon
Favicon

Re: nfs server performance (netbsd-5)

On Fri, Apr 02, 2010 at 11:13:47PM +0300, Jukka Marin wrote:
>
> The nfs server is a domU with 2048 MB of RAM and the disks are mounted
> with softdeps (not brave enough to try out log).

I don't know about the rest of the issue you're reporting, but I think
you should have to feel a lot more brave to be using softdep at this
point than to use log.

--

-- 
Thor Lancelot Simon	                               tls <at> rek.tjls.com
  "All of my opinions are consistent, but I cannot present them all
   at once."	-Jean-Jacques Rousseau, On The Social Contract

Paul Goyette | 2 Apr 2010 22:32

Re: nfs server performance (netbsd-5)

On Fri, 2 Apr 2010, Thor Lancelot Simon wrote:

> On Fri, Apr 02, 2010 at 11:13:47PM +0300, Jukka Marin wrote:
>>
>> The nfs server is a domU with 2048 MB of RAM and the disks are mounted
>> with softdeps (not brave enough to try out log).
>
> I don't know about the rest of the issue you're reporting, but I think
> you should have to feel a lot more brave to be using softdep at this
> point than to use log.

HeHeHe!

Just as a data point, I'm using 5.99.24 -current on my quad-core amd64 
nfs server with no issues.  I'm serving two file systems (one each on 
two separate drives) with occassional heavy access (one is my NetBSD 
source tree, the other holds my $TOOLDIR, $OBJDIR, and other "outputs" 
from build.sh).  And both fole systems are mounted  with "-o log".

No issues to report, and performance is really pretty good across my 1GB 
Ethernet backbone.

-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

(Continue reading)

Jukka Marin | 5 Apr 2010 11:38
Picon

Re: nfs server performance (netbsd-5)

On Fri, Apr 02, 2010 at 01:32:46PM -0700, Paul Goyette wrote:
> On Fri, 2 Apr 2010, Thor Lancelot Simon wrote:
> 
> >On Fri, Apr 02, 2010 at 11:13:47PM +0300, Jukka Marin wrote:
> >>
> >>The nfs server is a domU with 2048 MB of RAM and the disks are mounted
> >>with softdeps (not brave enough to try out log).
> >
> >I don't know about the rest of the issue you're reporting, but I think
> >you should have to feel a lot more brave to be using softdep at this
> >point than to use log.

I knew someone would comment this. ;-)  Maybe I can find the courage to try
log with the 4.7 TB partition I have.  I'm just afraid of problems with
partitions as large as this.

> Just as a data point, I'm using 5.99.24 -current on my quad-core amd64 
> nfs server with no issues.  I'm serving two file systems (one each on 
> two separate drives) with occassional heavy access (one is my NetBSD 
> source tree, the other holds my $TOOLDIR, $OBJDIR, and other "outputs" 
> from build.sh).  And both fole systems are mounted  with "-o log".
> 
> No issues to report, and performance is really pretty good across my 1GB 
> Ethernet backbone.

I "upgraded" my 4.0 server to netbsd-5 by extracting the tarballs over
the old binaries, so old libraries and stuff were not deleted.  Maybe this
is causing me problems.. is it possible that the new nfsd is using libs
from NetBSD 4.0 and this is causing problems?

(Continue reading)

Jukka Marin | 5 Apr 2010 11:59
Picon

Re: nfs server performance (netbsd-5)

On Mon, Apr 05, 2010 at 12:38:20PM +0300, Jukka Marin wrote:
> I "upgraded" my 4.0 server to netbsd-5 by extracting the tarballs over
> the old binaries, so old libraries and stuff were not deleted.  Maybe this
> is causing me problems.. is it possible that the new nfsd is using libs
> from NetBSD 4.0 and this is causing problems?

What are the RPC errors, reported by nfsstats?  The number is increasing.

RPC errors          faults
     67923               0

  -jm

Michael van Elst | 5 Apr 2010 13:44
Picon

Re: nfs server performance (netbsd-5)

jmarin <at> embedtronics.fi (Jukka Marin) writes:

>On Mon, Apr 05, 2010 at 12:38:20PM +0300, Jukka Marin wrote:
>> I "upgraded" my 4.0 server to netbsd-5 by extracting the tarballs over
>> the old binaries, so old libraries and stuff were not deleted.  Maybe this
>> is causing me problems.. is it possible that the new nfsd is using libs
>> from NetBSD 4.0 and this is causing problems?

>What are the RPC errors, reported by nfsstats?  The number is increasing.

>RPC errors          faults
>     67923               0

Can be almost anything. It just counts RPCs that return an
error status. Since that's a reply to the client you can
probably see what fails with wireshark.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."

Matthias Scheler | 5 Apr 2010 15:05
Picon
Favicon

Re: nfs server performance (netbsd-5)

On Mon, Apr 05, 2010 at 12:38:20PM +0300, Jukka Marin wrote:
> I "upgraded" my 4.0 server to netbsd-5 by extracting the tarballs over
> the old binaries, so old libraries and stuff were not deleted.  Maybe this
> is causing me problems.. is it possible that the new nfsd is using libs
> from NetBSD 4.0 and this is causing problems?

That is very unlikely. But you can get rid of old libraries and
update configuration files using "postinstall". You can e.g.
Run "/usr/sbin/postinstall -s /where/ever/etc.tgz -d / check"
or "cd /usr/src && make postinstall-check". The later requires
a "netbsd-5-0" or "netbsd-5" source tree of course.

And for the record:
My NetBSD/amd64 5.0_STABLE NFS server works fine. My Mac OS X NFS client
can read large files with more than 500Mb/s.

	Kind regards

--

-- 
Matthias Scheler                                  http://zhadum.org.uk/

Jukka Marin | 5 Apr 2010 17:40
Picon

Re: nfs server performance (netbsd-5)

On Mon, Apr 05, 2010 at 11:44:19AM +0000, Michael van Elst wrote:
> >What are the RPC errors, reported by nfsstats?  The number is increasing.
> Can be almost anything. It just counts RPCs that return an
> error status. Since that's a reply to the client you can
> probably see what fails with wireshark.

Hmm, wireshark looks like a gui program - and I must run it as root, right?
:-(

  -jm


Gmane