A little progress.
I have a machine with a KTR enabled kernel running.
Another machine is running David's ffs_vfsops.c's patch.
I left two other machines (GENERIC kernels) running the packet loss test
overnight. At ~ 32480 seconds of uptime the problem starts. This is
really
close to a 16 b
Thanks to each of you.
On Dec 18, 2007, at 4:55 AM, Andre Oppermann wrote:
Lawrence Stewart wrote:
Hi all,
We've been involved in a research project to implement and test an
emerging TCP congestion control algorithm under FreeBSD. As a part of
this, we've put together a patch for FreeBSD 7.0-B
> > I got an almost identical delay (with 64000 vnodes).
> >
> > Now, 17ms isn't much.
>
>Says you. On modern systems, trying to run a pseudo real-time application
> on an otherwise quiescent system, 17ms is just short of an eternity. I agree
> that the syncer should be preemptable (which is
Andrey V. Elsukov wrote:
Krishna Kumar wrote:
Is this in the list of todo's??
Can this feature not be supported due to design issues?
Is somebody trying this out somewhere?
Please do copy me on the reply as I am not subscribed to the list.
Look into freebsd-hackers@ mail archive. In the previo
> > tcpdump on rl0 still nothing.
>
> After reading this I feel that you have absolutely no packets on
> either interfaces when your Linux box ping FreeBSD. But this
> contradicts with your previous assertion that if ICMP packet comes
> in on rl1, then it is reflected at rl0. Am I missing someth
> I got an almost identical delay (with 64000 vnodes).
>
> Now, 17ms isn't much.
Says you. On modern systems, trying to run a pseudo real-time application
on an otherwise quiescent system, 17ms is just short of an eternity. I agree
that the syncer should be preemptable (which is what my bandai
On Tue, 18 Dec 2007, David G Lawrence wrote:
I didn't say it caused any bogus disk I/O. My original problem
(after a day or two of uptime) was an occasional large scheduling delay
for a process that needed to process VoIP frames in real-time. It was
happening every 31 seconds and was causing v
Rui Paulo
At Tue, 18 Dec 2007 13:55:20 +0100,
Andre Oppermann wrote:
>
> Lawrence Stewart wrote:
> > Hi all,
> > We've been involved in a research project to implement and test an
> > emerging TCP congestion control algorithm under FreeBSD. As a part of
> > this, we've put together a patch for Fre
> On Tue, 18 Dec 2007, David G Lawrence wrote:
>
> >>Thanks. Have a kernel building now. It takes about a day of uptime
> >>after reboot before I'll see the problem.
> >
> > You may also wish to try to get the problem to occur sooner after boot
> >on a non-patched system by doing a "tar cf /dev
On Tue, 18 Dec 2007, David G Lawrence wrote:
Thanks. Have a kernel building now. It takes about a day of uptime
after reboot before I'll see the problem.
You may also wish to try to get the problem to occur sooner after boot
on a non-patched system by doing a "tar cf /dev/null /" (note: su
> Thanks. Have a kernel building now. It takes about a day of uptime
> after reboot before I'll see the problem.
You may also wish to try to get the problem to occur sooner after boot
on a non-patched system by doing a "tar cf /dev/null /" (note: substitute
/dev/zero instead of /dev/null, i
Good day.
Fri, Dec 14, 2007 at 11:58:45AM +0100, vermaden wrote:
> > Fri, Dec 14, 2007 at 11:20:32AM +0100, vermaden wrote:
> > > I already used tcpdump, if ICMP packet goes in thru 192.168/16 on rl1
> > the
> > > response goes out on 10/24 on rl0.
Fri, Dec 14, 2007 at 11:58:45AM +0100, vermaden
> >Right, it's a non-optimal loop when N is very large, and that's a fairly
> >well understood problem. I think what DG was getting at, though, is
> >that this massive flush happens every time the syncer runs, which
> >doesn't seem correct. Sure, maybe you just rsynced 100,000 files 20
> >seconds
Lawrence Stewart wrote:
Hi all,
We've been involved in a research project to implement and test an
emerging TCP congestion control algorithm under FreeBSD. As a part of
this, we've put together a patch for FreeBSD 7.0-BETA4 that modularises
the congestion control code in the TCP stack. It allows
The following reply was made to PR kern/112654; it has been noted by GNATS.
From: "Nagy Keve" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a
Netfinity 5000
Date: Tue, 18 Dec 2007 13:30:31 +0100
Src synced
On Mon, 17 Dec 2007, Scott Long wrote:
Bruce Evans wrote:
On Mon, 17 Dec 2007, David G Lawrence wrote:
One more comment on my last email... The patch that I included is not
meant as a real fix - it is just a bandaid. The real problem appears to
be that a very large number of vnodes (all of
Hi all,
We've been involved in a research project to implement and test an
emerging TCP congestion control algorithm under FreeBSD. As a part of
this, we've put together a patch for FreeBSD 7.0-BETA4 that modularises
the congestion control code in the TCP stack. It allows for new
congestion contr
18.12.07 @ 17:21 Sergey Matveychuk wrote:
I've recently found a patch (also available at
http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend
in January to ipfwpcap(8) introduced in 7.0. Now it have more features,
Unfortunately too old to apply.
Mislooked that, sorry. B
Vadim Goncharov wrote:
Hi,
I've recently found a patch (also available at
http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend
in January to ipfwpcap(8) introduced in 7.0. Now it have more features,
Unfortunately too old to apply.
And using of pidfile_* functions from libu
On Mon, 17 Dec 2007, Mark Fullmer wrote:
Thanks. Have a kernel building now. It takes about a day of uptime after
reboot before I'll see the problem.
Yes run "find / >/dev/null" to see the problem if it is the syncer one.
At least the syscall latency problem does seem to be this. Under ~5.
Hi,
I found the pages, but the WOL patch is not present for Broadcom chipsets
(BCM57XX).
I am struck at point where I am confused as to why it does not work if it
works with my operating system (linux based micro kernel).
Somebody working on this? In case yes, I can surely be of help.
Thanks,
K
Hi,
I've recently found a patch (also available at
http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend in
January to ipfwpcap(8) introduced in 7.0. Now it have more features, some
of which were already present in pflogd(8) counterpart. Patched version
were tested in abo
22 matches
Mail list logo
