On Tue, May 10, 2005 at 09:31:28PM +0200, Manuel Bouyer wrote:
> On Tue, May 10, 2005 at 12:48:58PM +0100, Patrick Welche wrote:
> > While waiting for a 22GB text file to be read through a filter, I was
> > just wondering whether I should expect a faster read rate..
> > 
> >  88% |********************************     | 19885 MB    4.06 MB/s    10:49 ETA
> > 
> > is what progress says, so as the disks aren't doing anything else, is that
> > a reasonable way to estimate read speed?
> 
> Did you run top and systat vm while this was running ? Just to check that
> it is not CPU bound.
> You could also try a 'cat bigfile > /dev/null' to see if progress or the
> filter has some impact.

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
 6708 prlw1    -18    0   120K  672K uvn_fp2    0:05  0.98%  0.98% cat

    6 users    Load  4.29  3.66  2.75                  Wed May 11 12:30:37


Proc:r  d  s  w    Csw   Trp   Sys  Int  Sof   Flt            PAGING   SWAPPING
     1  1 19       259   766   639  191  210   796            in  out   in  out
                                                      ops                     1
   1.2% Sy   0.0% Us  98.8% Ni   0.0% In   0.0% Id    pages
|    |    |    |    |    |    |    |    |    |    |
=-------------------------------------------------                        forks
                                                                          fkppw
           memory totals (in kB)             301 Interrupts               fksvm
          real  virtual     free             100 cpu0 softclock           pwait
Active 1146984  1146984     1232              10 cpu0 softnet             relck
All    2046008  2046008   538352                 cpu0 softserial          rlkok
                                              91 pic0 pin 9               noram
Namei         Sys-cache     Proc-cache           pic0 pin 4             4 ndcpy
    Calls     hits    %     hits     %           pic0 pin 1               fltcp
      180      172   96                          pic0 pin 12           26 zfod
                                                 pic0 pin 10            9 cow
Disks:   sd0   sd1   cd0   cd1   sd2             pic0 pin 5            64 fmin
 seeks                                           pic0 pin 14           85 ftarg
 xfers                            73             pic0 pin 15       143501 itarg
 bytes                         4221K         100 pic0 pin 0          1028 wired
 %busy                           100                                 1068 pdfre

(the load of 4 is basically: dnetc, cat, ioflush, aiodoned)
so it really isn't doing anything else...

(csh built-in time)
% time cat olddata03_04m > /dev/null
0.0u 10.1s 13:25.74 1.2% 0+0k 208+1io 0pf+0w
% ls -l olddata03_04m
-rw-r--r--  1 postgres  postgres  3465758203 May 10 18:48 olddata03_04m
% ls -lh olddata03_04m
-rw-r--r--  1 postgres  postgres  3.2G May 10 18:48 olddata03_04m

3.2G/13:25 wall time = 4.1G, so "progress" seems to be correct...

3GHz P4, 2GB ram. A complication, is that sd2 is really 2 disks plugged into
to the lsilogic raid controller, combining them (striping?), and presenting
as a singe drive to the OS:

sd2 at scsibus2 target 0 lun 0: <LSILOGIC, RAID ARRAY    IS, 1000> disk fixed
sd2: fabricating a geometry
sd2: 136 GB, 139712 cyl, 64 head, 32 sec, 512 bytes/sect x 286130176 sectors
sd2: sync (6.25ns offset 127), 16-bit (320.000MB/s) transfers, tagged queueing
sd2: fabricating a geometry
sd2: fabricating a geometry

mpt0 at pci2 dev 3 function 0: LSI Logic 53c1030 Ultra320 SCSI
mpt0: interrupting at irq 10
scsibus1 at mpt0: 16 targets, 8 luns per target
mpt1 at pci2 dev 3 function 1: LSI Logic 53c1030 Ultra320 SCSI
mpt1: interrupting at irq 9
scsibus2 at mpt1: 16 targets, 8 luns per target

(on same interrupt:)
wm0 at pci2 dev 12 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 2
wm0: interrupting at irq 9


I really don't see where a speed factor of 80 could be hiding!

Cheers,

Patrick