On 09/07/2018 09:37 AM, John Johansen wrote:
> hey Tony,
>
> thanks for the patch, I am curious did you're investigation look
> into what parts of DEFINE_AUDIT_SK are causing the issue?
Hi JJ.
Attached are the perf annotations for DEFINE_AUDIT_SK (percentages are relative
to the fn).
Our ke
On 09/06/2018 09:33 PM, Tony Jones wrote:
> The netperf benchmark shows a 5.73% reduction in throughput for
> small (64 byte) transfers by unconfined tasks.
>
> DEFINE_AUDIT_SK() in aa_label_sk_perm() should not be performed
> unconditionally, rather only when the label is confined.
>
> netperf
The netperf benchmark shows a 5.73% reduction in throughput for
small (64 byte) transfers by unconfined tasks.
DEFINE_AUDIT_SK() in aa_label_sk_perm() should not be performed
unconditionally, rather only when the label is confined.
netperf-tcp
56974a6fc^
On 05/02/2014 12:40 PM, V JobNickname wrote:
I have an ARM platform which works with older 2.6.28 Linux Kernel and
the embedded NIC driver
I profile the TCP Tx using netperf 2.6 by command "./netperf -H
{serverip} -l 300".
Is your ARM platform a multi-core one? If so, you may need/want to look
I have an ARM platform which works with older 2.6.28 Linux Kernel and
the embedded NIC driver
I profile the TCP Tx using netperf 2.6 by command "./netperf -H
{serverip} -l 300".
In 2.6.28 the TCP tx can reach 190 Mbps.
Recently I am porting the platform to long-term Kernel version
2.6.32.61, 3.4.
y 3.10 was fine even with these settings and 3.12
wasn't. Here's the original report:
"I recently upgraded the Kernel from version 3.10 to latest stable
3.12.8, did the usual "make oldconfig" (resulting config attached).
But now I noticed some _really_ low network perf
On Sun, 2014-02-09 at 16:31 +0100, Borislav Petkov wrote:
> On Sun, Feb 09, 2014 at 04:05:11PM +0100, Daniel Exner wrote:
> > > cat /etc/sysctl.d/net.conf
> > > net.ipv4.tcp_window_scaling = 1
> > > net.core.rmem_max = 16777216
> > > net.ipv4.tcp_rmem = 4096 87380 16777
> > > net.ipv4.tcp_wmem = 40
On Sun, Feb 09, 2014 at 04:05:11PM +0100, Daniel Exner wrote:
> > cat /etc/sysctl.d/net.conf
> > net.ipv4.tcp_window_scaling = 1
> > net.core.rmem_max = 16777216
> > net.ipv4.tcp_rmem = 4096 87380 16777
> > net.ipv4.tcp_wmem = 4096 1638
>
> After removing those values I finally had sane iper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
Am Mon, 20 Jan 2014 23:37:52 +0100
schrieb Borislav Petkov :
> On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote:
> > I just did the same procedure with Kernel Version 3.13: same poor
> > rates.
> >
> > I think I will try to see
On 01/20/2014 11:37 PM, Borislav Petkov wrote:
On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote:
I just did the same procedure with Kernel Version 3.13: same poor rates.
I think I will try to see of 3.12.6 was still ok and bisect from there.
Or try something more coarse-grained lik
On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote:
> I just did the same procedure with Kernel Version 3.13: same poor rates.
>
> I think I will try to see of 3.12.6 was still ok and bisect from there.
Or try something more coarse-grained like 3.11 first, then 3.12 and then
the -rcs in
ne.linux.kernel.]
>
>> On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote:
>
>>> I recently upgraded the Kernel from version 3.10 to latest
>>> stable 3.12.8, did the usual "make oldconfig" (resulting
>>> config attached).
>>>
ote:
>
>> I recently upgraded the Kernel from version 3.10 to latest
>> stable 3.12.8, did the usual "make oldconfig" (resulting config
>> attached).
>>
>> But now I noticed some _really_ low network performance.
>
> Try: sysctl net.ipv4.tcp_limit_o
On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote:
> I recently upgraded the Kernel from version 3.10 to latest stable
> 3.12.8, did the usual "make oldconfig" (resulting config attached).
>
> But now I noticed some _really_ low network performance.
> "Willy" == Willy Tarreau writes:
Willy> On Sun, Jan 06, 2013 at 11:00:15AM -0800, Eric Dumazet wrote:
>> On Sun, 2013-01-06 at 10:51 -0800, Eric Dumazet wrote:
>> > >
>> > > (sd->len is usually 4096, which is expected, but sd->total_len value is
>> > > huge in your case, so we always set t
> "Willy" == Willy Tarreau writes:
Willy> On Sun, Jan 06, 2013 at 04:49:35PM -0500, John Stoffel wrote:
>> > "Willy" == Willy Tarreau writes:
>>
Willy> On Sun, Jan 06, 2013 at 11:00:15AM -0800, Eric Dumazet wrote:
>> >> On Sun, 2013-01-06 at 10:51 -0800, Eric Dumazet wrote:
>> >> > >
>
On Sun, Jan 06, 2013 at 04:49:35PM -0500, John Stoffel wrote:
> > "Willy" == Willy Tarreau writes:
>
> Willy> On Sun, Jan 06, 2013 at 11:00:15AM -0800, Eric Dumazet wrote:
> >> On Sun, 2013-01-06 at 10:51 -0800, Eric Dumazet wrote:
> >> > >
> >> > > (sd->len is usually 4096, which is expecte
On Sun, Jan 06, 2013 at 11:39:31AM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 20:34 +0100, Willy Tarreau wrote:
>
> > OK it works like a charm here now ! I can't break it anymore, so it
> > looks like you finally got it !
> >
> > I noticed that the data rate was higher when the loopback's
On Sun, 2013-01-06 at 20:34 +0100, Willy Tarreau wrote:
> OK it works like a charm here now ! I can't break it anymore, so it
> looks like you finally got it !
>
> I noticed that the data rate was higher when the loopback's MTU
> is exactly a multiple of 4096 (making the 64k choice optimal)
> whi
On Sun, Jan 06, 2013 at 11:00:15AM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 10:51 -0800, Eric Dumazet wrote:
> > >
> > > (sd->len is usually 4096, which is expected, but sd->total_len value is
> > > huge in your case, so we always set the flag in fs/splice.c)
> >
> > I am testing :
> >
On Sun, 2013-01-06 at 10:51 -0800, Eric Dumazet wrote:
> >
> > (sd->len is usually 4096, which is expected, but sd->total_len value is
> > huge in your case, so we always set the flag in fs/splice.c)
>
> I am testing :
>
>if (sd->len < sd->total_len && pipe->nrbufs > 1)
>
>
> (sd->len is usually 4096, which is expected, but sd->total_len value is
> huge in your case, so we always set the flag in fs/splice.c)
I am testing :
if (sd->len < sd->total_len && pipe->nrbufs > 1)
more |= MSG_SENDPAGE_NOTLAST;
--
To unsubscribe from this list: se
On Sun, 2013-01-06 at 10:39 -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 18:35 +0100, Willy Tarreau wrote:
>
> > Unfortunately it does not work any better, which means to me
> > that we don't leave via this code path. I tried other tricks
> > which failed too. I need to understand this part
On Sun, 2013-01-06 at 18:35 +0100, Willy Tarreau wrote:
> Unfortunately it does not work any better, which means to me
> that we don't leave via this code path. I tried other tricks
> which failed too. I need to understand this part better before
> randomly fiddling with it.
>
OK, now I have you
On Sun, Jan 06, 2013 at 09:10:55AM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 17:44 +0100, Willy Tarreau wrote:
> > On Sun, Jan 06, 2013 at 08:39:53AM -0800, Eric Dumazet wrote:
> > > Hmm, I'll have to check if this really can be reverted without hurting
> > > vmsplice() again.
> >
> > Loo
On Sun, 2013-01-06 at 17:44 +0100, Willy Tarreau wrote:
> On Sun, Jan 06, 2013 at 08:39:53AM -0800, Eric Dumazet wrote:
> > Hmm, I'll have to check if this really can be reverted without hurting
> > vmsplice() again.
>
> Looking at the code I've been wondering whether we shouldn't transform
> the
On Sun, 2013-01-06 at 16:51 +0100, Willy Tarreau wrote:
> Hi Eric,
>
> Oh sorry, I didn't really want to pollute the list with links and configs,
> especially during the initial report with various combined issues :-(
>
> The client is my old "inject" tool, available here :
>
> http://git.
On Sun, Jan 06, 2013 at 08:39:53AM -0800, Eric Dumazet wrote:
> Hmm, I'll have to check if this really can be reverted without hurting
> vmsplice() again.
Looking at the code I've been wondering whether we shouldn't transform
the condition to perform the push if we can't push more segments, but
I
Hi Eric,
On Sun, Jan 06, 2013 at 06:59:02AM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 10:24 +0100, Willy Tarreau wrote:
>
> > It does not change anything to the tests above unfortunately. It did not
> > even stabilize the unstable runs.
> >
> > I'll check if I can spot the original comm
On Sun, 2013-01-06 at 10:24 +0100, Willy Tarreau wrote:
> It does not change anything to the tests above unfortunately. It did not
> even stabilize the unstable runs.
>
> I'll check if I can spot the original commit which caused the regression
> for MTUs that are not n*4096+52.
Since you don't p
On Sun, Jan 06, 2013 at 11:25:25AM +0100, Willy Tarreau wrote:
> OK good news here, the performance drop on the myri was caused by a
> problem between the keyboard and the chair. After the reboot series,
> I forgot to reload the firmware so the driver used the less efficient
> firmware from the NIC
On Sun, Jan 06, 2013 at 12:46:58PM +0100, Romain Francoise wrote:
> Willy Tarreau writes:
>
> > That makes me think that I should try 3.8-rc2 since LRO was removed
> > there :-/
>
> Better yet, find a way to automate these tests so they can run continually
> against net-next and find problems ea
Willy Tarreau writes:
> That makes me think that I should try 3.8-rc2 since LRO was removed
> there :-/
Better yet, find a way to automate these tests so they can run continually
against net-next and find problems early...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Sun, Jan 06, 2013 at 10:24:35AM +0100, Willy Tarreau wrote:
> But before that I'll try to find the recent one causing the myri10ge to
> slow down, it should take less time to bisect.
OK good news here, the performance drop on the myri was caused by a
problem between the keyboard and the chair.
On Sat, Jan 05, 2013 at 11:35:24PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 03:52 +0100, Willy Tarreau wrote:
>
> > OK so I observed no change with this patch, either on the loopback
> > data rate at >16kB MTU, or on the myri. I'm keeping it at hand for
> > experimentation anyway.
> >
>
On Sun, 2013-01-06 at 03:52 +0100, Willy Tarreau wrote:
> OK so I observed no change with this patch, either on the loopback
> data rate at >16kB MTU, or on the myri. I'm keeping it at hand for
> experimentation anyway.
>
Yeah, there was no bug. I rewrote it for net-next as a cleanup/optim
only.
On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> > >
> > > > Ah interesting because these were some of th
On Sun, 2013-01-06 at 03:32 +0100, Willy Tarreau wrote:
> It's 0cf833ae (net: loopback: set default mtu to 64K). And I could
> reproduce it with 3.6 by setting loopback's MTU to 65536 by hand.
> The trick is that once the MTU has been set to this large a value,
> even when I set it back to 16kB th
On Sat, Jan 05, 2013 at 06:22:13PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 03:18 +0100, Willy Tarreau wrote:
> > On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> > > On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > > > On Sat, 2013-01-05 at 17:40 -0800, Eric Duma
On Sun, 2013-01-06 at 03:18 +0100, Willy Tarreau wrote:
> On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> > On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wr
On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> > >
> > > > Ah interesting because these were some of th
On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> >
> > > Ah interesting because these were some of the mm patches that I had
> > > tried to revert.
> >
> > Hmm, or we shoul
On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
>
> > Ah interesting because these were some of the mm patches that I had
> > tried to revert.
>
> Hmm, or we should fix __skb_splice_bits()
>
> I'll send a patch.
>
Could you try t
On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> Ah interesting because these were some of the mm patches that I had
> tried to revert.
Hmm, or we should fix __skb_splice_bits()
I'll send a patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Sat, Jan 05, 2013 at 05:21:16PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 01:50 +0100, Willy Tarreau wrote:
>
> > Yes, I've removed all zero counters in this short view for easier
> > reading (complete version appended at the end of this email). This
> > was after around 140 GB were tr
On Sun, 2013-01-06 at 01:50 +0100, Willy Tarreau wrote:
> Yes, I've removed all zero counters in this short view for easier
> reading (complete version appended at the end of this email). This
> was after around 140 GB were transferred :
OK I only wanted to make sure skb were not linearized in xm
On Sat, Jan 05, 2013 at 04:02:03PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 00:29 +0100, Willy Tarreau wrote:
>
> > > 2) Another possibility would be that Myri card/driver doesnt like very
> > > well high order pages.
> >
> > It looks like it has not changed much since 3.6 :-/ I really
On Sun, 2013-01-06 at 00:29 +0100, Willy Tarreau wrote:
> > 2) Another possibility would be that Myri card/driver doesnt like very
> > well high order pages.
>
> It looks like it has not changed much since 3.6 :-/ I really suspect
> something is wrong with memory allocation. I have tried revertin
Hi Eric,
On Sat, Jan 05, 2013 at 03:18:46PM -0800, Eric Dumazet wrote:
> Hi Willy, another good finding during the week end ! ;)
Yes, I wanted to experiment with TFO and stopped on this :-)
> 1) This looks like interrupts are spreaded on multiple cpus, and this
> give Out Of Order problems with
On Sat, 2013-01-05 at 22:49 +0100, Willy Tarreau wrote:
> Hi,
>
> I'm observing multiple apparently unrelated network performance
> issues in 3.7, to the point that I'm doubting it comes from the
> network stack.
>
> My setup involves 3 machines connected point
Hi,
I'm observing multiple apparently unrelated network performance
issues in 3.7, to the point that I'm doubting it comes from the
network stack.
My setup involves 3 machines connected point-to-point with myri
10GE NICs (the middle machine has 2 NICs). The middle machine
normally ru
On Tue, Mar 06, 2007 at 04:16:24PM +0100, Eric Dumazet wrote:
>
> It would be better to name the tunable "disable_timestamps", default 0 of
> course
I agree.
If networking maintainers are interested, I surely can prepare a patch.
But IMO some way to force TSC usage on x86_64 will be even b
On Tuesday 06 March 2007 15:43, Vladimir B. Savkin wrote:
> On Tue, Mar 06, 2007 at 03:38:44PM +0100, Eric Dumazet wrote:
> > 2) "accurate_timestamps" is misleading.
> > Should be "disable_timestamps"
>
> Not, if default is 1, as in my patch.
Yes I saw this. I should write more words next time
On Tue, Mar 06, 2007 at 03:38:44PM +0100, Eric Dumazet wrote:
> 2) "accurate_timestamps" is misleading.
> Should be "disable_timestamps"
Not, if default is 1, as in my patch.
~
:wq
With best regards,
Vladi
On Tuesday 06 March 2007 14:25, Vladimir B. Savkin wrote:
> },
> + {
> + .ctl_name = NET_CORE_ACCURATE_TIMESTAMPS,
> + .procname = "accurate_timestamps",
> + .data = &sysctl_accurate_timestamps,
> + .maxlen = s
On Fri, Sep 22, 2006 at 09:51:09AM -0700, Rick Jones wrote:
> >That came from named. It opens lots of sockets with SIOCGSTAMP.
> >No idea what it needs that many for.
>
> IIRC ISC BIND named opens a socket for each IP it finds on the system.
> Presumeably in this way it "knows" implicitly the des
Andrew,
Please apply.
--linas
This patch corrects a problem seen on later kernels running
the NetPIPE application. Specifically, NetPIPE would begin
running very slowly at the 1533 packet size. It was
determined that Spidernet slowed with an idle DMA
engine.
Signed-off-by: James K Lewis
tg3 driver). I am seeing truly appalling network performance
> > (2-4kbps on a 1gbps network). Is this a known issue? I know this patch is
> > not production ready, what traces/logs do you need/want to be able to
> > debug/fix this?
>
> What is your test app and what
On Sun, Mar 27, 2005 at 10:27:40PM +, Christensen Tom wrote:
> I'm running 2.6.11 with Ingo's Preempt patch
> (realtime-preempt-2.6.11-final-V0.7.40-04). The system is SMP with a
> broadcom NIC (tg3 driver). I am seeing truly appalling network performance
> (2-4k
I'm running 2.6.11 with Ingo's Preempt patch
(realtime-preempt-2.6.11-final-V0.7.40-04). The system is SMP with a
broadcom NIC (tg3 driver). I am seeing truly appalling network performance
(2-4kbps on a 1gbps network). Is this a known issue? I know this patch is
not production r
On Wed, Jun 06, 2001 at 02:52:03AM +, John William wrote:
>
> The curse of the HP Vectra XU 5/90 strikes again!
>
> What is interesting is that I tried the NetGear FA310, FA311, 3COM 3cSOHO
> and 3C905C-TX cards and both the receive and transmit speeds (measured with
> both iperf and netpe
This is a follow up message to the original "Abysmal Receive Performance"
message. Thanks to everyone who e-mailed me with suggestions.
Well, after poking around, I eventually narrowed the problem down to the
fact that the system BIOS did not enable PCI->RAM write posting. After I
enabled that
won't get there.
skd
On Mon, May 28, 2001 at 03:47:22AM +, John William wrote:
> Can someone please help me troubleshoot this problem - I am getting abysmal
> (see numbers below) network performance on my system, but the poor
> performance seems limited to receiving data.
John William wrote:
>
> >Depends on what is driving it... An application I built can only push
> >about
> >80 Mbps bi-directional on PII 550Mhz machines. It is not the most
> >efficient program in
> >the world, but it isn't too bad either...
> >
> >I missed the rest of this thread, so maybe you
>Depends on what is driving it... An application I built can only push
>about
>80 Mbps bi-directional on PII 550Mhz machines. It is not the most
>efficient program in
>the world, but it isn't too bad either...
>
>I missed the rest of this thread, so maybe you already mentioned it, but
>what is
or testing. So it appears to me that everything is working
> correctly (hardware).
>
> I keep coming back to a problem with the kernel, or that somehow I have two
> cards (FA310 and 3CSOHO) defective in almost exactly the same way, but only
> on receive. If it were a hardware problem
and 3CSOHO) defective in almost exactly the same way, but only
on receive. If it were a hardware problem, why would I only get poor
performance in one direction and not both?
Does anyone have network performance numbers for a comparable machine (P-90
class)? I'm thinking I should expect 50-
> >the Netgear FA311/2 (tulip). Found that the link lost
> >connectivity because of card lockups and transmit timeout
> >failures - and some of these were silent. However, I moved
> >to the 3C905C (3c59x driver) which behaved like a champ, and
> I'm a little confused here - do you mean the FA310T
>From: Nivedita Singhvi <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED]
>Subject: Re: Abysmal RECV network performance
>Date: Mon, 28 May 2001 23:45:28 -0700 (PDT)
>While we didnt use 2.2 kernels at all, we did similar tests
>on 2.4.0 through 2.4.4 k
> Can someone please help me troubleshoot this problem -
> I am getting abysmal (see numbers below) network performance
> on my system, but the poor performance seems limited to receiving
> data. Transmission is OK.
[ snip ]
> What kind of performance should I be seeing with
Can someone please help me troubleshoot this problem - I am getting abysmal
(see numbers below) network performance on my system, but the poor
performance seems limited to receiving data. Transmission is OK.
The computer in question is a dual Pentium 90 machine. The machine has
RedHat 7.0
I'm working on a problem on alpha SMP on the
AS4100 (Rawhide) machine. Under SMP, with heavy network activity.
With an inbound and outbound ping flood running, after about 500,000
packets, it just dies. Console dead, no response. For about a minute.
Then, sometimes, the machine comes back.
Anythi
On Tue, 20 Feb 2001, Richard B. Johnson wrote:
> There is nothing in either the VXI/Bus driver or the the Ethernet
> driver that gives up the CPU, i.e., nobody calls schedule() in any
> (known) path.
Check out IKD. Ktrace is wonderful for making such unknowns visible.
-Mike
-
To unsub
On Tue, 20 Feb 2001, Mike Galbraith wrote:
> On Tue, 20 Feb 2001, Richard B. Johnson wrote:
>
> > There is nothing in either the VXI/Bus driver or the the Ethernet
> > driver that gives up the CPU, i.e., nobody calls schedule() in any
> > (known) path.
>
> Check out IKD. Ktrace is wonderful fo
Given the following topography:
| |
| VXI RAM |
|__|
|---
|--|-| | Ethernet|
| VXI bridge | | AMD PcNet32 |
|| |__
On Tue, Jan 09, 2001 at 03:56:11PM -0500, Tim Sailer wrote:
> > The defaults must be large unless your application calls setsockopt() to
> > set the buffers itself. (Some FTP clients and servers can do this, but
> > for testing, your're still probably better always having the _max's and
> > _defa
On Tue, Jan 09, 2001 at 02:29:36PM -0500, John Heffner wrote:
> >
> > ports:/home/ftp# sysctl -a | fgrep net/core
> > net/core/optmem_max = 10240
> > net/core/message_burst = 50
> > net/core/message_cost = 5
> > net/core/netdev_max_backlog = 300
> > net
On Tue, 9 Jan 2001, Tim Sailer wrote:
> Here is some more data:
>
> Inbound = 99.66 kB/s
> Outbound= 151 kB/s
>
>
>
> ports:/home/ftp# sysctl -a | fgrep net/core
> net/core/optmem_max = 10240
> net/core/message_burst = 50
> net/core/
On Tue, Jan 09, 2001 at 05:52:34PM +0100, Martin Josefsson wrote:
> On Tue, 9 Jan 2001, Tim Sailer wrote:
>
> > On Mon, Jan 08, 2001 at 07:07:18PM +0100, Erik Mouw wrote:
> > > I had similar problems two weeks ago. Turned out the connection between
> > > two switches: one of them was hard wired t
On Tue, 9 Jan 2001, Tim Sailer wrote:
> On Mon, Jan 08, 2001 at 07:07:18PM +0100, Erik Mouw wrote:
> > I had similar problems two weeks ago. Turned out the connection between
> > two switches: one of them was hard wired to 100Mbit/s full duplex, the
> > other one to 100Mbit/s half duplex. Just to
Here is some more data:
Inbound = 99.66 kB/s
Outbound= 151 kB/s
ports:/home/ftp# sysctl -a | fgrep net/core
net/core/optmem_max = 10240
net/core/message_burst = 50
net/core/message_cost = 5
net/core/netdev_max_backlog = 300
net/core/r
On Mon, Jan 08, 2001 at 01:40:57PM -0500, Craig I. Hagan wrote:
> > 101 packets transmitted, 101 packets received, 0% packet loss
> > round-trip min/avg/max = 109.6/110.3/112.2 ms
> >
> > > Does the problem occur in both directions?
> >
> > Good question. I'll find out.
> >
> > > Are you _sure_
On Mon, Jan 08, 2001 at 07:07:18PM +0100, Erik Mouw wrote:
> I had similar problems two weeks ago. Turned out the connection between
> two switches: one of them was hard wired to 100Mbit/s full duplex, the
> other one to 100Mbit/s half duplex. Just to rule out the obvious...
We check that as the
On Mon, 8 Jan 2001, Tim Sailer wrote:
> > What is the round-trip time on the WAN?
> >
> > Packet loss?
>
> 101 packets transmitted, 101 packets received, 0% packet loss
> round-trip min/avg/max = 109.6/110.3/112.2 ms
Packet loss and RTT can be greatly affected by how much data you're
sending t
> 101 packets transmitted, 101 packets received, 0% packet loss
> round-trip min/avg/max = 109.6/110.3/112.2 ms
>
> > Does the problem occur in both directions?
>
> Good question. I'll find out.
>
> > Are you _sure_ the window size is being set correctly? How
> > is it being set?
>
> I'm fairl
On Mon, Jan 08, 2001 at 09:06:45AM -0500, Tim Sailer wrote:
> On Mon, Jan 08, 2001 at 09:26:23PM +1100, Andrew Morton wrote:
> > You're sending and receiving FTP/TCP/IP4 to Solaris and AIX hosts
>
> Yup
>
> > You have a 1000kbyte window size
>
> Yup
>
> > You have an 80 megabit/sec pipe.
>
>
On Mon, Jan 08, 2001 at 09:26:23PM +1100, Andrew Morton wrote:
> Tim Sailer wrote:
> >
> > On Sat, Jan 06, 2001 at 10:11:40PM +1100, Andrew Morton wrote:
> > > this issue was discussed on the netdev mailing list a few weeks
> > > back.
> > >
> > > It's very unfortunate that the web archives of ne
Tim Sailer wrote:
>
> On Sat, Jan 06, 2001 at 10:11:40PM +1100, Andrew Morton wrote:
> > this issue was discussed on the netdev mailing list a few weeks
> > back.
> >
> > It's very unfortunate that the web archives of netdev
> > stopped working several months ago and there now appears
> > to be n
On Sat, Jan 06, 2001 at 10:11:40PM +1100, Andrew Morton wrote:
> this issue was discussed on the netdev mailing list a few weeks
> back.
>
> It's very unfortunate that the web archives of netdev
> stopped working several months ago and there now appears
> to be no web archive of [EMAIL PROTECTED]
> The conclusion was "The problem is also fixed with
> 2.4.0-test12pre3". Dunno about kernel 2.2 though.
DaveM sent me a patch to address the problem its in 2.2.19pre3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please re
Tim Sailer wrote:
>
> On Thu, Jan 04, 2001 at 01:33:40AM -0500, Tim Sailer wrote:
> > This may not be the right forum to ask this. If not, please let me know
> > where to ask.
> >
> > I have a Debian box with 2 NICs. Both 100/full duplex. This machine is
> > running as a ftp proxy (T.Rex suite).
On Thu, Jan 04, 2001 at 01:33:40AM -0500, Tim Sailer wrote:
> This may not be the right forum to ask this. If not, please let me know
> where to ask.
>
> I have a Debian box with 2 NICs. Both 100/full duplex. This machine is
> running as a ftp proxy (T.Rex suite). As part of the traffic going th
This may not be the right forum to ask this. If not, please let me know
where to ask.
I have a Debian box with 2 NICs. Both 100/full duplex. This machine is
running as a ftp proxy (T.Rex suite). As part of the traffic going through the
box, some streams have 1000k window size for a certain reaso
HI all,
Thanks for all the help. I have switched to a low-end 16-bit PCMCIA
network card by 3COM 3C589 10/BT. And now everything works as it
should. Before making this change, I thought that my problem was caused
by the TCP/IP layer -- between Linux and Sun, because I could get good
network
Hello!
> installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500,
> 256MB RAM). One thing that I found is the networking performance
> between this Linux box and all my Solaris 7 based servers are very very
> slow.
Make tcpdump before all.
> least 1000K/s, normally 3000k/s.
Somet
On Wed, 6 Sep 2000, Jack Duan wrote:
> I have been using Linux since the early days... and recently that I have
> installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500,
> 256MB RAM). One thing that I found is the networking performance
> between this Linux box and all my Solaris 7
Hi,
I have been using Linux since the early days... and recently that I have
installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500,
256MB RAM). One thing that I found is the networking performance
between this Linux box and all my Solaris 7 based servers are very very
slow. I only
97 matches
Mail list logo
