> Xin, good day.
>
> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote:
> > The attached patch should fix this, any objections?
>
> Yes, you missed negation operator in the copyin check. The issue
> was already fixed by hrs@ two hours ago:
> http://svn.freebsd.org/viewvc/base?view=revision&r
> Can someone please confirm or rule out my issue with dhclient sending
> bad IP checksum packets. It would really suck if 7.1 was released with a
> broken DHCP client.
>
I've had many problems lately, but none involved checksum nor the dhcpd
(btw, I assume that you are seeing bad checksum on th
> On 5/16/07, Thomas Hurst <[EMAIL PROTECTED]> wrote:
> > * Jack Vogel ([EMAIL PROTECTED]) wrote:
> >
> > > I introduced a change yesterday that limited TSO to PCI Express
> > > adapters, I did this more for avoidance rather than a bug fix, and
> > > I'm not 100% sure its the right thing, so I t
> >short version:
> >the point im trying to make, is that the same setup, where I only change
> >the release, is going downhill - with this particular MB.
>
> But its not the same necessarily. Some of the settings are different.
> For example, disable net.inet.tcp.inflight.enable on 6.x if you wa
> Jack Vogel wrote:
> > On 10/11/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
> >> the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
> >> dual cpu.
> >> running iperf -c (receiving):
> >>
> >> freebsd-4.100.0-10.0
> On 10/11/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
> > the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
> > dual cpu.
> >
> > running iperf -c (receiving):
> >
> > freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec
&
> On Wed, 11 Oct 2006 16:06:17 +0200, in sentex.lists.freebsd.net you
> wrote:
>
>
>the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
>
>dual cpu.
>
>
>
>running iperf -c (receiving):
>freebsd-4.10 0.0-10.0 sec936 MBytes785 Mbits/sec
>freebsd-5.40.0-10.0 sec41
the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU)
dual cpu.
running iperf -c (receiving):
freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec
freebsd-5.4 0.0-10.0 sec413 MBytes346 Mbits/sec
freebsd.6.1 0.0-10.0 sec366 MBytes307 Mbits/sec
freebsd-6.
> On Tue, Sep 26, 2006 at 01:53:44PM -0700, John Polstra wrote:
> > On 26-Sep-2006 Danny Braniss wrote:
> > > This keeps bitting me every other upgrade, IPMI on some
> > > hosts, if enabled, will steal packets to port 623 or 664, so
> > >
Hi,
This keeps bitting me every other upgrade, IPMI on some
hosts, if enabled, will steal packets to port 623 or 664, so
the current solution is either set net.inet.ip.portrange.lowlast
to 664, (for some reason this does not seem to work if done via
loader.conf) or change it in sys/netinet/
> Jack Vogel wrote:
> > On 8/30/06, Danny Braniss <[EMAIL PROTECTED]> wrote:
> >>
> >> ever since 6.1 I've seen fluctuations in the performance of
> >> the em (Intel(R) PRO/1000 Gigabit Ethernet).
> >>
> &
ever since 6.1 I've seen fluctuations in the performance of
the em (Intel(R) PRO/1000 Gigabit Ethernet).
motherboard OBN (On Board NIC)
--
1- Intel SE7501WV2S Intel 82546EB::2.1
2- Inte
problem:
IPMI will highjack packets to ports 623/664, so packets
which get assigned either port, will not get back to the application.
Question:
Is there a way to blacklist these ports?
thanks,
danny
___
freebsd-net@freebsd.org
> In the last episode (Jul 12), Danny Braniss said:
> > [...]
> > > You might want to apply the patch at the bottom of
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/75122 ; without it, new
> > > connections get a random initial bandwidth.
> >
>
> > combining
> > sysctl net.inet.tcp.sendspace=131072
> > and
> > sysctl net.inet.tcp.inflight.enable=0
> >
> > did the trick!
>
> Congratulations! But I wonder why the throughput of FreeBSD=>Linux
> was almost equal to that of Linux=>FreeBSD. If the settings above
> improves the throug
> > > Are the window sizes on Linux bigger or smaller?
>
> > TCP window size: 16.0 KByte (default)
> > smaller :-(, but increasing it does not make any change
>
> Hmmm... Various things that you could try (I'd try them
> one by on, rather than all together):
>
> 1) sysctl net.inet.tcp.inflight_e
heers
> luigi
thanks,
danny
>
> On Tue, Jul 12, 2005 at 09:21:13AM +0300, Danny Braniss wrote:
> > while checking out the quality of a switch, I came about a very disturbing
> > dicovery: FreeBSD <-> Linux througput is MUCH better than FreeBSD <->
> > FreeBSD
while checking out the quality of a switch, I came about a very disturbing
dicovery: FreeBSD <-> Linux througput is MUCH better than FreeBSD <-> FreeBSD
Setup:
2 blades in the same bladeserver, A running FreeBSD 5.4, B running Linux
C is running FreeBSD 5.4
all are connecte
> Scott Long wrote:
> > Danny Braniss wrote:
> >
> >>> with tags enabled, iSCSI is much faster, but it also causes a
> >>> deadlock :-(
> >>> this is what i run:
> >>> newfs -U /
> >>> cd /
> >>>
> with tags enabled, iSCSI is much faster, but it also causes a deadlock :-(
> this is what i run:
> newfs -U /
> cd /
> restore rf /home/file.dump
>
> on the same motherboard, a dual Xeon, with smp disabled all is OK
> with smp enabled restore gets stuck usualy waiting on biord.
with tags enabled, iSCSI is much faster, but it also causes a deadlock :-(
this is what i run:
newfs -U /
cd /
restore rf /home/file.dump
on the same motherboard, a dual Xeon, with smp disabled all is OK
with smp enabled restore gets stuck usualy waiting on biord.
the iscsi
> Danny Braniss wrote:
> >>Depends on what the arps are for.
> >>
> >>On my network router (which is running 5.3), I noticed a lot of ARP messages
> >>that were not as a result of any configuration errors and was able to put a
> >>stop
&g
> At Wed, 16 Mar 2005 11:02:01 +0200,
> Danny Braniss wrote:
> > This is not my case, no kernel messages, I see the packets. (im mirrowing
> > the traffic to another host so that i can 'sniff' it).
> >
> > the host has indeed two nics, but only one is conn
ckets. (im mirrowing
the traffic to another host so that i can 'sniff' it).
the host has indeed two nics, but only one is connected.
The problem - if indeed it is - only appears on this host, and i have
several identical ones, that don't show this.
danny
>
>
>
> At 10
While debuging something else, im noticing my host sending out
'Gratuitous ARP' serveral times per second all the time.
Q: is this normal?
btw, the host is running 5.3 and the ethernet hardware is
thanks,
danny
___
freebsd-net@freebsd.
I need to send/receive tcp packets in the kernel. At the moment im
looking at /sys/kern/uipc_socket:sosend, and was wondering if that is the best
way to go.
thanks,
danny
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailma
thanks for insight! i guess it's time to change horses :-(
i was planning to use it for an application that is udp,
oh well, there goes another idea down the drain.
danny
> Danny Braniss wrote:
> >
> > > I have been the last one fuzz around in the TTCP code areas. Howev
> I have been the last one fuzz around in the TTCP code areas. However
> there could be problems that were lurking there before in other code
> parts (syncache maybe). TTCP isn't used in production by anyone (AFAIK)
> and only minimally tested.
ahh, that's one realy good piece of info so far.
th
> Danny Braniss wrote:
> > hi,
> > im running some experiments, and it seems to me that
> > setting net.inet.tcp.rfc1644 has the reverse effect.
> > with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
> > and it's less than 1 sec,
hi,
im running some experiments, and it seems to me that
setting net.inet.tcp.rfc1644 has the reverse effect.
with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
and it's less than 1 sec, setting net.inet.tcp.rfc1644 to 1 uses
8 packets and takes more than 1 sec.
with
30 matches
Mail list logo
