On Mon, Dec 11, 2006 at 10:32:53AM +, Dieter wrote:
Did this problem start before you made port2file run with rtprio?
Yes. I only added rtprio because it wasn't working.
Can you please include a copy of your kernel configuration file and dmesg?
I think you asked that before:
Did this problem start before you made port2file run with rtprio?
Yes. I only added rtprio because it wasn't working.
Can you please include a copy of your kernel configuration file and dmesg?
I think you asked that before: :-)
OK, that's correct. Can you also provide details of
On Thu, Dec 07, 2006 at 05:41:51PM +, Dieter wrote:
However, I don't know what you mean by data is lost. Data should
never be lost from the filesystem regardless of how slow the I/O is
happening, unless there's something else going wrong (e.g. driver
bug).
Also, rtprio should
Dieter 16 IP bsd.63743 src.65001: . ack 52 win 65535
Dieter 11 IP bsd.63743 src.65001: . ack 53 win 112 -- why
does
Dieter the window suddenly shrink?
Chuck I'd guess because both sides have requested that the connection
Chuck close
That's probably the case. It just
hw.ata.wc=3D3D3D0
^^^
Make my hard drive go rally slow please (just in case I crash)=
:)
=3D20
Slower, yes, but not *that* slow.
=3D20
Normal ls : 0.032 second. Two processes using same disk, multiply by=
two,
so 0.064 second. Maybe
On Thu, Dec 07, 2006 at 03:21:46PM +, Dieter wrote:
hw.ata.wc=3D3D3D0
^^^
Make my hard drive go rally slow please (just in case I crash)=
:)
=3D20
Slower, yes, but not *that* slow.
=3D20
Normal ls : 0.032 second. Two processes
hw.ata.wc=3D3D3D3D0
^^^
Make my hard drive go rally slow please (just in case I cr=
ash)=3D
:)
=3D3D20
Slower, yes, but not *that* slow.
=3D3D20
Normal ls : 0.032 second. Two processes using same disk, multipl=
y by=3D
I found a couple more things that don't look right.
17 IP bsd.63743 src.65001: . ack 52 win 65535
000107 IP bsd.63743 src.65001: . ack 52 win 65535
12 IP bsd.63743 src.65001: F 52:52(0) ack 52 win 65535
05 IP bsd.63743 src.65001: F 52:52(0) ack 52 win 65535
000172 IP src.65001
On Dec 6, 2006, at 6:46 AM, Dieter wrote:
I found a couple more things that don't look right.
17 IP bsd.63743 src.65001: . ack 52 win 65535
000107 IP bsd.63743 src.65001: . ack 52 win 65535
12 IP bsd.63743 src.65001: F 52:52(0) ack 52 win 65535
05 IP bsd.63743 src.65001: F
Dieter [EMAIL PROTECTED] wrote:
I found a couple more things that don't look right.
17 IP bsd.63743 src.65001: . ack 52 win 65535
000107 IP bsd.63743 src.65001: . ack 52 win 65535
12 IP bsd.63743 src.65001: F 52:52(0) ack 52 win 65535
05 IP bsd.63743 src.65001: F 52:52(0)
hw.ata.wc=3D3D0
^^^
Make my hard drive go rally slow please (just in case I crash) :)
=20
Slower, yes, but not *that* slow.
=20
Normal ls : 0.032 second. Two processes using same disk, multiply by two,
so 0.064 second. Maybe the multiplier is more
Here's another oddity:
With one process reading from ad4, crunching data, writing to ad2:
4 usersLoad 0.31 0.47 0.67 Nov 23 10:05
Mem:KBREALVIRTUAL VN PAGER SWAP PAGER
Tot Share TotShareFree in out
On Thu, Nov 23, 2006 at 09:35:08AM +, Dieter wrote:
hw.ata.wc=3D3D0
^^^
Make my hard drive go rally slow please (just in case I crash) :)
=20
Slower, yes, but not *that* slow.
=20
Normal ls : 0.032 second. Two processes using same disk,
On Tue, Nov 21, 2006 at 11:12:38PM +, Dieter wrote:
I'm surprised that you're seeing that much of a hang. Even if the disks
are busy, the system should slow down all disk processes equally, so no
one process blocks, but they're all a little slower.
I collected a bit of data:
While
In message [EMAIL PROTECTED], Kris Kennaway writes:
I'm surprised that you're seeing that much of a hang. Even if the di=
sks
are busy, the system should slow down all disk processes equally, so no
one process blocks, but they're all a little slower.
=20
I collected a bit of data:
On Wed, Nov 22, 2006 at 11:02:54AM +, Dieter wrote:
In message [EMAIL PROTECTED], Kris Kennaway writes:
I'm surprised that you're seeing that much of a hang. Even if the di=
sks
are busy, the system should slow down all disk processes equally, so no
one process blocks, but
In message [EMAIL PROTECTED], Kris Kennaway writes:
--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 22, 2006 at 11:02:54AM +, Dieter wrote:
In message [EMAIL PROTECTED], Kris Kennaway
On Wed, Nov 22, 2006 at 06:12:06PM +, Dieter wrote:
time ls on a small directory on disk2
=3D20
real4m51.911s
user0m0.000s
sys 0m0.002s
=3D20
I expect access to a busy disk to take longer, but 5 minutes is
a bit much. And that's the root
time ls on a small directory on disk2
=3D3D20
real4m51.911s
user0m0.000s
sys 0m0.002s
=3D3D20
I expect access to a busy disk to take longer, but 5 minutes is
a bit much. And that's the root directory of the filesystem,
it didn't have
On Wed, Nov 22, 2006 at 07:41:46PM +, Dieter wrote:
oad
have been trimmed from your email.
=3D20
In telnet window 1:
=3D20
cd /disk1/
cp -ip very_big_file /disk2/bar/ (the workload)
=3D20
In telnet window 2:
=3D20
time ls /disk3/foo1/
hw.ata.wc=3D0
^^^
Make my hard drive go rally slow please (just in case I crash) :)
Slower, yes, but not *that* slow.
Normal ls : 0.032 second. Two processes using same disk, multiply by two,
so 0.064 second. Maybe the multiplier is more than 2, call it 10x, so
0.32
On Wed, Nov 22, 2006 at 11:29:16PM +, Dieter wrote:
hw.ata.wc=3D0
^^^
Make my hard drive go rally slow please (just in case I crash) :)
Slower, yes, but not *that* slow.
Normal ls : 0.032 second. Two processes using same disk, multiply by two,
so 0.064
I'm surprised that you're seeing that much of a hang. Even if the disks
are busy, the system should slow down all disk processes equally, so no
one process blocks, but they're all a little slower.
I collected a bit of data:
While copying a large file from disk1 to disk2,
time ls on a small
On Sat, 18 Nov 2006 23:42:31 +
Dieter [EMAIL PROTECTED] wrote:
[snip]
Bill writes:
Bill My guess would be that your process blocked on stdout.
Bill You don't mention what you're doing with stdout from the program, are
Bill you just letting it scroll on the terminal, or redirecting it
The machine has 2 GB. I wonder if the process is getting its fair share?
I have been observing other problems where disk activity to one disk
will make an unrelated process reading data from a different disk *very*
unresponsive.
Sounds like a hardware problem to me. If you've got a
In the tcpdump output below, the src machine is sending data to the
bsd machine. At one point during this test, the bsd machine is slowly
falling behind, as shown in the smaller and smaller window size.
It looks like at one point, the bsd machine takes 5.5 seconds to
ack a packet. :-( Am I
In the last episode (Nov 18), Dieter said:
In the tcpdump output below, the src machine is sending data to the
bsd machine. At one point during this test, the bsd machine is
slowly falling behind, as shown in the smaller and smaller window
size.
It looks like at one point, the bsd machine
My comments are based both on the packet dump here and the source code
you posted earlier ...
On Sat, 18 Nov 2006 12:20:33 +
Dieter [EMAIL PROTECTED] wrote:
In the tcpdump output below, the src machine is sending data to the
bsd machine. At one point during this test, the bsd machine is
Dan writes:
Dan A shrinking window and no packet loss is an indication that the program
Dan the socket is connected to isn't reading data fast enough. If you're
Dan locally gzipping the output of a remote backup, for example, you'll see
Dan this.
Just a tight loop reading the socket and writing
On Thu, 2006-11-16 at 19:17 -0500, Bill Moran wrote:
Window scaling is enabled by default. I'd assumed that there would be a
sysctl to disable it, but I can't seem to find one.
fwiw, the net.inet.tcp.rfc1323 sysctl is for window scaling/ high
performance extensions.
Bob
In response to Bob M. [EMAIL PROTECTED]:
On Thu, 2006-11-16 at 19:17 -0500, Bill Moran wrote:
Window scaling is enabled by default. I'd assumed that there would be a
sysctl to disable it, but I can't seem to find one.
fwiw, the net.inet.tcp.rfc1323 sysctl is for window scaling/
In the process of debugging a not-working-so-well TCP
application, I've been asked to provide:
cat /proc/sys/net/ipv4/tcp_window_scaling
cat /proc/sys/net/ipv4/tcp_wmem
Which of course results in No such file or directory.
I suspect these are from Linux. Are there equivalent
parameters in
On Thu, 16 Nov 2006 15:17:26 +
Dieter [EMAIL PROTECTED] wrote:
In the process of debugging a not-working-so-well TCP
application, I've been asked to provide:
cat /proc/sys/net/ipv4/tcp_window_scaling
cat /proc/sys/net/ipv4/tcp_wmem
Which of course results in No such file or
33 matches
Mail list logo
