On Thu, 29 Nov 2001, Luigi Rizzo wrote:
> The call to update_poll_threshold() however needs to be done by
> either hardclock() or statclock() (i am experimenting with that
> right now) because the purpose is to sample what the CPU is doing
> when we get that particular interrupt.
Why in that par
In article
[EMAIL PROTECTED]> you
write:
>-=-=-=-=-=-
>test4 was the only trace I looked at. One thing that caught my eye is
>that the receiver seems to be sending a bunch of dupacks (in some cases,
>many more than needed to trigger fast retransmit) but no retransmit
>happens. In *most* cases,
> > Matthew Emmerton wrote:
> > >
> > > Hi all,
> > >
> > > In the continuing saga of IPSec over PPPoE for a retail POS
environment that
> > > I'm maintaing, the problems seem to become more complex as time goes
on.
> > >
> > > The network is quite simple:
> > > [ LAN #1 ] - [ FreeBSD Gateway #1 ]
OK, I think this time around I have fixed the duplex issues and the problem
with the D-link not being initialized properly (reset PCI config data in
the BIOS fixed a the problems).
Using netperf I ran the basic snapshot script to see what affect the
polling code had on network performance. I
If memory serves me right, Garrett Wollman wrote:
> Each trace shows a single large file transfer from a 4.4-stable
> machine to my -current desktop over a local-area network.
I'm pretty rusty at debugging TCP implementations, but I'll try to
contribute something...
Your 4.4-STABLE machine,
On Thursday, November 29, 2001, at 05:01 , Ahsan Ali wrote:
>> For TCP, that is what is always used by default when creating an
>> outbound connection. For incoming connections, the machine will of
>> course reply using the IP address the connection came in on. And a
>> program can always reques
On Thu, Nov 29, 2001 at 06:01:04PM +0500, Ahsan Ali wrote:
> > For TCP, that is what is always used by default when creating an
> > outbound connection. For incoming connections, the machine will of
> > course reply using the IP address the connection came in on. And a
> > program can always reque
On Thu, Nov 29, 2001 at 03:38:19PM +, Kris Kirby wrote:
>
> What's our current best recommended solution for channel-bonding ethernet
> cards? Netgraph?
http://people.freebsd.org/~wpaul/FEC/
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS
On Thu, Nov 29, 2001 at 11:27:50AM -0600, Jonathan Lemon wrote:
>
> All the various #ifdefs scattererd over the code are absolutely sick;
> they fairly scream out for a sensible rewrite. However, from my point
> of view, if I'm going to rewrite things, there should be functional
> improvements a
On Thu, Nov 29, 2001 at 08:30:06AM -0800, Luigi Rizzo wrote:
> On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> > On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > > Thanks...I know where my problem is now...It's indeed a duplicate SYN.
> > >
> > > By the way, the tcp
On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > Thanks...I know where my problem is now...It's indeed a duplicate SYN.
> >
> > By the way, the tcp_input function is so long and large and there are
> > several goto sta
On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> Thanks...I know where my problem is now...It's indeed a duplicate SYN.
>
> By the way, the tcp_input function is so long and large and there are
> several goto statements which make reading the code even more difficult. Is
> this intened
What's our current best recommended solution for channel-bonding ethernet
cards? Netgraph?
-
Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said.
<[EMAIL PROTECTED]> | IM: KrisBSD
---
"Fate, it seems, is not without a sense of irony."
* Tariq Rashid <[EMAIL PROTECTED]> [011129 08:04] wrote:
>
> as recognised in the ports bug report, the isakmpd port for freebsd soaks
> up 99% CPU even when no connections have been established - even when in
> completely passive-connection mode.
>
> i'm not an expert coder but i think the sel
Bruce, thanks for the feedback.
Re. the second issue:
the code was placed in kern_clock.c just as a placeholder (and
because i needed to touch a couple of places in that file, i tried
to minimize the number of files affected by the patch). But surely,
the core of the code can go somewhere else,
as recognised in the ports bug report, the isakmpd port for freebsd soaks
up 99% CPU even when no connections have been established - even when in
completely passive-connection mode.
i'm not an expert coder but i think the select() in the main loop (isakmpd.c
main()) is doing this.
is there a
> For TCP, that is what is always used by default when creating an
> outbound connection. For incoming connections, the machine will of
> course reply using the IP address the connection came in on. And a
> program can always request to use a specific address if it wants to.
>
> I am not sure wher
> On Mon, 26 Nov 2001, Luigi Rizzo wrote:
>
> > [Bcc to -stable in case someone is interested there]
> >
> > Attached you can find the latest version of the polling code
> > for STABLE (which is useful to make boxes much more robust
> > to attacks and have much better responsiveness under [over]lo
On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> Thanks...I know where my problem is now...It's indeed a duplicate SYN.
>
> By the way, the tcp_input function is so long and large and there are
> several goto statements which make reading the code even more difficult. Is
> this intened
On Wed, Nov 28, 2001 at 04:52:59PM -0800, Crist J. Clark wrote:
> On Wed, Nov 28, 2001 at 12:31:09PM -0500, Garrett Wollman wrote:
> > <
>said:
> >
> > > Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
> > > understands dotted quads. The comments in src/lib/libc/net/inet_pt
20 matches
Mail list logo
