>As a further FYI, a variety of debugging features are still enabled by
>default in RELENG_6, including INVARINTS, WITNESS, and user space malloc
>debugging. These will remain enabled through the first snapshot from the
Not very scientific but here is my ubench on a dual nocona @ 2.8 GHz
and 4 GB
> > > 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
> did the trick! now can someone remind me what inflight does? and could
> someone explain why increasing sendspace alone did not do the trick?
> (i had it at 64k, which got things better, but not sufficient).
TCP inflight limiting is supposed to guess the bandwidth-delay
product for a TCP connect
> 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 throughput of FreeBSD=
(I am sorry if you have received this e-mail. I'm resending this
because it seems the previous one was lost.)
> TCP inflight limiting is supposed to guess the bandwidth-delay
> product for a TCP connection and stop the window expanding much
> above this.
(Just to clarify..)
TCP inflight limitin
Could you try SMP kernel without IPF support and without using IPF module?
Could you confirm, that your SMP kernel is not crashing when you do not use
IPF?
Interesting that the box has survived almost two days now, while it was always
crashing after at least 8 hours. Anyway, I have compiled a n
> > 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
Blaz Zupan wrote on 2005-07-12 13:17:
Interesting that the box has survived almost two days now, while it was always
crashing after at least 8 hours. Anyway, I have compiled a new kernel without
ipfilter, I have used pf instead (the configuration changes from ipfilter to
pf were mostly minor).
Hello Scott,
i run into same Problem with Spamassassin and Perl v5.8.7.
After a backport to 5.8.6_2 all thins run fine.
I have no relly good reason found why the behavior is, but i have many
hint's found
that say's that this is a generally io-problem with perl v5.8.7.
So that i have made a entry
Hmm,
Recently I've also been seeing less than what I'd expect tcp throughput
on FreeBSD 5.4R machines. I've got six 5.4R boxes with dual Gigabit em
interfaces. netperf gives me:
Recv SendSend
Socket Socket Message Elapsed
Size SizeSize Tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2005 at 02:28:33PM +0200, Michael Schuh wrote:
Scott wrote
>> The other problem that will possibly affect more people is that
>>SpamAssassin stopped working properly. This isn't a server, simply a
>> workstation, using get
In the last episode (Jul 12), David Malone said:
> > did the trick! now can someone remind me what inflight does? and
> > could someone explain why increasing sendspace alone did not do the
> > trick? (i had it at 64k, which got things better, but not
> > sufficient).
>
> TCP inflight limiting is
I have one IDE and two SATA drives in my system. With
FreeBSD 5.4 the system would not boot from the SATA
drive so I use the IDE as the primary then mount
the SATA drives in fstab. I tried upgrading to RELENG_6
and with the new kernel one of the SATA drives errors
out and so can't be mounted. I
I'm having a fiddle with RELENG_6 and while setting up a RAID1 system
disk I noticed that atacontrol now lets you create a RAID5 device.
I gave it a whirl and it seemed to work - I have a device I can "use".
But is this working properly? I don't have a hardware raid card, just a
plain old SATA car
Yes, there is absolutely no difference. Disabled HTT in the BIOS and in
FreeBSD, the box still crashes.
Matt again :)
So far a 13 day up time after switching from IPF to PF. If thats not the
problem, I hope I find it soon considering this is a production server ...
but it seems to be more st
Are you using the correct cables? I had a problem when I changed system
cases and used the wrong cable when I put the drives back in (IDE cable
instead of a SATA cable) I now have FreeBSD 5.4-p3 booting up fine and
without error. I think this is a common problem, where people forget
about the m
Jayton Garnett <[EMAIL PROTECTED]> writes:
>Are you using the correct cables? I had a problem when I changed system
>cases and used the wrong cable when I put the drives back in (IDE cable
>instead of a SATA cable) I now have FreeBSD 5.4-p3 booting up fine and
You mean, an old IDE cable vs. a
> Michael C. Shultz wrote:
> >I have one IDE and two SATA drives in my system. With
> >FreeBSD 5.4 the system would not boot from the SATA
> >drive so I use the IDE as the primary then mount
> >the SATA drives in fstab. I tried upgrading to RELENG_6
> >and with the new kernel one of the SATA dri
Yea, thats what I meant, this mcsd :-\ course must be turning me into
yet another zombie
Matthias Buelow wrote:
Jayton Garnett <[EMAIL PROTECTED]> writes:
Are you using the correct cables? I had a problem when I changed system
cases and used the wrong cable when I put the drives back in
19 matches
Mail list logo
