From: "P.V.Anthony" <pvantony@singnet.com.sg>
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] Re: Tcp transfer has a pause every few seconds
Date: Sun, 30 Oct 2005 23:27:25 +0800 [thread overview]
Message-ID: <4364E65D.4070109@singnet.com.sg> (raw)
In-Reply-To: <pan.2005.10.25.12.56.16.213042@cox.net>
Duncan wrote:
>
> Pause every few seconds. I've seen two commonly reported solutions to
> this -- two different problems resulting in the same symtoms -- and
> another one less common in general but likely equally common on amd64.
>
> 1) DMA, or rather, the lack thereof, or interrupt sharing. Ensure that
> you have the correct chipset drivers installed, both for whatever bus the
> NIC is on, and for your hard drive interface (the PATA/SATA/SCSI chipset).
> Often, generic or the wrong drivers will work in degraded mode, but DMA
> won't be turned on, and performance will suffer. For your hard drives
> (yes, wrong drivers there /can/ cause bottlenecks up the chain, including
> onto the same bus as the NIC), use hdparm (or sdparm) to verify that both
> the drive and the chipset agree that DMA is on.
I am using the Promise EX8350 raid card and using there driver.
>
> Also check interrupt distribution and sharing. You may be able to change
> these settings in the BIOS, or try switching some cards around
> (particularly your NIC if it's not on-board built-in).
This one I was thinking of trying the last. (Read below)
>
> 2) Do you have an "extra" network interface? I've seen this one on
> MSWormOS and am unsure how Linux would even have the problem, unless you
> have a spare interface (say a wireless card) that's running but not
> connected. Anyway, the problem here is an interface set to DHCP mode that
> can't get an IP because it's not connected, so of course can't see a
> server. The system would pause every few minutes (every few seconds seems
> a bit much, but...) and try to obtain an IP, stalling all I/O in the
> process. (Again, the reason it's stalling all I/O is likely rooted in
> misconfigured DMA or IRQs, but anyway...)
All the network cards are set to static address.
>
> 3) Seen frequently on this list as a problem resulting in one or more of
> a number of symtoms, including this one: APIC or ACPI problems. Take a
> look at the kernel documentation under $kerneldir/Documentation/x86_64,
> the apic and acpi boot options, and idle=poll as well. Note that those
> needing these often find they don't after a mature BIOS is available and
> flashed. idle=poll is particularly nasty, as it will cause your CPU to
> work far harder and run far hotter than it ordinarily would, but some
> early amd64 boards required it until an updated BIOS fixed the issue. I'm
> not sure if that's still a problem with the newer boards or not.
I am using the latest bios. So far I am not using any apic boot options. Will
read up.
>
> Also note that for specific net chip, various configuration options may be
> available. In particular, there's the Broadcom tigon3/tg3 kernel driver,
> and then another (I forget what it's called) for the same net chip. Often
> one will work well, the other won't work or will have issues. If that's
> your chip, look it up and consider trying the other driver.
Will check this.
Thank you very much for replying and helping. Please read my observations below
and if you have time please advice. Let me know if I still have to do the checks
as mention above.
Here are some specs and observations.
Specs.
cpu: AMD 64 3000+
drives: Sata drives
mobo: MSI Neo 4 Platinum
Ram: 2GB
Raid: Promise EX8350
OS: Gentoo
Kernel: 2.6.13 r3
Filesystem: XFS
Observations.
When I was using the xfs I had the problem of the pauses in the tcp transfers.
These pauses, I am guessing is because of the pdflush that occurs around every
20 seconds. There is only one pdflush every 20 seconds. This caused lose of
video frames when we did the video recording. The video would have a jerk or
jump when played back.
I changed the dirty_ratio from the default of 40 to 5. This solved the problem.
During the recording preview there seems to be some jerks but during the
playback it seems to be ok. The pdflush happens more often and there is still
one pdflush. I think the jerk that I see in the record preview coincides with
the pdflush. More jerks in record preview but ok during playback.
Next I formatted the drives to the ext3 filesystem. The dirty_ratio was set back
to the default value of 40. When the video started to record there is no loss of
frames and no jerks in the preview window. During the playback there is no loss.
Everything is good. Check the top for pdflush and noticed that the there is two
pdflush. The pdflushs is happening at every 5 seconds or so. Very fast compared
to when I was using xfs.
So the problem must be my xfs setting. For xfs I have only used the default
setting. Or could there be a problem with xfs and AMD64 kernel?
What must I do to get xfs to work? Or what am I doing wrong?
Please comment and advise.
Once again thank you very much for the advice.
P.V.Anthony
--
gentoo-amd64@gentoo.org mailing list
next prev parent reply other threads:[~2005-10-30 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-24 19:34 [gentoo-amd64] Tcp transfer has a pause every few seconds P.V.Anthony
2005-10-25 12:56 ` [gentoo-amd64] " Duncan
2005-10-30 15:27 ` P.V.Anthony [this message]
2005-10-30 17:53 ` [gentoo-amd64] " Duncan
2005-11-03 3:00 ` P.V.Anthony
2005-11-03 7:28 ` [gentoo-amd64] " Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4364E65D.4070109@singnet.com.sg \
--to=pvantony@singnet.com.sg \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox