> In special cases, the error induced by having interrupts blocked
> causes errors which are much larger than polling alone.
Which conditions block interrupts for longer than, say, a millisecond?
Disk errors / wakeups? Anything occurring in "normal" conditions?
Pete
To Unsubscribe: send mail
On Fri, 18 Oct 2002, Kelly Yancey wrote:
> > You should definitely clarify how fast the smartbits unit is pushing
> > out traffic, and whether its speed depends on the measured RTT.
> >
>
> It doesn't sound like the box is that smart. As it was explained to me, the
> test setup includes a desir
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> Oh, I *thought* the numbers you reported were pps but now i see that
> nowhere you mentioned that.
>
Sorry. I just checked with our tester. Those are the total number of
packets sent during the test. Each test lasted 10 seconds, so divde by 10 to
get
On Fri, 18 Oct 2002, Prafulla Deuskar wrote:
> FYI. 82543 doesn't support PCI-X protocol.
> For PCI-X support use 82544, 82545 or 82546 based cards.
>
> -Prafulla
>
That is alright, we aren't expecting PCI-X speeds. It is just that our only
PCI slot on the motherboard (1U rack-mount system) is
Oh, I *thought* the numbers you reported were pps but now i see that
nowhere you mentioned that.
But if things are as you say, i am seriously puzzled on what you
are trying to measure -- the output interface (fxp) is a 100Mbit/s
card which cannot possibly support the load you are trying to offer
t
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> How is the measurement done, does the box under test act as a router
> with the smartbit pushing traffic in and expecting it back ?
>
The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
configured with 7 VLANs. THe SmartBit produce
FYI. 82543 doesn't support PCI-X protocol.
For PCI-X support use 82544, 82545 or 82546 based cards.
-Prafulla
Kelly Yancey [[EMAIL PROTECTED]] wrote:
> On Fri, 18 Oct 2002, Luigi Rizzo wrote:
>
> > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> > ...
> > > Hmm. Might that ex
How is the measurement done, does the box under test act as a router
with the smartbit pushing traffic in and expecting it back ?
The numbers are strange, anyways.
A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
for 330-byte frames should amount to 100/(330*8+160) ~= 357kpps
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> ...
> > Hmm. Might that explain the abysmal performance of the em driver with
> > packets smaller than 333 bytes?
>
> what do you mean ? it works great for me. even on -current i
> can push
On Fri, Oct 18, 2002 at 06:21:37PM +0300, Petri Helenius wrote:
...
> Luigi´s polling work would be useful here. That would lead to incorrect
> timestamps
> on the packets, though?
polling introduce an extra uncertainty which might be as large as
an entire clock tick, yes.
But even with interrupt
On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
...
> Hmm. Might that explain the abysmal performance of the em driver with
> packets smaller than 333 bytes?
what do you mean ? it works great for me. even on -current i
can push out over 400kpps (64byte frames) on a 2.4GHz box.
On Fri, 18 Oct 2002, Petri Helenius wrote:
> >
> > just reading the source code, yes, it appears that the card has
> > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > and usage in sys/dev/em/* . I don't know in what units are the values
> > (28 and 128, respectively), but
Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds.
The em driver currently uses these to enable interrupt coalescing on the cards.
Thanks,
Prafulla
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
iginal Message -
> > From: "Jim McGrath" <[EMAIL PROTECTED]>
> > To: "Luigi Rizzo" <[EMAIL PROTECTED]>; "Petri Helenius" <[EMAIL PROTECTED]>
> > Cc: "Lars Eggert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>
> The chips I have are 82546. Is your recommendation to steer away
> from Intel
> Gigabit Ethernet chips? What would be more optimal alternative?
>
The 82543/82544 chips worked well in vanilla configurations. I never played
with an 82546. The em driver is supported by Intel, so any chip features
M
> > To: Jim McGrath
> > Cc: Petri Helenius; Lars Eggert; [EMAIL PROTECTED]
> > Subject: Re: ENOBUFS
> >
> >
> > On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote:
> > > Careful here. Read the errata sheet!! I do not believe the em
> &g
<[EMAIL PROTECTED]>
> To: "Luigi Rizzo" <[EMAIL PROTECTED]>; "Petri Helenius" <[EMAIL PROTECTED]>
> Cc: "Lars Eggert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Friday, October 18, 2002 7:49 AM
> Subject: RE: ENOBUFS
>
>
&
he data sheets :)
>
> cheers
> luigi
> > Jim
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > > Sent: Thursday, October 17, 2002 11:12 PM
>
>
> just reading the source code, yes, it appears that the card has
> support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> and usage in sys/dev/em/* . I don't know in what units are the values
> (28 and 128, respectively), but it does appear that tx interrupts are
> delayed a bit
-
From: "Jim McGrath" <[EMAIL PROTECTED]>
To: "Luigi Rizzo" <[EMAIL PROTECTED]>; "Petri Helenius" <[EMAIL PROTECTED]>
Cc: "Lars Eggert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 18, 2002 7:49 AM
Subject: RE: ENOBU
--Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:owner-freebsd-net@;FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > Sent: Thursday, October 17, 2002 11:12 PM
> > To: Petri Helenius
> > Cc: Lars Eggert; [EMAIL PROTECTED]
> > Subject: Re: ENOBUFS
>
002 11:12 PM
> To: Petri Helenius
> Cc: Lars Eggert; [EMAIL PROTECTED]
> Subject: Re: ENOBUFS
>
>
> On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> ...
> > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
>
> just reading the s
On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
...
> I seem to get about 5-6 packets on an interrupt. Is this tunable? At
just reading the source code, yes, it appears that the card has
support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
and usage in sys/dev/em/*
>
> Less :-) Let me tell you tomorrow, don't have the numbers here right now.
I seem to get about 5-6 packets on an interrupt. Is this tunable? At
50kpps the card generates 10k interrupts a second. Sending generates
way less. This is about 300Mbps so with the average packet size of
750 there shoul
> Sam Leffler wrote:
> > Try my port of the netbsd kttcp kernel module. You can find it at
> >
> > http://www.freebsd.org/~sam
>
> this seems to use some things from netbsd like
> so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK.
> Is there something else I need to apply to build it on
> fr
Sam Leffler wrote:
> Try my port of the netbsd kttcp kernel module. You can find it at
>
> http://www.freebsd.org/~sam
this seems to use some things from netbsd like
so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK.
Is there something else I need to apply to build it on
freebsd -STABLE?
> > The 900Mbps are similar to what I see here on similar hardware.
>
> What kind of receive performance do you observe? I haven´t got that
> far yet.
> >
> > For your two-interface setup, are the 600Mbps aggregate send rate on
> > both interfaces, or do you see 600Mbps per interface? In the latte
On Wed, Oct 16, 2002 at 08:57:19AM +0300, Petri Helenius wrote:
> >
> > how large are the packets and how fast is the box ?
>
> Packets go out at an average size of 1024 bytes. The box is dual
> P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled
yes, it qualifies as fast. With
Petri Helenius wrote:
>>The 900Mbps are similar to what I see here on similar hardware.
>
> What kind of receive performance do you observe? I haven´t got that
> far yet.
Less :-) Let me tell you tomorrow, don't have the numbers here right now.
> 600Mbps per interface. I´m going to try this out
> The 900Mbps are similar to what I see here on similar hardware.
What kind of receive performance do you observe? I haven´t got that
far yet.
>
> For your two-interface setup, are the 600Mbps aggregate send rate on
> both interfaces, or do you see 600Mbps per interface? In the latter
600Mbps pe
Petri Helenius wrote:
>>how large are the packets and how fast is the box ?
>
>
> Packets go out at an average size of 1024 bytes. The box is dual
> P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled
> hyperthreading to figure out if it was causing problems. I seem to
> be able
>
> how large are the packets and how fast is the box ?
Packets go out at an average size of 1024 bytes. The box is dual
P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled
hyperthreading to figure out if it was causing problems. I seem to
be able to send packets at a rate in the
Petri Helenius wrote:
>>Probably means that your outgoing interface queue is filling up.
>>ENOBUFS is the only way the kernel has to tell you ``slow down!''.
>>
>
> How much should I be able to send to two em interfaces on one
> 66/64 PCI ?
I've seen netperf UDP throughputs of ~950Mpbs with a fi
On Wed, Oct 16, 2002 at 02:04:11AM +0300, Petri Helenius wrote:
> >
> > What rate are you sending these packets at? A standard interface queue
> > length is 50 packets, you get ENOBUFS when it's full.
> >
> This might explain the phenomenan. (packets are going out bursty, with average
> hovering a
>
> Probably means that your outgoing interface queue is filling up.
> ENOBUFS is the only way the kernel has to tell you ``slow down!''.
>
How much should I be able to send to two em interfaces on one
66/64 PCI ?
Pete
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
>
> What rate are you sending these packets at? A standard interface queue
> length is 50 packets, you get ENOBUFS when it's full.
>
This might explain the phenomenan. (packets are going out bursty, with average
hovering at ~500Mbps:ish) I recomplied kernel with IFQ_MAXLEN of 5000
but there seems
On Wed, 16 Oct 2002, Petri Helenius wrote:
>
> My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
> while netstat -s counter under the heading of "ip" is incrementing:
> 7565828 output packets dropped due to no bufs, etc.
> but netstat -m shows:
my guess is that the inter
Petri Helenius wrote:
> My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
> while netstat -s counter under the heading of "ip" is incrementing:
> 7565828 output packets dropped due to no bufs, etc.
What rate are you sending these packets at? A standard interface queue
lengt
On Tue, 25 Sep 2001, Jeff Behl wrote:
> Any other guidelines to help tune a FreeBSD box for this sort of use
> would be greatly appreciated. Currently, the only change we make is
> increasing MAXUSERS to 128, though I'm not sure this is the preferred
> approach.
That's the simplest approach, a
39 matches
Mail list logo
