On Fri, 1 Nov 2002, Luigi Rizzo wrote:
> /sys/netinet/in.h contains a huge macro, CTL_IPPROTO_NAMES, which
> maps to an array containing protocol names.
> As far as i can tell (find /usr/src | xargs grep CTL_IPPROTO_NAMES)
> it is not used anywhere in the source tree.
All CTL_*_NAMES for sysctl a
> Time to default net.inet.tcp.slowstart_flightsize to 4?
A straight initial window of 4 is too big. I have patches lying around
that varies the initial window size from 2 to 4 depending on the MSS,
as specified in the RFC.
Jeffrey
To U
[EMAIL PROTECTED] wrote:
A new Request for Comments is now available in online RFC libraries.
RFC 3390
Title: Increasing TCP's Initial Window
Author(s): M. Allman, S. Floyd, C. Partridge
Status: Standards Track
Date: October 2002
U
I have committed Bill Paul's Cisco compatible FEC
interface code (for bundling several interfaces together.
However despite teh fact that it is a netgraph node it was
written in a completely netgraph incompatible manner..
To use this node you must NOT have compiled into your kernel, or
have kld
Hi,
/sys/netinet/in.h contains a huge macro, CTL_IPPROTO_NAMES, which
maps to an array containing protocol names.
As far as i can tell (find /usr/src | xargs grep CTL_IPPROTO_NAMES)
it is not used anywhere in the source tree.
Any objection to nuke it ?
Besides being unused, it is extremely ugly an
> From: David Myer [mailto:davidmyer800@;yahoo.com]
> Just curious on one thing, we know that SYN packet can
> carry data payload, but I never see any implementation
> that actually does this.
See T/TCP, RFC 1644, and sysctl 'net.inet.tcp.rfc1644'
--don ([EMAIL PROTECTED] www.sandvine.com)
To Un
Hi,
Just curious on one thing, we know that SYN packet can
carry data payload, but I never see any implementation
that actually does this. Nor have I seen code that
checks or handles this in receive function. Is there a
reason NOT doing so ?
Thanks
DM
_
Try retrieving a very large file via ftp. The sendfile() code seems
more efficient than ttcp, and if performance improves that may be
a clue that the problem lies in the user/kernel interface. If not,
probably in the stack. Could it conceivably be a resonance effect
between the actual rtt and th
Archie Cobbs <[EMAIL PROTECTED]> wrote on 01-11-02 20:30:11:
>
>Julian Elischer writes:
>> > >to enable forwarding of broadcast packets across any point-to-point
>> > >links whos local address lies on the broadcast subnet.
>> > >
>> > >If what you're really trying to solve is NBNS, use a WINS serve
Julian Elischer writes:
> > >to enable forwarding of broadcast packets across any point-to-point
> > >links whos local address lies on the broadcast subnet.
> > >
> > >If what you're really trying to solve is NBNS, use a WINS server.
>
> Archie, didn't we do something for this on the interjet?
Ye
> Are you sure you're not hitting the top of the pipe and bouncing
> around in congestion avoidance ? Unless your window size limits
> your bw at exactly the correct amount, you'll never get the steady
> state
We're not bouncing around. We see no loss, which would indicate
that either we should
> > From: Mark Allman [mailto:mallman@;grc.nasa.gov]
> > Thanks! Other ideas?
>
> What MSS is advertised on each end?
1500 byte packets (from looking at the trace file).
allman
--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
To Unsubscribe: send mail to [EMAIL PROTECT
> From: Mark Allman [mailto:mallman@;grc.nasa.gov]
> Thanks! Other ideas?
What MSS is advertised on each end?
--don ([EMAIL PROTECTED] www.sandvine.com)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Are you sure you're not hitting the top of the pipe and bouncing
around in congestion avoidance ? Unless your window size limits
your bw at exactly the correct amount, you'll never get the steady state
bw you want.
Mark Allman wrote:
> > Have you checked that both sides are negotiating SACK?
>
> Have you checked that both sides are negotiating SACK?
No SACK in 4.1. But, there is no loss in th connection.
> And both sides are negotiating a window scale option sufficiently
> large? (sounds like you need a window scale option of at least 5
> bits?)
We're seeing a shift of 6.
> And the
> From: Fran Lawas-Grodek [mailto:Fran.Lawas-Grodek@;grc.nasa.gov]
> Well... our development code that we are to ultimately test was
> developed on 4.1, thus we really need to try to stick with 4.1.
> It does not look like either of the above parameters are available
> until 4.7.
No worries.
Have
On Fri, Nov 01, 2002 at 11:18:50AM -0500, Don Bowman wrote:
>
> Perhaps
> sysctl net.inet.tcp.inflight_enable=1
> will help?
>
> you may wish to also change tcp.inflight_max.
> See tcp(4) as of 4.7.
Hello Don,
Well... our development code that we are to ultimately test was
developed on 4.1, th
Hello Bakul,
Your suggestion of increasing the -l seems to have made a positive
impact -- tests this morning with a higher buffer length size of 8192
gave us a better throughput of 44Mbps. Now the time sequence plot
shows a window usage of 1.5MB as opposed to the previous 1MB usage.
We still don'
> From: Fran Lawas-Grodek [mailto:Fran.Lawas-Grodek@;grc.nasa.gov]
Perhaps
sysctl net.inet.tcp.inflight_enable=1
will help?
you may wish to also change tcp.inflight_max.
See tcp(4) as of 4.7.
--don ([EMAIL PROTECTED] www.sandvine.com)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
These are our sysctl settings:
kern.ipc.maxsockbuf=4194304
net.inet.tcp.sendspace=3125000
net.inet.tcp.recvspace=3125000
net.inet.ip.intr_queue_maxlen=500
nmbclusters=32768
After reading your suggestion, we were able to achieve a
slightly better throughput from 32Mbps on the 250ms delayed
ne
Archie Cobbs <[EMAIL PROTECTED]> wrote on 01-11-02 00:14:06:
>
>Thomas Gielfeldt writes:
>> So you probably have to filter via netgraph?
>
>This can be done with ng_bpf(4).
>
>-Archie
>
>__
>Archie Cobbs * Packet Design
On Fri, 1 Nov 2002, Thomas Gielfeldt wrote:
> Archie Cobbs <[EMAIL PROTECTED]> wrote on 01-11-02 00:19:19:
[...]
> >
> >to enable forwarding of broadcast packets across any point-to-point
> >links whos local address lies on the broadcast subnet.
> >
> >If what you're really trying to solve is NB
Archie Cobbs <[EMAIL PROTECTED]> wrote on 01-11-02 00:19:19:
>
>Thomas Gielfeldt writes: [reformatted to 80 columns]
>> I'm still tampering with VPN and I want to say thanks for the advice
>> I've gotton from here and elsewhere. Now I'm trying to connect a
>> Win2k client to my internal network th
23 matches
Mail list logo
