Re: inet_pton(3) Does Not Replace inet_aton(3)
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_pton.c > > > clearly show this is the intended behavior. But is that what we want? > > > > Yes. The old format is deprecated, obsolete, legacy, however you want > > to put it. > > OK. But I think it should be documented. > > Index: inet.3 > === > RCS file: /export/ncvs/src/lib/libc/net/inet.3,v > retrieving revision 1.19 > diff -u -r1.19 inet.3 > --- inet.31 Oct 2001 16:08:55 - 1.19 > +++ inet.329 Nov 2001 00:47:28 - > @@ -203,6 +203,14 @@ > otherwise, the number is interpreted as decimal). > .Pp > The > +.Fn inet_pton > +function only understands Internet addresses written as dotted quads. > +Each > +.Dq part > +may only contain numeric characters and is always interpreted as a > +decimal value. > +.Pp > +The > .Fn inet_aton > and > .Fn inet_ntoa > Um, don't we already have this documented in the STANDARDS section? Though I liked POSIX.1-200x text more. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
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 to be like this? Even with Steven's TCP/IP Vol.2, it took me > three whole days to draw a Visio flow chart of this function. Has anybody > ever considered of reorganizing this module? Any chance that you could release the chart as a graphic to the community? I'd be interested to see that. Joe msg04168/pgp0.pgp Description: PGP signature
Re: netmask for aliased ip
> 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 where you see a problem. What I am saying is that if you have (for instance) 192.168.0.0/24 as a network. Interface A has the IP 192.168.0.10 with a netmask of 255.255.255.0 (/24) Alias A:1 has the IP 192.168.0.11 with a netmask of 255.255.255.255 (/32) Now Host B (192.168.0.20 mask 255.255.255.0) tries to access Alias A:1 which is 192.168.0.11/32 so B sends to A:1 which it (correctly) assumes to be on its own network, Alias A:1 cannot however reach B without sending the data to its configured gateway. If routing is enabled on this host then it may be able to send the reply routed through Interface A only... My point is, that if the aliased interface also had a class c mask, this issue wouldn't have come up in the first place when considering local (within the same subnet) access from other hosts on that network. I know this sounds really obfusticating! :) But I'm just trying to get my concepts sorted out too. -Ahsan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
isakmpd hogs CPU: select()?
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 difference between openbsd select() and freebsd 4.4R select()? i've ported over the latest isakmpd from openbsd and this is still the case... anyone? regards tariq --- Information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient any use, disclosure, copying or distribution of this message is prohibited and may be unlawful. When addressed to our customers, any information contained in this message is subject to Intelligent Network Technology Ltd Terms & Conditions. --- Take part in the intY 2001 Email Usage survey online at http://www.inty.net/email/survey.html --- intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: isakmpd hogs CPU: select()?
* 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 select() in the main loop (isakmpd.c > main()) is doing this. > > is there a difference between openbsd select() and freebsd 4.4R select()? > > i've ported over the latest isakmpd from openbsd and this is still the > case... > > anyone? truss(1) output might help, along with the code in question, along with what type of descriptors it's polling. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Etherchannel emulation / channel bonding?
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." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
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 to be like this? Even with Steven's TCP/IP Vol.2, it took me > three whole days to draw a Visio flow chart of this function. Has anybody > ever considered of reorganizing this module? I don't believe so; the code was originally designned to avoid function calls, and is essentially a couple of large switch statements. The flow pretty much mirrors the original RFC, and shouldn't be too hard to follow. I'd be leery of rewriting the code just for the sake of rewriting; chances would be pretty good that you'd introduce a subtle bug in one way or the other. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
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 statements which make reading the code even more difficult. Is > > this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me > > three whole days to draw a Visio flow chart of this function. Has anybody > > ever considered of reorganizing this module? > > I don't believe so; the code was originally designned to avoid function > calls, and is essentially a couple of large switch statements. The flow > pretty much mirrors the original RFC, and shouldn't be too hard to follow. let's be honest, it's a horrible piece of code from a sw engineering point of view. > I'd be leery of rewriting the code just for the sake of rewriting; chances > would be pretty good that you'd introduce a subtle bug in one way or the > other. on the other hand, chances are that there are already subtle bugs with all the modifications that have been applied these years (TTCP, newreno etc.). No later than yesterday there was a long thread on this issue, and Garret has also some traces which according to him evidence patologies. You have been there, Jonathan, so you should known well how hard is to make even small modifications to the existing code without being afraid of breaking a lot of things. I think a rewrite of FreeBSD's TCP would be extremely needed and welcome, however is such a large effort that i doubt anyone has the time and energy to dedicate to this task. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
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_input function is so long and large and there are > > > several goto statements which make reading the code even more difficult. Is > > > this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me > > > three whole days to draw a Visio flow chart of this function. Has anybody > > > ever considered of reorganizing this module? > > > > I don't believe so; the code was originally designned to avoid function > > calls, and is essentially a couple of large switch statements. The flow > > pretty much mirrors the original RFC, and shouldn't be too hard to follow. > > let's be honest, it's a horrible piece of code from a sw engineering > point of view. No argument there. > > I'd be leery of rewriting the code just for the sake of rewriting; chances > > would be pretty good that you'd introduce a subtle bug in one way or the > > other. > > on the other hand, chances are that there are already > subtle bugs with all the modifications that have been applied > these years (TTCP, newreno etc.). No later than yesterday there was > a long thread on this issue, and Garret has also some traces which > according to him evidence patologies. Yes, I'm currently digging into those traces now. :-( > You have been there, Jonathan, so you should known well how hard is > to make even small modifications to the existing code without > being afraid of breaking a lot of things. > > I think a rewrite of FreeBSD's TCP would be extremely needed and welcome, > however is such a large effort that i doubt anyone has the time and energy > to dedicate to this task. Well, I do have designs on making things better; but as you point out, before anyone should even think about changing things, they need a good understanding of how the code works. Wrapping your head around the entire TCP/IP stack is not an easy task and I'm not even going to claim that I've successfully done this. :-) 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 as well, not just rearranging what we have in a different fashion. I don't feel quite ready for this... yet. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
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 as well, not just rearranging what we have in a different > fashion. I don't feel quite ready for this... yet. functional can be also interpreted as "easier to read and validate" which seems to be one of the main drawbacks of the current code. I'd even be willing to pay the price of a small regression in functionality, on the grounds that it is better to know that "X is not implemented" than "X, Y, Z are implemented but we have no idea if they work in all cases, and no way to test". As a matter of fact, that would be an improvement, not a regression. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Etherchannel emulation / channel bonding?
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 @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netmask for aliased ip
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 request to use a specific address if it wants to. > > > > I am not sure where you see a problem. > > What I am saying is that if you have (for instance) 192.168.0.0/24 as a > network. > > Interface A has the IP 192.168.0.10 with a netmask of 255.255.255.0 (/24) > Alias A:1 has the IP 192.168.0.11 with a netmask of 255.255.255.255 (/32) > > Now Host B (192.168.0.20 mask 255.255.255.0) tries to access Alias A:1 which > is 192.168.0.11/32 so B sends to A:1 which it (correctly) assumes to be on > its own network, Alias A:1 cannot however reach B without sending the data > to its configured gateway. If routing is enabled on this host then it may be > able to send the reply routed through Interface A only... Hmmm? Routing is always enabled if you plan on talking to any other machines at all. But all of this is a non-issue. The selection of a route for a packet has _nothing_ to do with the source address, only the destination. How a packet finds its way to 192.168.0.20 is the same no matter what the source address is. 192.168.0.20 is local to the interface A, so it is sent directly to B. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netmask for aliased ip
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 request to use a specific address if it wants to. >> >> I am not sure where you see a problem. > > What I am saying is that if you have (for instance) 192.168.0.0/24 as a > network. > > Interface A has the IP 192.168.0.10 with a netmask of 255.255.255.0 > (/24) > Alias A:1 has the IP 192.168.0.11 with a netmask of 255.255.255.255 > (/32) > > Now Host B (192.168.0.20 mask 255.255.255.0) tries to access Alias A:1 > which > is 192.168.0.11/32 so B sends to A:1 which it (correctly) assumes to be > on > its own network, Alias A:1 cannot however reach B without sending the > data > to its configured gateway. If routing is enabled on this host then it > may be > able to send the reply routed through Interface A only... I think you are confusing interfaces and addresses. In your case, B will want to send to ...11 (it doesn't see the mask that's installed on A), so it will ARP for it, and A will reply. B then sends the packet to A's MAC address (which is the same for both the original and the aliased address). When A replies to B, it will send to B through the same physical interface through which B's packet arrived. There's no issue with reachability: both systems, and all three addresses, are on the same link. The netmask tom-foolery is just a local-to-the-system-installing-the-alias trick; it has nothing to do with the on-the-wire behavior, or how the remote site sees the site installing the alias. With a /32 mask, the system can keep track of the various addresses without a lot of routing tricks which would otherwise be necessary (more work for the admin to install and remove aliases). It is confusing, but it has to do with the way the routing infrastructure works on *BSD systems, not with the way networking works in general. Regards, Justin --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| It's not whether you win or lose... | It's whether *I* win or lose. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Revised polling code for STABLE
> 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]load). > > ... > Index: sys/i386/i386/swtch.s > === > RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/swtch.s,v > retrieving revision 1.89.2.4 > diff -u -r1.89.2.4 swtch.s > --- sys/i386/i386/swtch.s 2001/07/26 02:29:10 1.89.2.4 > +++ sys/i386/i386/swtch.s 2001/10/26 21:54:19 > @@ -246,6 +246,17 @@ > call_procrunnable > testl %eax,%eax > CROSSJUMP(jnz, sw1a, jz) > +#ifdef XORP_ETHER_POLLING > + incl_idle_done > + pushl _poll_burst > + call_ether_poll > + addl$4,%esp > + sti > + nop > + cli > + testl %eax, %eax > + jnz idle_loop > +#endif > call_vm_page_zero_idle > testl %eax, %eax > jnz idle_loop This has some serious bugs: (1) ether_poll() is called with interrupts disabled. This breaks fast interrupt handlers. ether_poll() uses splimp() so it is apparently not intended to run with priority higher than splhigh(). (2) The sti/cli stuff belongs in ether_poll(), and the test of the return code of ether_poll() only works because ether_poll() always returns 1. vm_page_zero_idle() and the hlt instruction are never reached and the system spins calling ether_poll() from idle until a process becomes runnable. ether_poll() needs quite different handling than vm_page_zero_idle() since it can reasonably find something to do whenever an interface is up, while vm_page_zero_idle() soon runs out of things to do if it is called a lot. > Index: sys/kern/kern_clock.c It shouldn't be necessary to touch this file. Everything involving "ether" certainly doesn't belong here. Everything related to periodic polling can be done, probably more efficiently, using schedsoft*() or timeout(). E.g., schedsoftnet() arranges for netisrs to be checked for at the next clock interrupt. But this can now be done almost as well (probably better in -current) using an ordinary timeout. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Revised polling code for STABLE
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, e.g. in net/
(i have had it for a long time in if_ethersubr.c), or maybe
even in a separate file, as you like.
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.
I do not know how/if I can replace the schednetisr() with an ordinary timeout:
i need the handler to be invoked as soon as possible after the
clock ticks, as the task it performs are as urgent as interrupt requests.
Certainly I do not want it to be run after other netisr handlers
(this is also why NETISR_POLL is lower than any other NETISR, so
the corresponding handler is called first).
It looked like the schednetisr() was the simplest (one-line change) and
more effective way to achieve this, if you know of other ways involving
timeouts please let me know.
Re. the first one, yes the code might probably benefit from
a bit of rearrangement, such as below
#ifdef XORP_ETHER_POLLING
call_idle_poll
#else
call_vm_page_zero_idle
#endif
testl %eax, %eax
jnz idle_loop
with idle_poll being
int idle_poll() {
{
idle_done=1;
if (poll_handlers > 0) {
int s = splimp();
__asm __volatile("sti" : : : "memory");
retval = ether_poll(poll_burst);
__asm __volatile("cli" : : : "memory");
splx(s);
vm_page_zero_idle();
return 1;
} else
return vm_page_zero_idle();
}
The thing is, with polling you cannot halt the CPU if there are handlers
registered for polling. You can try and deregister polling on
interfaces which are idle, which then should be handled correctly
by the above function.
Does the above make sense ?
cheers
luigi
On Thu, Nov 29, 2001 at 11:26:20PM +1100, Bruce Evans wrote:
> > 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]load).
> > > ...
> > Index: sys/i386/i386/swtch.s
> > ===
> > RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/swtch.s,v
> > retrieving revision 1.89.2.4
> > diff -u -r1.89.2.4 swtch.s
> > --- sys/i386/i386/swtch.s 2001/07/26 02:29:10 1.89.2.4
> > +++ sys/i386/i386/swtch.s 2001/10/26 21:54:19
> > @@ -246,6 +246,17 @@
> > call_procrunnable
> > testl %eax,%eax
> > CROSSJUMP(jnz, sw1a, jz)
> > +#ifdef XORP_ETHER_POLLING
> > + incl_idle_done
> > + pushl _poll_burst
> > + call_ether_poll
> > + addl$4,%esp
> > + sti
> > + nop
> > + cli
> > + testl %eax, %eax
> > + jnz idle_loop
> > +#endif
> > call_vm_page_zero_idle
> > testl %eax, %eax
> > jnz idle_loop
>
> This has some serious bugs:
> (1) ether_poll() is called with interrupts disabled. This breaks fast
> interrupt handlers. ether_poll() uses splimp() so it is apparently
> not intended to run with priority higher than splhigh().
> (2) The sti/cli stuff belongs in ether_poll(), and the test of the return
> code of ether_poll() only works because ether_poll() always returns 1.
> vm_page_zero_idle() and the hlt instruction are never reached and the
> system spins calling ether_poll() from idle until a process becomes
> runnable. ether_poll() needs quite different handling than
> vm_page_zero_idle() since it can reasonably find something to do
> whenever an interface is up, while vm_page_zero_idle() soon runs out
> of things to do if it is called a lot.
>
> > Index: sys/kern/kern_clock.c
>
> It shouldn't be necessary to touch this file. Everything involving
> "ether" certainly doesn't belong here. Everything related to periodic
> polling can be done, probably more efficiently, using schedsoft*() or
> timeout(). E.g., schedsoftnet() arranges for netisrs to be checked
> for at the next clock interrupt. But this can now be done almost as
> well (probably better in -current) using an ordinary timeout.
>
> Bruce
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
TCP anomalies (was Re: FreeBSD performing worse than Linux?)
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, is it from before or after rev 1.107.2.18 of sys/netinet/tcp_input.c? (Mon Nov 12 22:11:24 2001 UTC) I'm not sure how relevant this point is, but some of the anomalies I noticed seem related to fast retransmit (see below). Also...where did you do the trace (i.e. sender, receiver, or a third machine)? > test4 was > aborted about 10% into the transfer so that you have a chance at > looking at the whole thing in xplot. There are multiple pathologies > visible in the results, but a good place to start would be around > :56.44 in test4. 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, the receiver somehow gets the missing data because you can later see it acking later sequence numbers. The first place I saw this was at :41.504152. This looks a little odd, but it *could* be explained by data segments getting misordered somewhere and the dupacks getting lost. Another place to look is the large number of consecutive dupacks starting around :41.978767. I don't know what's happening here, but after a long time (about a second?!?) the sender finally gives up and sends the receiver what it wants. Cheers, Bruce. msg04182/pgp0.pgp Description: PGP signature
More Polling vs No Polling tests
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. In general it seems to work better for the most part, but the big bonus is the lowered load average. Next tests, I am going to see what effect it has purely on forwarding. For now, I have all the raw results available at http://www.tancsa.com/netperf-11-29-2001.tgz for anyone interested tar -tzf netperf-11-29-2001.tgz no-poll-dc-fxp no-poll-dc-fxp.no-hz no-poll-dc-rl no-poll-fxp-fxp no-poll-fxp-fxp-vlan no-poll-fxp-rl no-poll-fxp-rl.no-hz poll-dc-fxp poll-dc-fxp.no-hz poll-dc-rl poll-fxp-fxp poll-fxp-fxp-vlan poll-fxp-rl poll-fxp-rl.no-hz hardware.txt I did the following cross over cables connecting 2 boxes -- PIV with fxp and rl nics and and PIII with fxp and four port D-Link running the dc driver. netperf client on the PIII and the server on the PIV. I ran poll enabled vs no poll enabled on dc to fxp, dc to rl and fxp to fxp, and dc via switch port to a vlan interface on the PIV's fxp nic in 802.1q trunk mode connected to a compaq switch 10/100 switch. Much to my surprise and disappointment, the d-link was throughput wise quite an under-performer. I am not sure its the driver, it could very well be the card thats the problem. (Its a DFE-570TX 4 port). All the above tests were done with options HZ=1000 in the kernel. To see what difference it made, I re-ran the tests without the HZ option. These text files have the .no-hz extension One nice surprise (for me anyways) was the relatively good performance of the fxp card in 802.1q mode. With the prices of switches being so low (especially used), its almost cheaper to make a "24 port network card" as opposed to something like the quad port D-link. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Very strange network behaviour - can anyone help me analyse tcpdump output?
> > 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 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [ > > > LAN #2 ] > > > > > > Both LANs connect using PPPoE with the same ISP, and are one hop apart > > > (according to traceroute). > > > > This smells like MTU problems. Try to set the MTU on your physical LAN > > interfaces to something like 1480 or so any try again. > > That's what I thought too. I checked, and ppp is doing the TPC MSS > fixup. Even after removing the gif/ipsec stuff that I was doing > (less overhead, and converting this installation into a plain > LAN-behind-NAT setup), the problem persists. > > I tried dropping the MTU on my LAN interface to 1200 (from 1500), but that > didn't change anything. > > If my ISP installed a bunch of really buggy hardware, would that explain > why this started happening recently without any changes on my side? The answer turned out to be quite obvious. If I didn't make any changes on the FreeBSD end, and the ISP didn't make any changes on their end, then it must have been the telco (since these are DSL links.) It turned out that the telco upgraded a bunch of line equipment recently which didn't play nice with the DSL equipment that the ISP was using. After 6 hours of testing the wiring between our DSL modem and various points all the way back to the CO, the telco figured out the problem and the strangeness that we saw has gone away. Thanks for all the helpful hints and suggestions - it surely kept me from going mad. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
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, the receiver somehow gets the missing data >because you can later see it acking later sequence numbers. The first >place I saw this was at :41.504152. > >This looks a little odd, but it *could* be explained by data segments >getting misordered somewhere and the dupacks getting lost. > >Another place to look is the large number of consecutive dupacks >starting around :41.978767. I don't know what's happening here, but >after a long time (about a second?!?) the sender finally gives up and >sends the receiver what it wants. Yes, I think that area (I was looking at it too) provides a fairly good illustration that fast retransmits are broken. The transmit at 14:01:42.969338 appears to be the retransmit timer finally kicking in. I wonder if we can figure out which -RELEASE this started happening in. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Revised polling code for STABLE
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 particular interrupt? If you do it in a timeout routine,
then you will normally do it in sync with hardclock interrupts
but delayed by some fraction of a hardclock interrupt. I think the
fraction can be compensated for if necessary. Doing it in sync with
statclock interrupts might be slightly better, but statclock interrupts
are _supposed_ to be non-periodic (FreeBSD just doesn't implement this),
so adjustments for fair sampling are strictly required.
In -current, hardclock() and softclock() are called in fast interrupt
context, so adding to them is both nontrivial and BAD (it requires
aquiring sched_lock because all write accesses and certain read accesses
to variables accessed by the fast interrupt handler, and this is still
not done for at least all of the ntptime variables).
> I do not know how/if I can replace the schednetisr() with an ordinary timeout:
> i need the handler to be invoked as soon as possible after the
> clock ticks, as the task it performs are as urgent as interrupt requests.
As urgent as hardclock interrupts?
> Certainly I do not want it to be run after other netisr handlers
> (this is also why NETISR_POLL is lower than any other NETISR, so
> the corresponding handler is called first).
> It looked like the schednetisr() was the simplest (one-line change) and
> more effective way to achieve this, if you know of other ways involving
> timeouts please let me know.
schedsoftnet() doesn't quite work, but you could add another interrupt
class (`poll' instead of `net') in RELENG_4. This takes about 1 line
of changes in each of 6 files. All hardware interrupts would have
higher priority (sort of), but it is easy to make the new priority
higher than all SWI priorities. SWIs are easier to add in -current,
but have much higher overheads (which is not a problem for polling
every 100 seconds but very bad for much higher rates).
> Re. the first one, yes the code might probably benefit from
> a bit of rearrangement, such as below
>
> #ifdef XORP_ETHER_POLLING
> call_idle_poll
> #else
> call_vm_page_zero_idle
> #endif
> testl %eax, %eax
> jnz idle_loop
>
> with idle_poll being
>
> int idle_poll() {
> {
> idle_done=1;
> if (poll_handlers > 0) {
> int s = splimp();
> __asm __volatile("sti" : : : "memory");
Ugh. Use a standard FreeBSD C interface for this (critical_exit() in
-current; enable_intr() for i386's only in RELENG_4).
> retval = ether_poll(poll_burst);
> __asm __volatile("cli" : : : "memory");
> splx(s);
> vm_page_zero_idle();
> return 1;
> } else
> return vm_page_zero_idle();
> }
It's ugly for idle_poll() to know about all the other poll routines
(we've had other there before, e.g., one for apm).
> The thing is, with polling you cannot halt the CPU if there are handlers
> registered for polling. You can try and deregister polling on
> interfaces which are idle, which then should be handled correctly
> by the above function.
Yes, it's hard to reach hlt if there are any active interfaces. Maybe
limit the polling and switch to interrupt mode to wake up from hlt.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
