You might want to check out
http://alpine.cs.washington.edu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> one of them is the (relatively high) interrupt overhead
> as reported by many. There is a good description of the problem
> in the Click's paper at http://www.pdos.lcs.mit.edu/click/ and
> in the Mogul's paper referenced in there.
> The advantage of this approach is that you don't hav
> Some versions of the 21143 have a "interrupt mitigation" register
> which acts more or less as the VMIN/VTIME termios fields.
> But the 21143 is hard to find these days, and it is the
> only one i know with this feature.
Both the Alteon Tigon II (if_ti) and the National Semiconductor (
You may have run into the sequence number went backwards problem.
Try the recent patch by silby.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Rate-halving is implemented in the PSC version of SACK. Perhaps
we should take a look at that?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
What does netstat -s say?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> The UDP "dropped due to full socket buffers" increases with time
This is on the receiving machine, right? It looks like the application
isn't reading the buffer. Do a 'ps l' on the application and look at the
WCHAN to see if the application is running or waiting for something.
To Unsubscr
> 1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls
>ends up calling vm_map_entry_create(). vm_map_entry_create() calls
>uma_zalloc() with M_WAITOK.
Alan Cox and Tor Egge just fixed this in -current in rev 1.247 of vm_map.c.
To Unsubscribe: send mail to [EM
> does anyone know if FreeBSD is safe for having multiple processes do
> accept() on the same listenning socket?
I wrote a program on FreeBSD several years ago that does exactly this with
multiple rforked child processes. In fact, someone recompiled my program
on FreeBSD 4.5 last month to mo
So, what you want is something like a
MGETHCL(m, how, type)
MHCLFREE(m)
interface which first looks in a combined freelist before the individual
mbuf and cluster freelists. I think it's a good idea.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in
> > So, what you want is something like a
> > MGETHCL(m, how, type)
> > MHCLFREE(m)
> > interface which first looks in a combined freelist before the individual
> > mbuf and cluster freelists. I think it's a good idea.
>
> I would prefer to see an interface that just grabs b
> The side effect of having some source-files using the _IP_VHL hack and
> some not is that sizeof(struct ip) varies from file to file, which at
> best is confusing an at worst the source of some really evil bugs.
> I would therefore propose to eliminate the _IP_VHL hack from the kernel
> We recently published a book on the KAME implementation
Sounds great! I'll be sure to check it out at the bookstore.
> We would like to thank the FreeBSD community for helping
> making this book possible. In particular (and in no particular
> order), we'd like to thank the developers S
> 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
>> I have patches lying around
>> that varies the initial window size from 2 to 4 depending on the MSS,
>> as specified in the RFC.
> We could not apply those patches until we fix a bug serverside which
> increments snd_cwnd with 1 mss somewhere...
> Take a look on TCP session.
No, no
rtentry will get its own lock.
The roadmap for locking up the IP stack looks like roughly like ifaddr
ref counts, ifnet list, routing radix tree, ARP, ifaddr uses, and rtentry.
I'm a little over 3/5 of the way done along this path.
Jeffrey
if (rt->rt_flags & RTF_GATEWAY) /* XXX
How can we be sure that rt won't be freeed by
any other kernel thread now ??
XXX */
> Why is rt_refnt decreased so early and not later ?
In the non-SMP kernel, the kernel can't be preempted so anothe
It's high up on my list of things to do, after locking up the
networking stack, fixing NewReno, and adding hardware TCP segmentation
off-loading.
Jeffrey
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the b
> It seems like
> several variables are locked for the vast majority of the time in
> tcp_input().
inp, in particular, should be locked the entire time in tcp_input, so you
are always going to have your "could sleep with lock held" problem unless
you add M_NOWAIT to your calls to malloc() or
> I have been looking on this delta. I had been stuck on the handlers of the
> "user requests" ( xxx_usrreq() ) that are deeply different between NetBSD
> and FreeBSD.
The old pr_usrreq routine used to be a big switch statement on the second
parameter, the request type. Now, each case is a
> I have chosen to use the sysctl interface for my initial
> implementation. So far this is working out well, I am reading 4 variables
> about each connection via sysctl. Is sysctl the right way to get this
> information?
Yes, last time I looked at the Web100 project, I thought sysctl w
> Note that the IP length field must be in host byte order
Historically, BSD-derived systems have always had the length and offset fields
in host byte order.
Jeffrey
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebs
You could try adjusting the net.inet.tcp.msl sysctl down from its default
of 30 seconds.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> net.inet.tcp.sendspace: 1024
This will kill your send performance. Try raising it to 32 or 64k.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>> I know that our organization would love to see SACK. Much of the
>> high-performance network development that used to be on FreeBSD has
>> moved to Linux simply because SACK is essential. You can't run
>> trans-oceanic TCP streams of gigabit or more throughput without it.
>
> Wheneve
25 matches
Mail list logo
