Date: Wed, 26 Oct 2005 00:07:13 -0400 From: Robert Atkinson <phreaki@gmail.com> To: Joao Barros <joao.barros@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Poor Samba throughput on 6.0 RC1 Message-ID: <6fb2b4650510252107n66318924m874d530fb01410ad@mail.gmail.com> In-Reply-To: <70e8236f0510251636k1002cc96yd357492a138e1933@mail.gmail.com> References: <70e8236f0510241518x7b280938jd15f7e8c3224cbd@mail.gmail.com> <435D64B2.2020703@linkline.com> <6fb2b4650510242021l72a1ceb9m91e72a0420458982@mail.gmail.com> <70e8236f0510251636k1002cc96yd357492a138e1933@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/25/05, Joao Barros <joao.barros@gmail.com> wrote: > > On 10/25/05, Robert Atkinson <phreaki@gmail.com> wrote: > > Maybe a longshot, but what is your cluster size? > The default block size of 16384 bytes, a fragment size of 2048 bytes > The ide drive has a NTFS partition which I mounted readonly and > copying files from there resulted with the same below expected > performance :( > > > > > I'd be interested to hear if same irq is being shared if that is enough > bw? > > I disabled the USB controller and the extra NIC to get more available > > IRQs and tried using the amr on diferent pci slots with no change in > > performance. > > I could swear I remember seeing that actually usbd_enable=3D"NO" is required even if you disable the usb controller for the problem with drive speed and the usbd. Above that, does dmesg still show the nic, agp, and scsi controller sittin= g on irq 11? Might take a reset config data in bios, or a staggering of pci slots to get it to stop doing that. > > > > I've gotten better perf on that hardware with 6, so that's things i > > watch > > > for. > > > > > > Tipical 'systat -vm' when getting most bandwith (5.4MB/s): > > > > 1 users Load 0.21 0.20 0.08 Oct 26 00:27 > > > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > > Tot Share Tot Share Free in out in out > > Act 11428 1340 44612 3552 10832 count > > All 246032 3028 10261972 6828 pages > > Interrupts > > Proc:r p d s w Csw Trp Sys Int Sof Flt cow 3340 total > > 24 7743 1535 5604 40 45836 wire 1001 0: clk > > 14108 act 2127 5: fxp0 > > 15.6%Sys 10.9%Intr 0.8%User 0.0%Nice 72.7%Idl 176424 inact 6: fdc0 > > | | | | | | | | | | 10184 cache 128 8: rtc > > =3D=3D=3D=3D=3D=3D=3D=3D+++++> 648 free 11: ahc > > daefr 13: npx > > Namei Name-cache Dir-cache prcfr 14: ata > > Calls hits % hits % react 84 15: amr > > 1 pdwake > > zfod 1229 pdpgs > > Disks ad0 amrd0 da0 pass0 ofod intrn > > KB/t 0.00 128 0.00 0.00 %slo-z 35152 buf > > tps 0 42 0 0 993 tfree 3 dirtybuf > > MB/s 0.00 5.25 0.00 0.00 17453 desiredvnodes > > % busy 0 14 0 0 643 numvnodes > > 336 freevnodes > > I'm not great at vm usage, but I think it could just be chipset issue. I've seen some really poor results with disk performance from some people, but was mostly related to vnconfig and mdconfig (4.11 vs 5.X). This may not help your system out that greatly, as it doesn't appear to be an issue, but your fxp card should be supported for device_polling. AFAIK you should see better performance, since the fxp card won't be waking up the kernel for every little packet. I'd hope that with screen updates, nic data and the load of the irq from the disk would hurt it all. Surely the agp card is using up some of that, but I'm not sure of what that chipset would do under those types of conditions. Is dma being enabled? Is it really important to have access times marked o= n disk? You could/should turn that off with tunefs I think if you don't need it, will waste some access time and if you don't want that stamp, things should improve for at least smaller files. Above all, when a drive starts to be unusually slow, I'd pop a 4.11 disc i= n and test, throw in hard drive tester if 4.11 shows same perf, which is not easy for scsi drives (don't se= e smart data on the ones I have), ide drives can at least show me what errors are coming from the disk reads and I know the drive is going to be slower. (It takes 5 attempts to get a seek to go through) HTH -- > > Joao Barros > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6fb2b4650510252107n66318924m874d530fb01410ad>