Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error

[Daniel Kalchev]

> On 13 Dec 2017, at 21:39, O. Hartmann  wrote:
> 
> Am Wed, 13 Dec 2017 08:47:53 -0800 (PST)
> "Rodney W. Grimes"  schrieb:
> 
>>> On Tue, 12 Dec 2017 14:58:28 -0800
>>> Cy Schubert  wrote:
>>> 
 There are a couple of ways you can address this. You'll need to
 offline the vdev first. If you've done a smartcrl -t long and if the
 test failed, smartcrl -a will tell you which block it had an issue
 with. You can use dd, ddrescue or dd_rescue to dd the block over
 itself. The drive may rewrite the (weak) block or if it fails to it
 will remap it (subsequently showing as reallocated).
 
 Of course there is a risk. If the sector is any of the boot blocks
 there is a good chance the server will hang.  
>>> 
>>> The drive is part of a dedicated storage-only pool. The boot drive is a
>>> fast SSD. So I do not care about this - well, to say it more politely:
>>> I do not have to take care of that aspect.
>>> 
 
 You have to be *absolutely* sure which the bad sector is. And, there
 may be more. There is a risk of data loss.
 
 I've used this technique many times. Most times it works perfectly.
 Other times the affected file is lost but the rest of the file system
 is recovered. And again there is always the risk.
 
 Replace the disk immediately if you experience a growing succession
 of pending sectors. Otherwise replace the disk at your earliest
 convenience.  
>>> 
>>> The ZFS scrubbing of the volume ended this morning, leaving the pool in
>>> a healthy state. After reboot, there was no sign of CAM errors again.
>>> 
>>> But there is something else I'm worried about. The mainboard I use is a 
>>> 
>>> ASRock Z77 Pro4-M.
>>> The board has a cripple Intel MCP with 6 SATA ports from the chipset,
>>> two of them SATA 6GB, 4 SATA II, and one additional chip with two SATA
>>> 6GB ports:
>>> 
>>> [...]
>>> ahci0@pci0:2:0:0:   class=0x010601 card=0x06121849 chip=0x06121b21
>>> rev=0x01 hdr=0x00 vendor = 'ASMedia Technology Inc.'
>>>device = 'ASM1062 Serial ATA Controller'
>>>class  = mass storage
>>>subclass   = SATA
>>>bar   [10] = type I/O Port, range 32, base 0xe050, size 8, enabled
>>>bar   [14] = type I/O Port, range 32, base 0xe040, size 4, enabled
>>>bar   [18] = type I/O Port, range 32, base 0xe030, size 8, enabled
>>>bar   [1c] = type I/O Port, range 32, base 0xe020, size 4, enabled
>>>bar   [20] = type I/O Port, range 32, base 0xe000, size 32, enabled
>>>bar   [24] = type Memory, range 32, base 0xf7b0, size 512,
>>>enabled
>>> [...]
>>> 
>>> Attached to that ASM1062 SATA chip, is a backup drive via eSATA
>>> connector, a WD 4 TB RED drive. It seems, whenever I attach this drive
>>> and it is online, I experience problems on the ZFS pool, which is
>>> attached to the MCP SATA ports.  
>> 
>> How does this external drive get its power?  Are the earth grounds of
>> both the system and the external drive power supply closely tied
>> togeather?  A plug/unplug event with a slight ground creep can
>> wreck havioc with device operation.
> 
> The external drive is housed in a external casing. Its PSU is de facto with 
> the same
> "grounding" (earth ground) as the server's PSU, they share the same power 
> plug at its
> point were the plug is comeing out of the wall - so to speak.

Most external drive power supplies are not grounded. At least none I ever saw 
had grounded plugs for the mains cable. Might be, yours has it...

Worth checking anyway.

Daniel


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error

[Daniel Kalchev]

> On 13 Dec 2017, at 1:26, Freddie Cash  wrote:
> 
> On Tue, Dec 12, 2017 at 2:55 PM, Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
>> Hum, just noticed this.  25k hours power on, 2M load cycles, this is
>> very hard on a hard drive.  Your drive is going into power save mode
>> and unloading the heads.  Infact at a rate of 81 times per hour?
>> Oh, I can not believe that.  Either way we need to get this stopped,
>> it shall wear your drives out.
>> 
> 
> ​Believe it.  :)  The WD Green drives have a head parking timeout of 15
> seconds, and no way to disable that anymore.  You used to be able to boot
> into DOS and run the tler.exe program from WD to disable the auto-parking
> feature, but they removed that ability fairly quickly.
> 
> The Green drives are meant to be used in systems that spend most of their
> time idle.  Trying to use them in an always-on RAID array is just asking
> for trouble.  They are only warrantied for a couple hundred thousand head
> parkings or something ridiculous like that.  2 million puts it way out of
> the warranty coverage.  :(
> 
> We had 24 of them in a ZFS pool back when they were first released as they
> were very inexpensive.  They lead to more downtime and replacement costs
> than any other drive we've used since (or even before).  Just don't use
> them in any kind of RAID array or always-on system.
> 

In order to handle drives like this and in general to get rid of load cycles, I 
use smartd on  all my ZFS pools with this piece of config:

DEVICESCAN -a -o off -e apm,off 

Might not be the best solution, but as it is activated during boot, S.M.A.R.T. 
attribute 193 Load_Cycle_Count does not increase anymore. Not fan of WD drives, 
but have few tens of them… all of them “behave” in some way or another.

For the original question, if I do not have spare disk to replace, on a 
raidz1/raidz2 pool I would typically do:

zpool offline poolname disk
dd if=/dev/zero of=/dev/disk bs=1m
zpool replace poolname disk

This effectively fills the disk with zeros, forcing any suspected unreadable 
blocks to be replaced. After this operation, no more pending blocks etc. But, 
on large drives/pools requires few days to complete (the last part). Over the 
years, I have used this procedure on many drives, sometimes more than once on 
the same drive and that posponed having to replace the drive and the annoying 
S.M.A.R.T. message: which by itself might not be major problem, but better not 
have the logs filled with warnings all the time.

I feel more confident doing this on raidz2 vdevs anyway..

If I had spare disk and spare port, just

zpool replace poolname disk

Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Opteron 6100-series "Magny-Cours"

[Daniel Kalchev]

If you still have not found it, I have two Supermicro blades with these, one to 
be upgraded with 6127 these days… 

Daniel

> On 27.03.2017 г., at 16:11, Andriy Gapon  wrote:
> 
> On 27/03/2017 15:06, Piotr Kubaj wrote:
>> Does it have to be specifically 61xx series? I have a server running 2 
>> 6262HE's.
>> 
> 
> Yes.  I have the info that I need for 62xx Opterons.
> Thanks.
> 
> -- 
> Andriy Gapon
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ISO image: where is the CLANG compiler?

[Daniel Kalchev]

I never use the pre-built ISO images for tasks like this. Here is a script I 
use to build my own USB boot drive. The drive contains the full OS to boot and 
also a copy used to create a new system. I make these boot drives from time to 
time, to stay current. Please note the script is few years old (for 9-stable) 
and you might want to twiddle with boot partition size if they grew. You need 
to have done bouildworld/buildkernel on the host before using this script.

$ cat createuboot
#!/bin/sh
# target USB drive to write to
disk=da1
# use the current date for labels
today=`date "+%Y%m%d"`
# wipe out partition data form drive
# do it twice to wipe more stuff (might not be needed anymore)
gpart destroy -F $disk   
gpart create -s GPT $disk
gpart destroy -F $disk
# GPT label the drive
gpart create -s GPT $disk  
# bootstrap partition 
gpart add -b 34 -s 128 -t freebsd-boot $disk   
# partition for the OS
gpart add -a 4k -t freebsd-ufs -l boot$today $disk 
# write bootstrap code
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $disk

# format file system
newfs  /dev/gpt/boot$today

# mount file system
mount -o async /dev/gpt/boot$today /mnt

# install FreeBSD
cd /usr/src
make installworld DESTDIR=/mnt
make distribution DESTDIR=/mnt
make installkernel DESTDIR=/mnt
# Create new “clean” copy of FreeBSD for later use
mkdir -p /mnt/root/FreeBSD
make installworld DESTDIR=/mnt/root/FreeBSD
make distribution DESTDIR=/mnt/root/FreeBSD
make installkernel DESTDIR=/mnt/root/FreeBSD

# copy scripts
cp -r ~/scripts /mnt/root

echo /dev/gpt/boot$today / ufs rw,noatime 0 1 > /mnt/etc/fstab
umount /mnt


You might add more customizations, such as dhclient and starting sshd in 
/etc/rc.conf of the boot drive.

Hope this helps…

Daniel


> On 18.01.2017 г., at 9:45, O. Hartmann  wrote:
> 
> I ran into a very nasty situation where I need to save/restore/reinstall a
> in-installworld-crashed recent current.
> 
> While the /usr/obj and /usr/src as well as /etc folders are intact (residing 
> on
> a Samsung 850 pro SSD with UFS and journaling), /boot/kernel vanished and
> most binaries in /bin and /sbin are of Null size.
> 
> I treid to rescue the system by intending to use the most recent CURRENT ISO
> image found on the snapshot server for USB drives, booted this successfully 
> and
> then mounted the failes filesystems into the proper place (/usr/obj
> and /usr/src onto USB devices /usr/obj and /usr/src respectively, the rest 
> goes
> into /mnt).
> 
> I tried then to perform a make installworld with DESTDIR=/mnt set. But I fail:
> the minimalistic USB image does not have any CLANG/LLVM stuff required for the
> rescue!
> 
> Where the hell did this stuff go? Has it been ripped off due to the 1 GB
> ancient flash size? 
> 
> Help is needed. I've already posted to CURRENT a message, but I guess I always
> hit the wrong subject line. It seems that the key to my saviour is to have a
> flash drive with a recent CURRENT containing a cc compiler - otherwise 
> /usr/obj
> is useless.
> 
> Kind reards,
> 
> Oliver
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IPFW on CURRENT: NAT forwarding exposes internal IP!

[Daniel Kalchev]

It looks like your httpd server is doing a redirect to your internal IP 
address, which it thinks is it’s ServerName. Don’t think NAT has anything to do 
with it.

Daniel

> On 29.09.2016 г., at 15:47, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> Despite other problems with IPFW and its documentation regarding NAT, I face 
> a serious
> and disturbing problem.
> 
> I run a NanoBSD based router/firewall project of my own, running CURRENT 
> (FreeBSD
> 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is the filter 
> of my choice,
> since it is FreeBSD's native. I also use In-kernel-NAT as well as pppoed/ppp. 
> The modem
> is connected to a dedicated NIC, the pppoe-traffic is transported via tun0 - 
> I think this
> is the usual stuff.
> 
> The IPFW has this NAT rule:
> 
> ${fwcmd}nat 1 config if ${if_isp0} \
>log \
>reset \
>same_ports \
>redirect_port tcp ${server_gate}:22 22 \
>redirect_port tcp ${server_www}:80 80 \
>redirect_port tcp ${server_www}:443 443 \
>redirect_port tcp ${server_refdb}:9734 9734
> 
> server_www is assigned to a non-official IP, 192.168.10.10.
> 
> if_isp=tun0, tun0's IP is given by the provider, I use net/ddclient as the 
> updater for a
> dynamic DNS account.
> 
> I use an internal DNS server, which resolves 92.168.10.10 to a certain name. 
> I also use
> self signed SSL certicates, just for completeness of this information.
> 
> Connecting from the outside world to my dynDNS domain triggers Firefox or any 
> other
> browser to compalin about the self signed SSL certificate - as usual, but 
> then, adding
> it, suddenly the domain name (say: www.blabla.org) is replaced by the 
> internal IP I
> delegate any access on ports 80 and 443 to.
> 
> What happens here? I consider this a bug, I never saw this on our Linux 
> servers running a
> similar setup (forwarding, BIND 9.10/BIND 9.11).
> 
> Thanks,
> 
> Oliver
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJX7Q17AAoJEOgBcD7A/5N88yAH/RZLURQbC5LTgJD/NUdE51F3
> yPVaUQIaeGm93du87K2opXs3DNtMr0m1SI1wQZdOAQDl3yqMkz9bX9VTUweuAltp
> ZcBxhZ2VACQJCu/AsYIWWWp6rliniyZWMr+TOyNtTDxdPrIXYzwefX+fYN+Uy/04
> 9PalfcT/S+9q5DKd7sm7K6LqsU0HJ9GpKgNnsyqWEAWvORgxUvKS3GS9jEjxUnrD
> 20yTXjyiu0mS8UYLS7DbrrgItg3fXEJVG8188tweFB5aalQRH6oyNGaxWlGaF8Rc
> K9t479v6OW3XCs9FiG6AtCzpmnUkCoMtxl7lY3hPU/Sh1P5epYu26bdoF2ecr1g=
> =oMGL
> -END PGP SIGNATURE-
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Daniel Kalchev]

> On 12.07.2016 г., at 13:26, Franco Fichtner <fra...@lastsummer.de> wrote:
> 
> 
>> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev <dan...@digsys.bg> wrote:
>> 
>> It is trivial to play MTIM with this protocol and in fact, there are 
>> commercially available “solutions” for “securing one’s corporate network” 
>> that doe exactly that. Some believe this is with the knowledge and approval 
>> of the corporation, but who is to say what the black box actually does and 
>> whose interests it serves?
> 
> It's also trivial to ignore that pinning certificates and using client
> certificates can actually help a great deal to prevent all of what you
> just said.  ;)

I don’t know many users who even know that they can do this —  much less 
actually using it. Pinning the browser vendor’s certificates does not protect 
you from being spied while visiting someone else’s site. This is also 
non-trivial to support.
In the early days of DANE, Google even had a version of Chrome that supported 
DANE, just to kill it a bit later: 
https://www.ietf.org/mail-archive/web/dane/current/msg06980.html

> 
> The bottom line is not having GOST support readily available could alienate
> a whole lot of businesses.  Not wanting those downstream use cases will make
> those shift elsewhere and the decision will be seen as an overly political
> move that in no possible way reflects the motivation of community growth.


Exactly — especially as long as there is no demonstrable proof that GOST is 
actually broken.

Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GOST in OPENSSL_BASE

[Daniel Kalchev]

> On 12.07.2016 г., at 12:12, Matthew Seaman  wrote:
> 
> I'm also curious as to how far these regulations are supposed to extend.
> Presumably traffic which is merely transiting Russian territory isn't
> covered, at least in a practical sense.  How about people from Russia
> accessing foreign websites?  I can't see any of the big Internet players
> implementing GOST in any locations outside Russia any time soon.
> Neither would I as a non-Russian have GOST capabilities client-side, so
> what happens if I go and look at say a YandX website over HTTPS?  Putin
> and his advisors aren't stupid, and they'd already have considered all
> this; plus, as you say, the timetable is clearly impossible; so there
> must be something else going on here.

The standard HTTPS implementation is already sufficiently broken, with the door 
wide open by the concept of “multiple CAs”. The protocol design is flawed, as 
any CA can issue certificate for any site. Applications are required to trust 
that certificates, as long as they trust the CA that issued them.

It is trivial to play MTIM with this protocol and in fact, there are 
commercially available “solutions” for “securing one’s corporate network” that 
doe exactly that. Some believe this is with the knowledge and approval of the 
corporation, but who is to say what the black box actually does and whose 
interests it serves?

There is of course an update to the protocol, DANE, that just shuts this door 
off. But… it faces heavy resistance, as it’s acceptance would mean the end of 
the lucrative CA business and the ability to intercept “secure” HTTPS 
communication. Those relying on the HPPTS flaws will never let it become wide 
spread.

In summary — anyone can sniff HTTPS traffic. No need for any cipher backdoors 
here. Nor any need for GOST to be involved.

> 
> Of course, now there's fairly good evidence that there's some sort of
> backdoor in the GOST ciphers, all bets are off on how long it will be
> until they get broken in a very public manner.
> 

One can say the same for any other crypto. Plus, for some ciphers there is 
already evidence.. yet they are still in use.
But, a good show is always worth it. Let’s watch for those heroes. :)

Daniel


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] packaging the base system with pkg(8)

[Daniel Kalchev]

> On 19.04.2016 г., at 5:01, Roger Marquis  wrote:
> 
> Honestly, some of us are wondering what exactly is
> behind some of these concerns regarding base packages.
> 

Not taking a side on this discussion, yet… but the first thing that occurred to 
me is that such way of packaging is traditional for the Linux “distributions”. 
I could imagine people worrying at subconscious level that FreeBSD is going the 
Linux way… and that if they wanted such a model, they would be using Linux 
instead. Today, people have more choice in packaging — but if FreeBSD goes the 
Linux way, someone else will fill the void — so no worries in general.

I can see the support nightmare that a packaged base would bring, but as always 
— this is not enough to judge it. The benefits might be worth it in the long 
run.

I was a long time user of BSD/OS and then switched to FreeBSD when that OS was 
killed. In BSD/OS everything was monolithic. It was rock stable. Very 
dependable and very easy to support. My first few years with FreeBSD were spent 
to get used that the OS was not just one piece, but you could end up with 
different installs.. A bit more support efforts. Not that I am complaining :)

As long as packaged base is not mandatory, it is fine by me.

Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Dropping some locales/encodings?

[Daniel Kalchev]

> On 1.03.2016 г., at 5:45, Sergey Manucharian  wrote:
> 
> Excerpts from Andrey Chernov's message from Tue 01-Mar-16 05:47:
>> On 01.03.2016 2:23, Baptiste Daroussin wrote:
>>> 
>>> I can properly generate almost any of the said locales/encodings but a few 
>>> that
>>> I would like to remove (provided that unicode version are available)
>>> 
>>> Here is the list of locales/encodings:
>>> 
>>> be_BY.CP1251
>> 
>> CP1251 is Windows native (single characters mode) and widely used to
>> represent Cyrillic: Russian, Bulgarian, Serbian, Ukrainian, Belarusian
>> (i.e. be_BY), Macedonian. IMHO it will be better to not remove it to
>> make easy handling of native encoded texts comes from Windows.
>> 
> 
> I agree with Andrey that CP1251 is needed as one of major Cyrillic
> encodings.
> 
> Not sure how the locale existence/absence effects that. Definitely nobody
> uses it as a locale for more than a decade.
> 

I use daily bg_BG.CP1251 on a lot of workstations, primarily to handle old text 
documents and source code that contains pre-UTF text. I could imagine similar 
use case for be_BY.CP1251.

What benefit does it bring to remove an already existing locale?

Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CVE-2015-7547: critical bug in libc

[Daniel Kalchev]

> On 17.02.2016 г., at 15:40, Shawn Webb  wrote:
> 
> TL;DR: FreeBSD is not affected by CVE-2015-7547.


Unless you use Linux applications under emulation.

Daniel


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: "libssl.so.8" not found

[Daniel Kalchev]

> On 14.12.2015 г., at 17:35, Brad Davis  wrote:
> 
> 
> Or just use pkg-static. :)
> 

I always wondered, why pkg is not static ONLY. That eliminates the chicken/egg 
dilemma. 

Yes, you eliminate the friendly reminder that your system is out of sync with 
the FreeBSD package building platforms, but still…

Daniel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Daniel Kalchev]

It is my understanding, that using the NONE cypher is not identical to using 
“the old tools” (rsh/rlogin/rcp).

When ssh uses the NONE cypher, credentials and authorization are still 
encrypted and verified. Only the actual data payload is not encrypted.

Perhaps similar level of security could be achieved by “the old tools” if they 
were by default compiled with Kerberos. Although, this still requires building 
additional infrastructure.

I must have missed the explanation. But why having a NONE cypher compiled in, 
but disabled in the configuration is a bad idea?

Daniel


> On 11.11.2015 г., at 10:55, Jason Birch  wrote:
> 
> On Wed, Nov 11, 2015 at 6:59 PM, John-Mark Gurney  wrote:
>> If you have a trusted network, why not just use nc?
> 
> Perhaps more generally relevant is that ssh/scp are *waves hands* vaguely
> analogous to secure versions of rsh/rlogin/rcp. I'd think that most cases
> of "I wanted to send files and invoke some commands on a remote machine,
> and due to $CIRCUMSTANCE I don't need or desire encryption" are covered
> by the older, also standard tools. Additionally, rsync can use rsh as its
> transport, for users who desire more advanced behaviour. ssh just seems
> to have more support; Installation will ask you if you'd like to run sshd
> (not rshd), ssh is rather ubiquitous as a way of "doing a thing remotely"
> (even in Windows soon!), etc. This is a good default to have; the
> overhead of security is tiny in nearly all cases.
> 
> It would seem then that the extra complexity of maintenance development
> in supporting NONE in base doesn't really grant us any additional
> functionality in most cases. It's just more 'obvious'.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Leaving the Desktop Market

[Daniel Kalchev]

On 02.04.14 12:22, David Chisnall wrote:
The use case that PulseAudio was [over]designed to fix was plugging in 
USB headphones (or connecting a Bluetooth headset) and having existing 
audio streams redirected there.


Please don't ever make this behavior the default!

Imagine, you have an audio setup mixing sound and pushing it out and 
then you plug in some USB device that also has audio capability and 
your production sound gets redirected there. A nightmare!


Knowing what you do and the system behaving in predictable way is one of 
the beauties of UNIX and FreeBSD in particular.


Don't make it so that even idiots can use it because then, only idiots 
will be using it!


My 0.02,
Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Daniel Kalchev]

On 02.04.14 15:52, David Chisnall wrote:

On 2 Apr 2014, at 13:40, Daniel Kalchev dan...@digsys.bg wrote:


On 02.04.14 12:22, David Chisnall wrote:

The use case that PulseAudio was [over]designed to fix was plugging in USB 
headphones (or connecting a Bluetooth headset) and having existing audio 
streams redirected there.

Please don't ever make this behavior the default!

Imagine, you have an audio setup mixing sound and pushing it out and then you plug in 
some USB device that also has audio capability and your production sound gets 
redirected there. A nightmare!

Do you really think that someone is going to be setting up an audio mixing 
environment without configuring their sound setup?  Or that people doing this 
make up the majority of users?


Twenty years ago, very unlikely. Today, very much possible. Especially 
if the behavior is not explicitly documented.

Knowing what you do and the system behaving in predictable way is one of the 
beauties of UNIX and FreeBSD in particular.

I agree, however sane defaults are also very important to a useable system and 
these are not mutually exclusive.  It is perfectly possible to have a system 
that has defaults that do what most users do (or a choice of defaults based on 
a simple selection of typical uses), but which is also configurable if you have 
unusual requirements.  This is what we aim to do with FreeBSD.


I have no problems with the sound system supporting different setups. I 
just fail to see the usefulness of such configuration, except in the 
very trivial setup, where you have only one output device and add 
another. What if there are three output audio devices in the systems? 
Trivial with all the HDMI etc today.


An overly auto-configuring system is a pain to deal with, sometimes. 
Especially if you cannot control some aspects of it's behavior. In such 
cases, you end up with a more complicated setup.



Don't make it so that even idiots can use it because then, only idiots will be 
using it!

This kind of argument has no place in FreeBSD.  You are not a better person 
because you use things that are hard to use.  You are not a better person 
because you choose to do things the difficult way.  You are not a better person 
because you prove your superiority by making life hard for others.

David


This was uncalled for, really.

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Daniel Kalchev]

On 02.04.14 04:26, Adrian Chadd wrote:

It's no longer xorg just speaks to the graphics chip.


This is a common trend in computing recently. What once required tightly 
integrated OS/applications is now distributed, in the widest sense. The 
so called Personal Computer is nowadays actually spread out all around 
the globe -- some of your desktop applications or parts of them might 
actually run in a data center far, far away. Having lots of diskless 
workstations in my office, all running FreeBSD and fact being dumb X 
Windows terminals to a bunch of servers, where the actually applications 
run -- it is sometimes very difficult to even begin explaining this 
concept to colleagues who have seen nothing but the Windows PC. The 
display, keyboard, mouse etc might be running their own and different OS 
each.


Therefore, I don't see this adding of abstraction layers as a bad thing, 
as it lets you have a FreeBSD workstation, running on an Android STB 
as the interface to your physical monitor/mouse/etc. What we should do 
instead is make sure that FreeBSD supports the respective APIs.


Considering that today visualization is everywhere, I also don't see any 
problem running that particular Windows, or Linux only application in 
an VirtualBox window. Or (in my example office case), running something 
(Linux?) on the diskless workstations that handles the peculiarities of 
the particular video chip/audio etc and still providing you with the 
same desktop session on your FreeBSD servers.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Leaving the Desktop Market

[Daniel Kalchev]

Hice April 1st piece,

Let's see what I could contribute :)


On 01.04.14 08:46, Eitan Adler wrote:

Hi all,

Some of you may have seen my posts entitled Story of a Laptop User
and Story of a Desktop User.  For those of you who did not, it can
be a worthwhile read to see what life is like when using FreeBSD as a
desktop.  In short, it is an educational experience.  While FreeBSD
can be coerced to do the right thing, it is rarely there by default
and often doesn't work as well as we would expect.


There is no platform that can do everything as you please. In fact, 
there can't be any such thing with computers, because they are not 
humans and only do what we humans instruct (program) them to do, not 
what we believe we programmed them to do. A slight difference, but 
important to see things in perspective.




The following are issues I haven't brought up in the past:

Battery life sucks:  it’s almost as if powerd wasn't running.  Windows
can run for five hours on my laptop while FreeBSD can barely make it
two hours.  I wonder what the key differences are?  Likely it’s that
we focus so much on performance that no one considers power.  ChromeOS
can run for 12 hours on some hardware;  why can't we make FreeBSD run
for 16?



Who said we can't? We did, do and will do that. On a case by case 
solution. This is strictly hardware specific issue and of course, no 
other OS can claim good power management on any hardware.



Sound configuration lacks key documentation:  how can I automatically
change between headphones and external speakers?   You can't even do
that in middle of a song at all!  Trust me that you never want to be
staring at an HDA pin configuration.  I'll bet you couldn't even get
sound streaming to other machines working if you tried.


Lack of documentation has always been the weak part of any enthusiast 
work. For people care more about getting the work done, than writing 
long essays. I would not go that far to say you can't switch audio 
outputs in a middle of a song (or why not, a movie?). After all, this is 
strictly hardware specific issue and of course, no other OS can claim 
good audio management on any hardware.



FreeBSD lacks vendor credibility: CUDA is unsupported.  Dropbox hasn't
released a client for FreeBSD.  Nvidia Optimus doesn't function on
FreeBSD.  Can you imagine telling someone to purchase a laptop with
the caveat: but you won't be able to use your graphics card?


Purchasing specialized hardware (a laptop), without being aware what 
software will drive it is always a very bad idea. As for those vendor's 
proprietary technologies, they don't function on many other modern 
platforms, not only FreeBSD. Then, there is choice -- you could use 
other vendor's technologies, if that suits you. Or, if (say) CUDA 
requires OS XYZ, use that instead of FreeBSD.  Not that this has 
anything to do with desktop.





In any case, half of our desktop support is emulation: flash and opera
only works because of the linuxulator.  There really isn't any reason
for vendors to bother supporting FreeBSD if we are just going to ape
Linux anyways.


If you will remember, most of this is because of different licensing 
restrictions imposed by those vendors. I am absolutely confident, Adobe 
will produce a very good Flash Player for FreeBSD, once you convince 
them there is money in that.




That is why on this date I propose that we cease competing on the
desktop market.  FreeBSD should declare 2014 to be year of the Linux
desktop and start to rip out the pieces of the OS not needed for
server or embedded use.


FreeBSD is not sold. There is no such thing as market for FreeBSD. 
Neither in Desktop, Server or whatever other arbitrary segments. In 
fact, FreeBSD is not even a product -- it is more of a toolkit, which 
you use to build your very own OS for your very own segment.


Yes, 2014 might very well turn out to be the year of Linux, but that is 
not because of FreeBSD -- Microsoft are helping much more with their 
insistence to kill Windows XP.





Some of you may point to PCBSD and say that we have a chance, but I
must ask you: how does one flavor stand up to the thousands in the
Linux world?



You mean, all those short lived species will arrive in hordes and 
destroy the Dragon? Might be, might be not. The dragon has seen 
thousands of those already come and go.


Having fun is most important in the process. :)

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Import of DragonFly Mail Agent

[Daniel Kalchev]

On 24.02.14 19:49, Mark Felder wrote:

We can strip pieces of FreeBSD off and end up with an kernel. Or we
could keep the system very much usable out of the box.


Imagine a world where everything in FreeBSD is a package and we have a
working PROVIDES framework. Upon installation you can choose the
software that provides the MTA role. Same for DNS, NTP, database,
webserver... That would be a great accomplishment along with a framework
to create a master install image utilizing the options/packages you
desire. I think this type of thing is definitely plausible if we keep
moving forward. My personal opinion remains that complex software is
better served/secured/maintained when it is handled in ports not in
base.



While I agree with all you say, it is worth noting that 
bind/sendmail/ntp have been very compatible with FreeBSD precisely 
because of their integration with the base system.


What we risk with everything is a port concept is that we live in a 
world that there is a lot of software to chose from, but from time to 
time, the software happens to be incompatible with FreeBSD in one way, 
or another. Another risk is the confusion of too much choice.


There is a fine balance to be found here.

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Import of DragonFly Mail Agent

[Daniel Kalchev]

On 24.02.14 13:47, Thomas Mueller wrote:

I don't believe BSD users use base system of itself to send and receive email.  
They use ports (FreeBSD) or equivalent in other BSDs.


One of the beauties of the BSD 'base system' is that upon installation 
you have an usable workstation/server environment that can be 
immediately used for most Internet-related tasks -- and this most 
certainly includes SMTP. Or NTP. Or... used to include DNS.


We can strip pieces of FreeBSD off and end up with an kernel. Or we 
could keep the system very much usable out of the box.


Indeed, the current integration of sendmail is far from optimal. In 
fact, BIND was better integrated but is now gone. NTP is also pretty 
well integrated -- it is nice to have ready access to such tools on 
*any* FreeBSD system.


If one needs to strip down FreeBSD, there are already plenty of tools to 
do it, including WITHOUT_SENDMAIL.


One of the many problems with removing functionality is very well 
illustrated by what happens now, when you upgrade an pre-10 system 
running nameserver: you end up without it and eventually without your 
nameserver database as well. Imagine, one day a user updates their 
10-stable to 11-stable only to find out mail is no more.


Currently, without any user configuration, sendmail is run in send-only 
mode. You need to explicitly request for it to not run at all. If there 
is suitable replacement that performs the tasks the send-only sendmail 
does, I see no problem to remove it. Or at least make it non-default for 
a release or two.


The only remaining issue to solve is I just upgraded FreeBSD and now 
mail is not working. Perhaps by installing sendmail with pkg if it is 
requested in rc.conf?


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: What happened to nslookup?

[Daniel Kalchev]

On 16.10.13 08:42, Kevin Oberman wrote:


nslookup(1) was deprecated about a decade ago because it often provides
misleading results when used for DNS troubleshooting. It generally works
fine for simply turning a name to an address or vice-versa.

People should really use host(1) for simple lookups. It provides the same
information and does it in a manner that will not cause misdirection when
things are broken.


Of course, host(1) is not a replacement for nslookup(1).

nslookup is interactive, while host is not. This makes for a big 
difference in many usage scenarios.


The decision to remove bind from base was poor, and not well 
communicated. Let's hope it will be reverted.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: GCC withdraw

[Daniel Kalchev]

On 23.08.13 14:16, Kurt Jaeger wrote:

Hi!


I have a patch that I intend to commit before the 10.0 code
slush that removes GCC and libstdc++ from the default build on
platforms where clang is the system compiler.  We definitely don't
want to be supporting our 6-year-old versions of these for the
lifetime of the 10.x branch.

Isn't it a POLA violation?

As for me I expect something like this:
. 9.x gcc default and clang in base;
. 10.x clang default and gcc in base;
. 11.x gcc withdraw.

If the 150 ports that only work with gcc, all work with a ports
gcc and do not need the gcc from base, would the following be OK ?

- 9.x gcc default and clang in base;
- 10.x clang default and gcc in ports;



I believe this is the best idea so far. As long as these ports work with 
gcc in ports, that is.


For many of the important ports, they do get used together with other 
ports that already require newer gcc from ports anyway. So no additional 
pollution will be created.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: svn error during 'make buildkernel'?

[Daniel Kalchev]

On 06.08.13 21:11, Matthew D. Fuller wrote:
Sure, right _now_ devel/subversion and base svnlite get along, but 
what happens when ports moves to 1.9 which changes the WT format? 
This is just one of the quirks that subversion has, in that it's 
database can't be easily parsed with other tools. Perhaps a fix might 
be caching the last revision number in a text file so you don't need 
svnversion in order to extract it from the source tree? A fix/patch to 
subversion, that is.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Light humour

[Daniel Kalchev]

On Apr 29, 2013, at 2:37 AM, Diane Bruce d...@db.net wrote:

 http://www.softpanorama.org/Copyright/License_classification/social_roots_of_GPL.shtml

By any measure a very good one. Could use some editing of course to make it 
easier to comprehend for readers of different cultures though … and simplify 
English sentences . :)

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Light humour

[Daniel Kalchev]

On 29.04.13 12:40, Julian H. Stacey wrote:

Daniel Kalchev wrote:

On Apr 29, 2013, at 2:37 AM, Diane Bruce d...@db.net wrote:


http://www.softpanorama.org/Copyright/License_classification/social_roots_of_GPL.shtml

By any measure a very good one. Could use some editing of course to make it 
easier to comprehend for readers of different cultures though … and simplify 
English sentences . :)

Daniel

I suggest others save time  not read URL above,
A skim finds pretentious verbiage, socioligist's analysis
of different views of GPL v BSD people v. Stallman ...
throughout the XIX century into the early XX

Cheers,
Julian



You just prove that guy's point. Ironically, as with everything else - 
any don't read it plea has exactly the opposite effect.


My observation is that the typical Russian soul kind of 
thinking/expression is pretty much incomprehensible in the western 
world. Some real gems are often ignored/lost because of this. As is, by 
the way the concept of Intelligentsia which is in the core of that 
particular article.


The author rightly points out that the different licensing models and 
the resulting different culture (of development, administration, usage) 
in the Linux and BSD worlds is the result of different perception and 
values. The different knowledge and understanding of the .. world too, 
plays a role. It's just like with how humans grow trough their life, you 
have one set of values as a child, other as young/adult and yet another 
as a senior person.


Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ipfilter(4) needs maintainer

[Daniel Kalchev]

On 14.04.13 21:55, Joe Holden wrote:
For non-nat ipfw is still superior in every way, numbered rules 
(think: scripts), dummynet, much faster than pf, syntax is a lot nicer 
and predictable...


And, best of all, it still is buggy. At lest, it's tables handling is 
unusable.


I have been very stubborn IPFW user for very long time, but finally gave 
up in favor of PF. Nothing like that ever since. I am also not convinced 
IPFW is any faster than PF.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Response of *.freebsd.org websites are very slow

[Daniel Kalchev]

On 27.02.13 12:23, Daniel Nebdal wrote:

I think you're supposed to be automatically sent to the mirror that is
closest to you - for some value of closest. If the mirror you're
getting has issues, that might show up like this. Could you post the
output of traceroute ftp.freebsd.org ? It should show which mirror
you're getting, and perhaps if there are any obvious problems on the
way.


I believe, in his case that would be traceroute ftp.tr.freebsd.org. 
The list of mirrors is here 
http://www.freebsd.org/doc/handbook/mirrors-ftp.html


in any case, anything *.freebsd.org actually refers to plenty of hosts 
all over the world -- some might be slow, some very fast.


On the other hand, Address could not be found type of errors indicates 
something else than fast or slow.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Response of *.freebsd.org websites are very slow

[Daniel Kalchev]

On 27.02.13 15:13, Fbsd8 wrote:

Mark Felder wrote:

On Wed, 27 Feb 2013 06:52:29 -0600, fb...@a1poweruser.com wrote:

Well I am in cleveland ohio usa and I have noticed that 
http://www.freebsd.org/handbook/  is slow or in most cases just 
times out. So this is bigger problem that some mirror being down in 
turkey.

It started about 10 days ago.


I can't reproduce this myself. Can you provide a traceroute?




Script started on Wed Feb 27 08:09:20 2013

# /root dated
Wed Feb 27 08:09:28 EST 2013
# /root traceroute www.freebsd.org
traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 40 byte 
packets

traceroute: sendto: Network is unreachable
 1 traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1
 *traceroute: sendto: Network is unreachable
traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1
 *traceroute: sendto: Network is unreachable
traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1
^C
# /root date
Wed Feb 27 08:10:05 EST 2013
# /root exit
exit

Script done on Wed Feb 27 08:10:15 2013



It seems you have some network filter for this address (perhaps anything 
8.8/16) at your router or on your computer. traceroute should have at 
least worked past your network...


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD Testing Facility

[Daniel Kalchev]

On 21.02.13 15:04, Mehmet Erol Sanliturk wrote:

Dear All ,

During development of FreeBSD , testing is very vital .

To my knowledge ( which may not be correct ) , at present ,
Tinderbox is used to only compilation correctness ,
means Syntax is tested .

I have downloaded

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso


and tried to install it on an Intel DG965WH main board .

During the first booting , it generated a panic message and entered into
debug mode .

For me it has crashed , because I do not know what to do in debug mode .



On this main board , it is possible to completely install and successfully
run

Windows 7 ,
Fedora 15 , 17 , 18 ,
Mageia
OpenSuSE


I stopped right here. None of the software you compare FreeBSD-current 
to is an development build. On the other hand, you downloaded an 
cutting-edge development build of FreeBSD (not released software) and 
expected it to be stable. It is not. This is why it is not released. It 
might not always break, but it might also damage your data and 
(possibly) hardware too. Unless you agree to accept these risks, you 
should not play with development versions of software.


Having said that, the DG965WH is quite old hardware and any stable 
version of FreeBSD should work just fine there. You are unlikely to see 
any benefit of the unreleased versions that are still in development, 
such as supporting very new hardware etc.


Sorry if any of this sounds too hard, but it is reflecting reality. This 
mailing list, freebsd-current exists to facilitate discussion between 
those, who know they are running highly unstable, still in development 
version of FreeBSD that needs lots of work to become more stable.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS/RAIDZ and SAMBA: abyssimal performance

[Daniel Kalchev]

On Jan 4, 2013, at 4:06 PM, Fleuriot Damien m...@my.gd wrote:

 
 And network cards:
 # Up a bit our intel cards parameters
 hw.em.txd=4096
 hw.em.rxd=4096
 hw.em.tx_int_delay=512
 hw.em.rx_int_delay=512
 hw.em.tx_abs_int_delay=1024
 hw.em.rx_abs_int_delay=1024
 

I am curious why we need to manually set up these values. Especially the 
txd/rxd -- here are few controllers supported by the em driver that can't 
handle 4096 descriptors and the choice could really be made at driver attach 
time.. That could also permit different em interfaces in the system (using 
different chips) to have different settings.

My belief is the auto tuning should set things up for maximum performance, 
given the hardware and if someone really needs smaller queues they could just 
use the tunables. 

Are there drawbacks?

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do

[Daniel Kalchev]

On 22.06.12 09:22, Hans Petter Selasky wrote:
I'm sorry to say a lot of USB flash sticks out there are broken and 
only tested with the timing of MS Windows. Part of the problem is that 
it is difficult to autodetect these issues, because once you trigger 
the non- supported SCSI command, then the flash key stops working like 
you experience.


Morale of the story: Don't even dare put any hardware that you need 
working on FreeBSD under control of Linux or Windows. grin

OS X is safe.

By the way, I am serious!

Sometimes, I am inclined to believe the conspiracy theory that those 
operating systems do this on purpose. Often to claim superiority as in 
see, it works with our OS, ok?.


I believe if we get enough details of how this particular USB stick is 
exactly recognized an quirk definition for it could be added to save 
future users from such behavior. But the bit it was used with Linux 
might need to be supplied by the user.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

On 07.06.12 02:09, Erich wrote:

Those minor issues are, having the recent mess in front of my eyes, a
simple negative exaggeration. What is that price worth, if the
system is faulting and rendered useless or partially useless?


just do what was recommended in this thread: wait.

Tell this ones to a commercial client. They will use words on you for which use 
you get a life ban on this list.


If you are not qualified enough to handle issues like this, you would be 
better to avoid offering your integration services to anyone. Or, of 
you dare to -- you fully deserve those people yelling at you, or worse..


Those who use FreeBSD to offer integration services and are qualified do 
not whine, neither they wait. Those people do what the promised to do: 
provide the customer with the requested solution.


No, you are not born with prior knowledge of how ports work on FreeBSD, 
it takes lots of time, effort and discipline to learn. You either invest 
in learning the basic skills required to offer your services to others, 
or you go play elsewhere.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

On 07.06.12 12:30, Erich wrote:

On 07 June 2012 12:17:14 Daniel Kalchev wrote:
just do what was recommended in this thread: wait. Tell this ones to 
a commercial client. They will use words on you for which use you 
get a life ban on this list. 

If you are not qualified enough to handle issues like this, you would be
better to avoid offering your integration services to anyone. Or, of
you dare to -- you fully deserve those people yelling at you, or worse..

Those who use FreeBSD to offer integration services and are qualified do
not whine, neither they wait. Those people do what the promised to do:
provide the customer with the requested solution.

No, you are not born with prior knowledge of how ports work on FreeBSD,
it takes lots of time, effort and discipline to learn. You either invest
in learning the basic skills required to offer your services to others,
or you go play elsewhere.


this is precisely the kind of answer which stops people from using FreeBSD.

Thank you for repelling more people and keeping the user base small.


None of this is unique to FreeBSD. It is exactly the same no matter what 
OS or other tool you use. Either you know your tools and do your job for 
the benefit of your customers. Or you don't know your tools, to the 
detriment of those who trusted your claims otherwise.


As expected, you got the last sentence wrong. I wasn't referring to 
FreeBSD, but to consulting and integration services :)

English is apparently not native to both of us.

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

On 07.06.12 13:58, Hartmann, O. wrote:

... in some cases this needs the deep knowledge of all ports/software
provided and used and this is simply impossible, or at least null
convergent probability.


Only God is required to know and be able to do everything. We humans can 
be imperfect.



In some cases I see a dicrepancy between what is reality and what is
predicated. If it comes to the evidence, that something has been
mismanaged, then there is always this allmighty excuse: FreeBSD is a
volunteer system developed by volunteers blabla. I'm also a volunteer
using FreeBSD! And I spend a lot of time trying to help.


There was recently an very nice short announcement on how/why Netflix 
has decided to use FreeBSD as the base for their delivery infrastructure 
platform. You understand, that Netflix are serious about this. According 
to them, they have identified where the current state of FreeBSD needs 
help and contributed their fixes back to the community voluntarily (they 
are not required by the BSD license, unlike with GPL).


I didn't read any excuse on part of Netflix why they can't use FreeBSD.


But at some points this gets very frustrating! Totally corrupted ports
(not FreeBSD itself!), and so a corrupted system, no fallback mechanism
although the problem is there for decades by now (as stated in this thread).


Why the whining?

I too am sometimes frustrated that the ports tree gets broken from time 
to time. Usually  this means I will have to spend more time on it. Time 
is something I don't have much to spare. But I know that whining does 
not help. Learning is faster.


I also know there *is* fallback mechanism here. One that was explained 
in this thread a number of times: sync your ports tree to a non-broken 
date. Usually, just the day before the announcement that broke it 
appears in /usr/ports/UPDATING is enough.


I also see your problem with Thunderbird and LDAP. But you didn't 
provide enough information, except it does not work. So let's try to 
narrow it a bit:


- does the same setup work with another OS? (the same setup, same 
software versions)

- you imply interaction with Firefox. Is Firefox crashing too?
- have you traced the crash to specific library (there should be enough 
error messages, or at least core file to investigate)?
- have you considered that this all might be configuration problem of 
some sort? Or using some non-standard compiler like GCC 4.6? I know it 
is always FreeBSD's and not user fault, but still...



I guess there are plenty of reasons as well as there are plenty of
reasons of the opposit. But one very frustrating scaring thing is the
arrogancy of several people here - leveling out the great help of those
who wish to help.
I don't know about others, but I won't buy your attempt at social 
engineering here.


Like I said, you are either capable of doing certain job, or you are 
not. Blaming others for your lack of knowledge on certain subject is not 
very productive. Claiming that those who suggest the problem might be 
sometimes caused by the device in front of the computer are arrogant is 
even less productive.


By the way, asking a question politely is going to produce a lot more 
useful replies, than tell me this, you bunch of arrogant FreeBSD users!.


Or to put it in summary: if you are not critical to yourself, there is 
no point being critical towards others, much less FreeBSD.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

On 06.06.12 05:31, Erich wrote:

On 05 June 2012 10:55:57 Chris Rees wrote:

It is absolutely a bad idea for beginners to be using tagged/dated
ports trees-- they are not supported and will lead to many complaints
about problems that were solved since the tag.

How do they fall back when things went wrong?

The handbook states that there is no fall back option.

Their fall back option has a name: Windows.


No need for Windows propaganda here. We have had enough of this already. 
Thanks.


By the way, for those who tried FreeBSD and found it too much, there 
is another, way better alternative: OS X
Someone else does the packaging, testing etc. for you and you still 
don't run Windows :)


This, of course, if the person, unlike you, does not ignore the advice 
to use PC-BSD. The same FreeBSD, with someone else taking care of 
watching the ports tree, configuring, compiling, packaging etc.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

On 06.06.12 05:35, Erich wrote:

Warning: Be very careful to specify any tag= fields correctly. Some tags are 
valid only for certain collections of files. If you specify an incorrect or 
misspelled tag, CVSup will delete files which you probably do not want deleted. 
In particular, use only tag=. for the ports-* collections.'

I think that this states very clearly that there are no tags.

So, after we learned that every thing I am asking is there anyway in an 
official and supported way, only the documentation has to be changed.


It does not state, that there are not tags. It states, that you should 
be using tag=.
Unless, you know exactly what are you doing and unless you know what an 
particular tag that exists in the ports tree means.


In your language: normal users of the ports tree should use tag=. as 
anything else is not official and not supported.
Normal users can specify date=somedate to get the version of the ports 
tree as it was on that date (and time, up to a second).


The documentation is correct.

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

On 03.06.12 23:55, O. Hartmann wrote:

On 06/03/12 15:29, Erich wrote:

yes, you miss a very simple thing. Updated this morning your ports tree. Your 
client asks for something for Monday morning for which you need now a program 
which needs some kind of PNG but you did not install it.

... I spent now two complete days watching my boxes updating their
ports. Several ports do not compile anymore (inkscape, libreoffice,
libxul, to name some of the very hurting ones!).


Someone forced you to recompile your ports? :)

Just for the record, I too saw a lot of re-compilation necessary because 
of this PNG library update and for the most part, this was not 
necessary, but unfortunately this is how the ports dependencies are 
described by their maintainers - the upgrade tools like portmaster or 
portupgrade can hardly help much here.


Anyway, I am rebuilding on occasions like this just for the fun of it. 
Always have spare/backup system to work on while my primary desktop 
rebuilds because it breaks from time to time. By the way, this rebuild 
didn't give my lowly dual-core core2 6300 at 1.86 GHz much trouble.


In any case, suppose a customer comes and asks for an application that 
uses PNG, you just updated your ports tree and then you either:


1. Have already libpng installed.
Then you just don't rebuild libpng, just install the new software. You 
do this by going to the ports directory like 
/usr/ports/cathegory/greatstuff and type make install. This will use 
the existing libpng on your system. No trouble.


2. Don't have libpng installed yet.
You install the new port any way you like. Since you have no libpng on 
your system, you have no dependencies to upgrade (and wait). You will 
end up with the new libpng on your system. No trouble.


Applying some common sense to these situations helps great deal. It also 
helps to avoid any prejudice towards FreeBSD or whatever OS you end up 
using in the process.



Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Daniel Kalchev]

I had few troubles compiling OpenOffice, until closer inspection, that revealed 
I had forgotten to remove the redirection of libs to gcc4.6 in /etc/libmap.conf 
-- left from my experiments to like it for compiling ports… (with the pipe 
dream software will run faster)

After cleaning my system of this junk completely, OpenOffice built just fine 
from the first try. Needless to say, this wasted few days for me -- but it was 
entirely my fault.

Daniel

On Jun 3, 2012, at 2:03 AM, Jakub Lach wrote:

 Hmm... Speaking of libreoffice
 
 ERROR: error 65280 occurred while making
 /usr/obj/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj
 
 ?
 
 --
 View this message in context: 
 http://freebsd.1045724.n5.nabble.com/Re-Why-Are-You-NOT-Using-FreeBSD-tp5714253p5714383.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC

[Daniel Kalchev]

On 29.12.11 14:19, O. Hartmann wrote:

Am 12/29/11 12:59, schrieb Kostik Belousov:

On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote:

[...]
/usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_'
can not be used when making a shared object; recompile with -fPIC
lapi.o: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
*** Error code 1

Stop in /usr/ports/lang/lua/work/lua-5.1.4/src.
*** Error code 1

Stop in /usr/ports/lang/lua/work/lua-5.1.4/src.
*** Error code 1

Stop in /usr/ports/lang/lua/work/lua-5.1.4.
*** Error code 1

Stop in /usr/ports/lang/lua.

===  make failed for lang/lua
===  Aborting update

Terminated
Terminated

This is very strange!

What is strange ? It is exactly the same problem as in the first message
started this thread. You must use -fPIC flag for compiler when compiling
objects that shall be later linked into dso. So, for lua case, -fPIC
must be present on the cc -c command line.

This therefore strange, since this problem with lua occurs on machines,
where I've set CFLAGS= and COPTFLAGS= as in
/usr/share/examples/etc/make.conf and on one box, one box I accidentally
set those flags to CFLAGS+= and COPTFLAGS+= and there it works and
the -fPIC flag is set by the FreeBSD's port framework.

So I guess there is a bug introduced with one of the last Mk-files updates.



As suggested by the howto for using newer GCC versions, 
http://www.freebsd.org/doc/en/articles/custom-gcc/article.html you are 
supposed to use CFLAGS+= to add additional compile flags.


By the way, -O2 -fno-strict-aliasing -pipe are the default flags, that 
are used when CFLAGS is not set by the user.


COPTFLAGS is used only to build the kernel and doing it with non-system 
GCC is not likely to be safe.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 23.12.11 03:17, O. Hartmann wrote:
Or even look at the thread regarding to SCHED_ULE. Why has a user, 
experiencing really worse performance with SCHED_ULE, in a nearly 
scientific manner some engineer the fault? I'd expect the developer or 
care-taking engineer taking care in a more user friendly manner.


You remember that those developers are not paid to do what they do?
You remember that nobody has sold you this OS and promised support in 
whatever form?


Still, this issue is discussed publicly and experiments are being made, 
I guess also new code is being experimented.
If you are interested in the outcome, just follow the discussion. If you 
can help with something and you are willing, please do. There will be 
good solution to the SCHED_ULE shortcomings.


FreeBSD is unique group of people, who all sit on their eggs, be it eggs 
they themselves produced, or they inherited one way or another. These 
people include all the developers and most of the system administrators 
and users of FreeBSD. There is no they and us.


If your preference for the OS is different, you might feel more 
comfortable in choosing another OS, probably a commercial OS with 
support from the vendor.


If a benchmark reveals some severe weak points in FreeBSD and I have 
to read about obscure tweaks of non documented sysctl, then this OS 
would be a no-go if I was a manager to make decissions. 


Luckily, managers do not care about knobs or how difficult it is for the 
system administrator to achieve specific goal. All they care is the 
bottom line in general and in short therm the goals they have set. No 
sane manager will care about benchmarks, as long as he gets what he wants.


Back, to the Phoronix benchmarks. There has already been communication. 
Phoronix were given advices on how to better do some things on FreeBSD 
(which will make the quality of their benchmarks better and therefore 
more trusted). Phoronix has made their updated test suite available to 
FreeBSD users (that include developers) to try on their own hardware. By 
the way, it is in /usr/ports/benchmarks/phoronix-test-suite.


Linux and FreeBSD are not enemies, they both solve the same problems 
with different means.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 23.12.11 08:47, Martin Sugioarto wrote:
A further thing is that I cannot understand the people here sometimes. 
I would like that the -RELEASE versions of FreeBSD perform well 
without any further optimizations.


The -RELEASE things is just a freeze (or, let's say tested freeze) of 
the corresponding branch at some time. It is the code available and 
tested at that time.


Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than 
FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed 
between both code bases, lots of bugs have been discovered and fixed and 
new technologies have been integrated. Especially in this line, the 
compiler has changed from 4.2.1 to 4.2.2.


When the distribution does not compile with the latest compiler it's 
simply a bug.


FreeBSD is not a distribution. It also compiles with the latest compiler 
- LLVM. :)


I find it amusing, that people want everything compiled with GCC 4.7, 
which is still very much developing, therefore highly unstable and 
(probably) full of bugs.


Why should one try to penalize the other distribution and downgrade 
their binaries?


Many suggested that the Linux binaries be run via the FreeBSD Linux 
emulation. Unchanged.

There is one problem here though, the emulation is still 32 bit.

When FreeBSD has a bad default setup, there must be a reason for that. 
Tell me this reason and show me that it's justified in form of some 
other benchmark.


FreeBSD has safe default. It is supposed to work out of the box on 
whatever hardware you put it. As much as it has drives for that 
hardware, of course.

Once you have working installation, you may tweak it all the way you wish.

If your installation is pre-optimized, chances are it will crash all the 
time on you and there will be no easy way for you to fix, short of 
installing another distribution.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 23.12.11 12:48, O. Hartmann wrote:
Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a 
way that is far beyond enough! He gave tests, insights of his setup, 
bad performance compared to SCHED_4BSD and what happend? We are still 
stuck with this problem and more and more people realise, that FreeBSD 
does have somewhere a problem and this seems to be a nasty problem not 
easy to find or investigate.


This has made me to realize, that I was having a problem with SCHED_ULE 
that I was not aware of until now. WOW! :)


Every scheduler has some problem, some fail here some fail there. I am 
confident, that the case that Steve Kargls has reported will be resolved.


Another problem is this very elite-feeling closed club. Once you 
managed it getting into the club of committers or core team members, 
you'll probably fight for your seat ... I dont propose for that 
socialists crap Linux people tend to be like,

[..]

You never heard of the People's Republic of Berkeley? :)

As for commiter access, this sort of comments trigger the system 
administrator in me. I have seen enough people, who for the lack of 
other excuses always use but I don't have enough RIGHTS!. I am evil, I 
know


But I follow the illusion that if people can see what benchmarks 
reveal, they start thinking and if the facts are starting to give a 
heavy load load on those rejecting the facts, they migght change their 
opinion or get hopefully replaced by more openminded people.


Here is now it works:

If you see an problem and have a solution: go fix it. Many will be grateful.
If you can't fix it, but have an idea how to fix it, share it. May will 
be grateful.
If you can't fix it and don't have any idea, just say there is a 
problem and stop there. There are many, many, many like you who just 
hold their breath.


We all learn, every day.

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 23.12.11 16:47, Martin Sugioarto wrote:
I thought that the D in FreeBSD stands for distribution. Yes, it's 
ok that it compiles with LLVM. Does it also run faster in benchmarks? 


It does. From a language perspective. It is a distribution, because at 
the times BSD was developed, it was not a complete operating system. It 
was supposed to be added to say ATT System V to make it networking 
capable etc.


The Linux people use the word distribution in a different context.

I don't want to have everything compiled on $COMPILER. I want that 
there is a reasonable quality. And for me quality is not only 
stability, but also speed. 


You can always have faster algorithm if it is not necessary to produce 
the right answer.


But if you don't tweak, you get a fair result in a benchmark. This is 
what you will see as a user of the system. These are the default 
settings, that means developers chose them as the BEST choice for the 
system. 


Developers are not Gods. Developers have no clue on what system and for 
what purpose you will use the software. All they may do for you is to 
provide enough knobs for you to tune your system for your 
hardware/application and also make sure that the system scales, when you 
turn the knobs.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 22.12.11 11:02, Johan Hendriks wrote:

Stefan Esser schreef:

Am 21.12.2011 22:49, schrieb Johan Hendriks:

If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux
to 4.2.1, then that will tell me nothing about FreeBSD vs Linux.

The gcc version distributed with FreeBSD was chosen for license reasons,
not for technical reasons. If you are OK with installing a GPLv3
licensed compiler on your systems, then just do it and take advantage of
the improved code generated by it.
It does not matter what the decission is to use the old compiler, it 
is a fact that the base comes with 4.2.x
Does that mean we can not compare/benchmark against other 
distributions because they use GPLv3 stuff.


If you intend to compare operating systems 'as shipped', then forget 
about comparing third party programs on top of these operating systems. 
Compare only any software that is already available with the operating 
system, as shipped.


There is plenty of software in the base system and this software is 
specifically different (say) in FreeBSD and Linux.


Anyone made such comparison?


No, i want to know where standard released FreeBSD stands against 
standard released Linux distributions.
If you compare benchmark userland applictions, then it is fair to use 
the latest compiler for the userland software also on FreeBSD.
But what if the ports tree defaults to LLVM, then again we want to 
know what FreeBSD does against a Linux distribution.

Why because that is what most of us will be using...!!


It is pretty easy to tell the ports system to use latest gcc, as 
described here 
http://www.freebsd.org/doc/en/articles/custom-gcc/article.html




If we start to compile all the ports with gcc 4.7 to be on par in 
comparising and benchmarking, why spend all the time getting LLVM as 
the default compiler for ports also?


Because, FreeBSD attempts to be as GPL free as possible. GPL is 
incompatible with many of the applications of FreeBSD.


Why not take that effort into making the WHOLE ports tree to compile 
with GCC4.7?


This has already been done. See above.



Reason, because FreeBSD goes the LLVM route. That is a decission 
FreeBSD is making!


LLVM, as well as GCC are just choices in FreeBSD.

What FreeBSD is making is, to make it safe to use LLVM to compile 
everything on FreeBSD, including the kernel.


As you may have already noticed, some ports require to be compiled with 
a specific version of gcc, or a very specific compiler -- there is 
nothing wrong with this -- this is external software after all.


And that choise will be the FreeBSD that is used in comparising and 
benchmarks on the net , not the utterly overcopiled and tuned FreeBSD 
against stock Ubuntu or whatever Linux distribution.


Earlier on this thread I mentioned, that FreeBSD and Linux philosophies 
differ. While Linux (well, some distributions, to be correct) will try 
to optimize certain parts of the OS/applications in order to do well in 
benchmarks -- FreeBSD takes a different approach. The FreeBSD (and BSD 
UNIX, in general) approach is do the right thing. This may produce the 
results slower, but the environment is more stable in general and in the 
long run, the results noticeable better.


This argument, by the way reminds me of the ATT vs BSDI lawsuit, where 
at the time UCB was involved there was lengthly discussion (at court), 
about sloppy programming, but we had to have something for the 
deadline (ATT) vs well, we have designed the architecture we think is 
appropriate, there might be few unimplemented things, but we are working 
on it.




Same goes for the scheduler! and all the other subsystems FreeBSD has 
choosen, that makes FreeBSD.


What about the scheduler?




Yes you can use a more advanced compiler on FreeBSD, BUT you can do 
that on Linux also ,so where do you stop?


Can you compile the entire Linux system, kernel and userland and 
external packages with LLVM?


Are you going to spend a month to compare a fullly tuned up FreeBSD 
system against a Linux distribution?


I would do that, if:

- I have a task for which I need tuned system (that is, hardware would 
be at limits);

- The application is available on both;
- There is evidence or suggestion that the application under Linux will 
perform much better;


No because the users will not spend months tuning and recompile there 
servers.

They use the FreeBSD version that comes with the CD!


On servers? :-)


And that we want to compare/benchmark against a Linux distribution.


No, we don't. We run our servers, we don't want to compare/benchmark 
them with Linux for no reason.


We want however to identify design or implementation weaknesses in 
FreeBSD and fix these. This rarely happens by comparing to Linux 
distributions. There are better things to be observed in say, Solaris.


If we were selling FreeBSD, we would be interested in publishing 
benchmarks that demonstrate how superior to Linux it is. We would tune 
FreeBSD to beat Linux in most 

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 22.12.11 11:56, Igor Mozolevsky wrote:

On 22 December 2011 05:54, Daniel Kalchevdan...@digsys.bg  wrote:

  Of course, it is meaningless, the Ferrari will lose big time in the fuel
consumption comparison! I believe it will also lose the price comparison as
well. Not to speak the availability comparison.

That's an oxymoron, right? The comparison cannot be meaningless---the
reality is F430 will indeed use up more fuel than Prius. If a
benchmark demonstrates a true reality, how can that benchmark be
possibly meaningless??? Same benchmark might be irrelevant to someone
who wants to know how fast they can get from A to B, but irrelevant is
not a synonym for meaningless!


That benchmark is especially meaningless and a waste of time, because by 
design the Prius is constructed to consume 'less' fuel at the cost of 
lower engine power and the Ferrari is designed to waste fuel for the 
sake of high engine power.

Of course, you can compare them, but this is not exactly benchmark.

As for how fast to get from point A to point B. If you observe speed 
limits, that will depend only on the pilot, no? :)

Both cars are sufficiently faster than the imposed speed limits.

The same can be said for the FreeBSD and the Linux platforms. Today. 
Years ago, Linux was much worse, but they.. hm.. learned. :)
On commodity hardware, you can expect about the same results from both 
OS. There will be differences due to drivers, different optimizations etc.
On very specific hardware, such as systems with many CPUs and lots of 
memory, you may see one better than the other -- this in most cases will 
be relevant to tuning, but also to overall system architecture.





Any 'benchmark' has a goal. You first define the goal and then measure how
different contenders achieve it. Reaching the goal may have several
measurable metrics, that you will use to later declare the winner in each.
Besides, you need to define a baseline and be aware of what theoretical
max/min values are possible.

Treating a benchmark as a binary win/lose is rather naive, it's not a
competition, and (I hope) no serious person ever does that. A proper
benchmark shows true strength and weaknesses so than a well-informed
intelligent decision can be taken by an individual according to that
individual's needs. The caveat, of course, is making your methodology
clear and methods repeatable!


Err... a benchmark produces metrics. It does not produce conclusions. Or 
at least, should not :)
It takes context and understanding of both the subject and methodology 
used to draw any conclusion out of particular benchmark.


No benchmark shows strengths and weaknesses -- these are subject of 
interpretation and any 'score' you have in a benchmark might be the 
result of poor benchmark design and/or implementation.


You may make an very scientific, well documented and repeatable 
benchmark, such as this one:


time dd if=/dev/zero of=/dev/null

.. then optimize your particular OS to run it at the highest possible 
rate... and so what? Do you know what this benchmark measures? :)


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 22.12.11 12:50, Igor Mozolevsky wrote:

On 22 December 2011 10:12, Daniel Kalchevdan...@digsys.bg  wrote:


As for how fast to get from point A to point B. If you observe speed limits,
that will depend only on the pilot, no? :)
Both cars are sufficiently faster than the imposed speed limits.

You are ignoring acceleration, handling, and other factors... Besides,
you're missing the point: *given same conditions* a benchmark allows
one to show how A performs compared to B, which is why I said it is
important to keep everything else constant! At the end of the day,
what users, sysadmins,c want to know is given hardware configuration
H and requirement R will software X outperform software Y or Z. The
components and the bells and whistles of X, Y or Z are, quite often,
irrelevant (unless one has some silly idealogical reason, for
example).


None of the benchmarks measure 'comfort'.
None of the benchmarks measure how the system 'feels' while performing 
an numerical computation.

The benchmarks measure how soon the computations are finished.

You typically achieve that by tuning the OS to say, ignore any 
interactivity at the cost of focusing all resources to compute-intensive 
tasks.
If you use the same hardware, the CPU can do only so much and if there 
are any differences, that will be in how the OS asks the CPU to do other 
things, besides the task you benchmark.


You need to define your criteria. Otherwise the benchmark cannot be used 
to make comparisons.



On very specific hardware, such as systems with many CPUs and lots of
memory, you may see one better than the other -- this in most cases will be
relevant to tuning, but also to overall system architecture.

Are you saying that careful tuning will give you _orders of magnitude_
performance increase? Got numbers to back that up? ;-)


Ah.. now we are talking :)

Two things:

Someone once said, that you may have an very fast computation if only 
you need not make sure the results are correct. So yes, you can! :)


It is all too easy to make things worse, from the theoretical baseline. 
So often we measure not how 'good' an OS is, but how 'bad' it actually 
manages the hardware.


Well.. there is also some hardware that has limitations and you need to 
define the benchmark in a specific way to not touch them. Or you may 
have specific OS trying to avoid touching them -- and thus providing you 
with 'performance'.



You may make an very scientific, well documented and repeatable benchmark,
such as this one:

time dd if=/dev/zero of=/dev/null

.. then optimize your particular OS to run it at the highest possible
rate... and so what? Do you know what this benchmark measures? :)

Yes, do you? I hope you are not being deliberately obtuse here...


I know, that different people will see different things being measured 
here. Let's see if someone else will jump in. (which is the purpose of 
this example)



Besides, I would criticise your test in this example: have you tried
running that with, say, bs=1g count=1000?


That would measure different things. :)


Is there a difference how fast FreeBSD completes that vs how fast a Linux box 
does the same?


Why not? I would expect there will be difference in how fast different 
versions of FreeBSD complete it as well.


It could be also interesting to measure (although it's somewhat 
subjective) how interactive both systems stay during this task.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 21.12.11 23:49, Johan Hendriks wrote:


I my opinion, you benchmark the latest release of Linux, FreeBSD, 
Solaris, Windows and whatever OS you want to compare!




There is no 'general benchmark' as there is not one single tasks that 
all computers are used for.


If you want to benchmark something, then you define that something, tune 
all test subjects appropriately for that one thing and run the same test 
load. You then go on and claim 'for task X, the OS Y was best, followed 
by ...'.

This is what people have done for PostgreSQL for example.

You may try to see how, with that same settings different OS will 
perform with varying conditions, like what the PostgreSQL test did -- 
performance over the network and performance to localhost.


Testing a system, tuned for a file server as X workstations will not 
tell you much about the abilities of the different operating systems to 
run a web server, or either file server or X workstation.


By the way, the gcc in 8-stable is

gcc version 4.2.2 20070831 prerelease [FreeBSD]

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 22.12.11 00:33, Igor Mozolevsky wrote:
Using the same argument one can say that Ferrari F430 vs Toyota Prius 
is a meaningless comparison because the under-the-hood equipment is 
different.


 Of course, it is meaningless, the Ferrari will lose big time in the 
fuel consumption comparison! I believe it will also lose the price 
comparison as well. Not to speak the availability comparison.


You say that comparison is meaningless, yet you intend to compare those 
two cars?


Any 'benchmark' has a goal. You first define the goal and then measure 
how different contenders achieve it. Reaching the goal may have several 
measurable metrics, that you will use to later declare the winner in each.
Besides, you need to define a baseline and be aware of what theoretical 
max/min values are possible.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On 20.12.11 11:42, Garrett Cooper wrote:
As long as I have reliable checksums that match the what the upstream 
source says is the real thing, it doesn't practically matter where I 
get my images from.


Relying on checksums that are published on the same web site where you 
download the files from and given that most of these sites do not even 
use SSL so much about 'security'.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

I have already canceled few replies to this thread, but...

On 19.12.11 15:16, Alexander Yerenkow wrote:

IMHO, no offence, as always.


I feel obliged to include the same disclaimer :-)


As were told, Phoronix used default setup, not tuned.


Not really. They created some weird test environment, at least for 
FreeBSD -- who knows, possibly for Linux as well.


For example, ZFS is by no means a default file system in FreeBSD. You 
need to go trough manual steps, to enable it, to build the pool, 
filesystems etc. This is because ZFS is very powerful file system and 
storage manager that needs some thinking before you implement it -- then 
it may reward you with features not found anywhere else.


Funny, ZFS is available in Linux too, and at least the file system tests 
might benefit from using one and the same file system. One would expect 
that ZFS was used for both, in a multiple-disk (way over 4 disks) setup, 
as one would expect to be the case for a 'server'.



So? Is average user will tune it after setup? No, he'll get same defaults,
and would expect same performance as in tests, and he probably get it.


You forget, that the FreeBSD type and the Linux type are quite 
different. This is why both worlds exist.
The FreeBSD way is to understand what you do and configure your 
environment accordingly. FreeBSD gives you flexibility to do as you 
please and in most of the possible configurations it will work. Maybe 
not optimally, but will not break on you. With FreeBSD there is never 
one true way to do things.
The Linux way on the other hand is to follow a HowTo instruction. The 
Linux OS is typically optimized for these setups and as long as you 
follow the HOWTO you are safe and well performance-wise. If you go way 
out of the prescriptions in the HOWTO, you may end up with losing data, 
crashing system or extremely poor performance.


I know, things are not that black and white, but this is the general 
difference.



But problem really is lacking of choosing them (defaults) during install,
for average users.


Who are the average users? It has been repeatedly said, that the PC 
user is always better to start with PC-BSD, because it is FreeBSD with 
safe defaults suitable for a desktop.



For example, few checkboxes with common sysctl tuning would be perfect,
even if they would be marked as Experimental, or not recommended.


By following this, we push FreeBSD into the Linux style of doing things: 
someone else decides what is good for you, without having a clue of your 
circumstances.



Simple example - many connections for PostgreSQL is not available on
FreeBSD out-of-box. Just google postgresql freebsd max connection and
you'll see how many there bikesheds requested and same solutions posted
again and again :)


Still, PostgreSQL is not part of FreeBSD. The PostgreSQL port clearly 
says what you need to adjust in your setup in order to use it. As do 
most other ports.


Computers do what people ask them to do -- we are far from the AI times, 
when the computers will assembe, configure and run themselves the way we 
think they should.



FreeBSD currently have very obscure, closed community.


Some say this is a feature ;-)


To get in touch, you need to subscribe to several mail lists, constantly read 
them, I've just found recently (my shame of course) in mail list that there is 
service (pub.allbsd.org) which constantly building current versions. This is 
great,
but at homepage of freebsd.org there is no word about it :)


There is a menu Community on www.freebsd.org and an Forums entry there.
You don't have to use mailing lists, of you prefer forums.


I hope we all do something good about this, and things will going to change.


Many bright people do a lot of things about all of these issues.

If there is a problem, one needs to understand the problem, what causes 
the problem and what are the implications. Merely reacting on the 
symptoms never helps in the long run, as the core problem is not resolved.

So far in this thread there is no evidence of where the problem is.
There is no evidence even if there is a real problem -- except that many 
people get overly excited by benchmarks.


To the last point I could add that, with experience, one learns that: 
the benchmarks done in your environment, with your settings, with your 
OS version, on your hardware and with your set of applications does not 
help me much on my hardware/software/configuration -- except if these 
happen to be very similar.

/usr/ports/benchmarks is your friend.

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Uneven load on drives in ZFS RAIDZ1

[Daniel Kalchev]

I have observed similar behavior, even more extreme on a spool with dedup 
enabled. Is dedup enabled on this spool?

Might be that the DDT tables somehow end up unevenly distributed to disks. My 
observation was on a 6 disk raidz2.

Daniel___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Uneven load on drives in ZFS RAIDZ1

[Daniel Kalchev]

On Dec 19, 2011, at 11:00 PM, Stefan Esser wrote:

 Am 19.12.2011 19:03, schrieb Daniel Kalchev:
 I have observed similar behavior, even more extreme on a spool with dedup 
 enabled. Is dedup enabled on this spool?
 
 Thank you for the report!
 
 Well, I had dedup enabled for a few short tests. But since I have got
 only 8GB of RAM and dedup seems to require an order of magnitude more
 to be working well, I switched dedup off again after a few hours.

You will need to get rid of the DDT, as those are read nevertheless even with 
dedup (already) disabled. The tables refer to already deduped data.

In my case, I had about 2-3TB of deduced data, with 24GB RAM. There was no 
shortage of RAM and I could not confirm that ARC is full.. but somehow the pool 
was placing heavy read on one or two disks only (all others, nearly idle) -- 
apparently many small size reads.

I resolved my issue by copying the data to a newly created filesystem in the 
same pool -- luckily there was enough space available, then removing the 
'deduped' filesystems.

That last operation was particularly slow and at one time I had spontaneous 
reboot -- the pool was 'impossible to mount', and as weird as it sounds, I had 
'out of swap space' killing the 'zpool list' process.
I let it sit for few hours, until it has cleared itself.

I/O in that pool is back to normal now.

There is something terribly wrong with the dedup code.

Well, if your test data is not valuable, you can just delete it. :)

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Uneven load on drives in ZFS RAIDZ1

[Daniel Kalchev]

On Dec 19, 2011, at 11:53 PM, Dan Nelson wrote:

 
 Since it looks like the algorithm ends up creating two half-cold parity
 disks instead of one cold disk, I bet a 3-disk RAIDZ would exhibit even
 worse balancing, and a 5-disk set would be more even.

There were some experiments a year or two ago with different number of disks in 
raidz and the results suggested that certain number of disks had better 
performance, contrary to theory that writes should be evenly distributed. 
Worse, this is in the official theory of how raidz operates…

Perhaps the code can be fixed to spread the writes to all devices in raidz, but 
compatibility issues need to be considered.

Perhaps DDT is stored in the 'worst case' write size, because it clearly 
exhibits such poor distribution.

Daniel___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On Dec 15, 2011, at 3:48 PM, Jeremy Chadwick wrote:

[…]
 That said: thrown out, data ignored, done.
 
 Now what?  Where are we?  We're right back where we were a day or two
 ago; meaning no closer to solving the dilemma reported by users and
 SCHED_ULE.  Heck, we're not even sure if there is an issue, other than
 some folks confirming that SCHED_4BSD performs better for them (that's
 what started this whole thread), and there are at least a couple which
 have stated this.

But, are any of these benchmarks really engaging the 4BSD/ULE scheduler 
differences? Most such benchmarks are run on a system with no other load 
whatsoever and in no way represent real world experience.

What is more, I believe in such benchmarks the system feels sluggish is not 
measured at all. Even if it is measured, if in such case the benchmark finishes 
better - that is, faster, or say, makes the system freeze for the user for 
the duration of the test -- it will be considered win, because the benchmark 
suite ran faster on that particular system -- whereas a system which ran the 
benchmark fast, provided good interactive response etc would be considered 
loser.

I think it is not good idea to hijack this thread, but instead focusing on the 
other SCHED_ULE bashing thread to define an reasonable benchmark or a set of 
benchmarks rather -- so that many would run it and provide feedback.


Daniel___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Daniel Kalchev]

On Dec 15, 2011, at 3:25 PM, Stefan Esser wrote:

 Am 15.12.2011 11:10, schrieb Michael Larabel:
 No, the same hardware was used for each OS.
 
 In terms of the software, the stock software stack for each OS was used.
 
 Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with
 journaling enabled) should be an obvious choice since it is more similar
 in concept to ext4 and since that is what most FreeBSD users will use
 with FreeBSD?


Or perhaps, since it is server Linux distribution, use ZFS on Linux as well. 
With identical tuning on both Linux and FreeBSD. Having the same FS used by 
both OS will help make the comparison more sensible for FS I/O.

Daniel___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

On 07.12.11 22:23, Luigi Rizzo wrote:


Sorry, forgot to mention that the above is with TSO DISABLED
(which is not the default). TSO seems to have a very bad
interaction with HWCSUM and non-zero mitigation.


I have this on both sender and receiver

# ifconfig ix1
ix1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=4bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO

ether 00:25:90:35:22:f1
inet 10.2.101.11 netmask 0xff00 broadcast 10.2.101.255
media: Ethernet autoselect (autoselect full-duplex)
status: active

without LRO on either end

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.051 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1802.4049 MB in 5.06 real seconds = 365077.76 KB/sec = 
2990.7170 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 28839 I/O calls, msec/call = 0.18, calls/sec = 5704.44
nuttcp-t: 0.0user 4.5sys 0:05real 90% 108i+1459d 630maxrss 0+2pf 87706+1csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1802.4049 MB in 5.18 real seconds = 356247.49 KB/sec = 
2918.3794 Mbps

nuttcp-r: 529295 I/O calls, msec/call = 0.01, calls/sec = 102163.86
nuttcp-r: 0.1user 3.7sys 0:05real 73% 116i+1567d 618maxrss 0+15pf 
230404+0csw


with LRO on receiver

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.067 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 2420.5000 MB in 5.02 real seconds = 493701.04 KB/sec = 
4044.3989 Mbps

nuttcp-t: host-retrans = 2
nuttcp-t: 38728 I/O calls, msec/call = 0.13, calls/sec = 7714.08
nuttcp-t: 0.0user 4.1sys 0:05real 83% 107i+1436d 630maxrss 0+2pf 4896+0csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 2420.5000 MB in 5.15 real seconds = 481679.37 KB/sec = 
3945.9174 Mbps

nuttcp-r: 242266 I/O calls, msec/call = 0.02, calls/sec = 47080.98
nuttcp-r: 0.0user 2.4sys 0:05real 49% 112i+1502d 618maxrss 0+15pf 
156333+0csw


About 1/4 improvement...

With LRO on both sender and receiver

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.049 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 2585.7500 MB in 5.02 real seconds = 527402.83 KB/sec = 
4320.4840 Mbps

nuttcp-t: host-retrans = 1
nuttcp-t: 41372 I/O calls, msec/call = 0.12, calls/sec = 8240.67
nuttcp-t: 0.0user 4.6sys 0:05real 93% 106i+1421d 630maxrss 0+2pf 4286+0csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 2585.7500 MB in 5.15 real seconds = 514585.31 KB/sec = 
4215.4829 Mbps

nuttcp-r: 282820 I/O calls, msec/call = 0.02, calls/sec = 54964.34
nuttcp-r: 0.0user 2.7sys 0:05real 55% 114i+1540d 618maxrss 0+15pf 
188794+147csw


Even better...

With LRO on sender only:

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.054 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 2077.5437 MB in 5.02 real seconds = 423740.81 KB/sec = 
3471.2847 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 33241 I/O calls, msec/call = 0.15, calls/sec = 6621.01
nuttcp-t: 0.0user 4.5sys 0:05real 92% 109i+1468d 630maxrss 0+2pf 49532+25csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 2077.5437 MB in 5.15 real seconds = 413415.33 KB/sec = 
3386.6984 Mbps

nuttcp-r: 531979 I/O calls, msec/call = 0.01, calls/sec = 103378.67
nuttcp-r: 0.0user 4.5sys 0:05real 88% 110i+1474d 618maxrss 0+15pf 
117367+0csw




also remember that hw.ixgbe.max_interrupt_rate has only
effect at module load -- i.e. you set it with the bootloader,
or with kenv before loading the module.


I have this in /boot/loader.conf

kern.ipc.nmbclusters=512000
hw.ixgbe.max_interrupt_rate=0

on both sender and receiver.


Please retry the measurements disabling tso (on both sides, but
it really matters only on the sender). Also, LRO requires HWCSUM.


How do I set HWCSUM? Is this different 

Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

On Dec 7, 2011, at 8:08 PM, Luigi Rizzo wrote:

 Summary:
 
 - with default interrupt mitigation, the fastest configuration
  is with checksums enabled on both sender and receiver, lro
  enabled on the receiver. This gets about 8.0 Gbit/s

I do not observe this. With defaults:

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.053 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1857.4978 MB in 5.02 real seconds = 378856.02 KB/sec = 3103.5885 Mbps
nuttcp-t: host-retrans = 0
nuttcp-t: 29720 I/O calls, msec/call = 0.17, calls/sec = 5919.63
nuttcp-t: 0.0user 2.5sys 0:05real 52% 115i+1544d 630maxrss 0+2pf 107264+1csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1857.4978 MB in 5.15 real seconds = 369617.39 KB/sec = 3027.9057 Mbps
nuttcp-r: 543991 I/O calls, msec/call = 0.01, calls/sec = 105709.95
nuttcp-r: 0.1user 4.1sys 0:05real 83% 110i+1482d 618maxrss 0+15pf 158432+0csw

On receiver:

ifconfig ix1 lro

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.068 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1673.3125 MB in 5.02 real seconds = 341312.36 KB/sec = 2796.0308 Mbps
nuttcp-t: host-retrans = 1
nuttcp-t: 26773 I/O calls, msec/call = 0.19, calls/sec = 5333.01
nuttcp-t: 0.0user 1.0sys 0:05real 21% 113i+1518d 630maxrss 0+2pf 12772+1csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1673.3125 MB in 5.15 real seconds = 332975.19 KB/sec = 2727.7327 Mbps
nuttcp-r: 106268 I/O calls, msec/call = 0.05, calls/sec = 20650.82
nuttcp-r: 0.0user 1.3sys 0:05real 28% 101i+1354d 618maxrss 0+15pf 64567+0csw

On sender:

ifconfig ix1 lro

(now both receiver and sender have LRO enabled)

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.063 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1611.7805 MB in 5.02 real seconds = 328716.18 KB/sec = 2692.8430 Mbps
nuttcp-t: host-retrans = 1
nuttcp-t: 25789 I/O calls, msec/call = 0.20, calls/sec = 5136.29
nuttcp-t: 0.0user 1.0sys 0:05real 21% 109i+1465d 630maxrss 0+2pf 12697+0csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1611.7805 MB in 5.15 real seconds = 320694.82 KB/sec = 2627.1319 Mbps
nuttcp-r: 104346 I/O calls, msec/call = 0.05, calls/sec = 20275.05
nuttcp-r: 0.0user 1.3sys 0:05real 27% 113i+1516d 618maxrss 0+15pf 63510+0csw

remove LRO from receiver (only sender has LRO):

# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.065 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1884.8702 MB in 5.02 real seconds = 384464.57 KB/sec = 3149.5338 Mbps
nuttcp-t: host-retrans = 0
nuttcp-t: 30158 I/O calls, msec/call = 0.17, calls/sec = 6007.27
nuttcp-t: 0.0user 2.7sys 0:05real 55% 104i+1403d 630maxrss 0+2pf 106046+0csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1884.8702 MB in 5.15 real seconds = 375093.52 KB/sec = 3072.7661 Mbps
nuttcp-r: 540237 I/O calls, msec/call = 0.01, calls/sec = 104988.68
nuttcp-r: 0.1user 4.2sys 0:05real 84% 110i+1483d 618maxrss 0+15pf 156340+0csw

Strange enough, setting hw.ixgbe.max_interrupt_rate=0 does not have any effect..

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

Here is what I get, with an existing install, no tuning other than 
kern.ipc.nmbclusters=512000


Pair of Supermicro blades:

FreeBSD 8.2-STABLE #0: Wed Sep 28 11:23:59 EEST 2011
CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2403.58-MHz 
K8-class CPU)

real memory  = 51539607552 (49152 MB)
[...]
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.10 
port 0xdc00-0xdc1f mem 0xfbc0-0xfbdf,0xfbbfc000-0xfbbf irq 
16 at device 0.0 on pci3

ix0: Using MSIX interrupts with 9 vectors
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: Ethernet address: xx:xx:xx:xx:xx:xx
ix0: PCI Express Bus: Speed 5.0Gb/s Width x8
ix1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.10 
port 0xd880-0xd89f mem 0xfb80-0xfb9f,0xfbbf8000-0xfbbfbfff irq 
17 at device 0.1 on pci3

ix1: Using MSIX interrupts with 9 vectors
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: Ethernet address: xx:xx:xx:xx:xx:xx
ix1: PCI Express Bus: Speed 5.0Gb/s Width x8


blade 1:

# nuttcp -S
# nuttcp -t -T 5 -w 128 -v localhost
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.044 ms
nuttcp-t: send window size = 143360, receive window size = 71680
nuttcp-t: 8959.8750 MB in 5.02 real seconds = 1827635.67 KB/sec = 
14971.9914 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 143358 I/O calls, msec/call = 0.04, calls/sec = 28556.81
nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 602maxrss 0+5pf 16+46csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 127.0.0.1
nuttcp-r: send window size = 43008, receive window size = 143360
nuttcp-r: 8959.8750 MB in 5.17 real seconds = 1773171.07 KB/sec = 
14525.8174 Mbps

nuttcp-r: 219708 I/O calls, msec/call = 0.02, calls/sec = 42461.43
nuttcp-r: 0.0user 3.8sys 0:05real 76% 105i+1407d 614maxrss 1+17pf 
95059+22csw


blade 2:

# nuttcp -t -T 5 -w 128 -v 10.2.101.12
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.12
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.12 with mss=1448, RTT=0.059 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1340.6469 MB in 5.02 real seconds = 273449.90 KB/sec = 
2240.1016 Mbps

nuttcp-t: host-retrans = 171
nuttcp-t: 21451 I/O calls, msec/call = 0.24, calls/sec = 4272.78
nuttcp-t: 0.0user 1.9sys 0:05real 39% 120i+1610d 600maxrss 2+3pf 75658+0csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.11
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1340.6469 MB in 5.17 real seconds = 265292.92 KB/sec = 
2173.2796 Mbps

nuttcp-r: 408764 I/O calls, msec/call = 0.01, calls/sec = 78992.15
nuttcp-r: 0.0user 3.3sys 0:05real 64% 105i+1413d 620maxrss 0+15pf 
105104+102csw



Another pari of blades:

FreeBSD 8.2-STABLE #0: Tue Aug  9 12:37:55 EEST 2011
CPU: AMD Opteron(tm) Processor 6134 (2300.04-MHz K8-class CPU)
real memory  = 68719476736 (65536 MB)
[...]
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.10 
port 0xe400-0xe41f mem 0xfe60-0xfe7f,0xfe4fc000-0xfe4f irq 
19 at device 0.0 on pci3

ix0: Using MSIX interrupts with 9 vectors
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: Ethernet address: xx:xx:xx:xx:xx:xx
ix0: PCI Express Bus: Speed 5.0Gb/s Width x8
ix1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.10 
port 0xe800-0xe81f mem 0xfea0-0xfebf,0xfe8fc000-0xfe8f irq 
16 at device 0.1 on pci3

ix1: Using MSIX interrupts with 9 vectors
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: Ethernet address: xx:xx:xx:xx:xx:xx
ix1: PCI Express Bus: Speed 5.0Gb/s Width x8

first blade:

# nuttcp -S
# nuttcp -t -T 5 -w 128 -v localhost
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.090 ms
nuttcp-t: send window size = 143360, receive window size = 71680
nuttcp-t: 2695.0625 MB in 5.00 real seconds = 551756.90 KB/sec = 
4519.9925 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 43121 I/O calls, msec/call = 0.12, calls/sec = 8621.20
nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+4pf 2+71csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 127.0.0.1
nuttcp-r: send window size = 43008, receive window size = 143360
nuttcp-r: 2695.0625 MB in 5.14 real seconds = 536509.66 KB/sec = 
4395.0871 Mbps

nuttcp-r: 43126 I/O calls, msec/call = 0.12, 

Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

On 06.12.11 13:18, Daniel Kalchev wrote:

[...]
second blade:

# nuttcp -t -T 5 -w 128 -v 10.2.101.13
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.13
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.164 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1290.3750 MB in 5.00 real seconds = 264173.96 KB/sec = 
2164.1131 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 20646 I/O calls, msec/call = 0.25, calls/sec = 4127.72
nuttcp-t: 0.0user 3.8sys 0:05real 77% 96i+1299d 616maxrss 0+3pf 
27389+0csw


nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.14
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1290.3750 MB in 5.14 real seconds = 256835.92 KB/sec = 
2103.9998 Mbps

nuttcp-r: 85668 I/O calls, msec/call = 0.06, calls/sec = 16651.70
nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1437d 624maxrss 0+15pf 
11848+0csw



Not impresive... I am rebuilding now to -stable.

Daniel


I also noticed interrupt storms happening while this was running on the 
second pair of blades:


interrupt storm detected on irq272:; throttling interrupt source
interrupt storm detected on irq272:; throttling interrupt source
interrupt storm detected on irq272:; throttling interrupt source
interrupt storm detected on irq270:; throttling interrupt source
interrupt storm detected on irq270:; throttling interrupt source
interrupt storm detected on irq270:; throttling interrupt source

some stats

# sysctl -a dev.ix.1
dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 
2.3.10

dev.ix.1.%driver: ix
dev.ix.1.%location: slot=0 function=1
dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fc subvendor=0x 
subdevice=0x class=0x02

dev.ix.1.%parent: pci3
dev.ix.1.flow_control: 3
dev.ix.1.advertise_gig: 0
dev.ix.1.enable_aim: 1
dev.ix.1.rx_processing_limit: 128
dev.ix.1.dropped: 0
dev.ix.1.mbuf_defrag_failed: 0
dev.ix.1.no_tx_dma_setup: 0
dev.ix.1.watchdog_events: 0
dev.ix.1.tso_tx: 1193460
dev.ix.1.link_irq: 1
dev.ix.1.queue0.interrupt_rate: 100
dev.ix.1.queue0.txd_head: 45
dev.ix.1.queue0.txd_tail: 45
dev.ix.1.queue0.no_desc_avail: 0
dev.ix.1.queue0.tx_packets: 23
dev.ix.1.queue0.rxd_head: 16
dev.ix.1.queue0.rxd_tail: 15
dev.ix.1.queue0.rx_packets: 16
dev.ix.1.queue0.rx_bytes: 2029
dev.ix.1.queue0.lro_queued: 0
dev.ix.1.queue0.lro_flushed: 0
dev.ix.1.queue1.interrupt_rate: 62500
dev.ix.1.queue1.txd_head: 0
dev.ix.1.queue1.txd_tail: 0
dev.ix.1.queue1.no_desc_avail: 0
dev.ix.1.queue1.tx_packets: 0
dev.ix.1.queue1.rxd_head: 0
dev.ix.1.queue1.rxd_tail: 2047
dev.ix.1.queue1.rx_packets: 0
dev.ix.1.queue1.rx_bytes: 0
dev.ix.1.queue1.lro_queued: 0
dev.ix.1.queue1.lro_flushed: 0
dev.ix.1.queue2.interrupt_rate: 20
dev.ix.1.queue2.txd_head: 545
dev.ix.1.queue2.txd_tail: 545
dev.ix.1.queue2.no_desc_avail: 0
dev.ix.1.queue2.tx_packets: 331690
dev.ix.1.queue2.rxd_head: 1099
dev.ix.1.queue2.rxd_tail: 1098
dev.ix.1.queue2.rx_packets: 498763
dev.ix.1.queue2.rx_bytes: 32954702
dev.ix.1.queue2.lro_queued: 0
dev.ix.1.queue2.lro_flushed: 0
dev.ix.1.queue3.interrupt_rate: 62500
dev.ix.1.queue3.txd_head: 0
dev.ix.1.queue3.txd_tail: 0
dev.ix.1.queue3.no_desc_avail: 0
dev.ix.1.queue3.tx_packets: 0
dev.ix.1.queue3.rxd_head: 0
dev.ix.1.queue3.rxd_tail: 2047
dev.ix.1.queue3.rx_packets: 0
dev.ix.1.queue3.rx_bytes: 0
dev.ix.1.queue3.lro_queued: 0
dev.ix.1.queue3.lro_flushed: 0
dev.ix.1.queue4.interrupt_rate: 100
dev.ix.1.queue4.txd_head: 13
dev.ix.1.queue4.txd_tail: 13
dev.ix.1.queue4.no_desc_avail: 0
dev.ix.1.queue4.tx_packets: 6
dev.ix.1.queue4.rxd_head: 6
dev.ix.1.queue4.rxd_tail: 5
dev.ix.1.queue4.rx_packets: 6
dev.ix.1.queue4.rx_bytes: 899
dev.ix.1.queue4.lro_queued: 0
dev.ix.1.queue4.lro_flushed: 0
dev.ix.1.queue5.interrupt_rate: 20
dev.ix.1.queue5.txd_head: 982
dev.ix.1.queue5.txd_tail: 982
dev.ix.1.queue5.no_desc_avail: 0
dev.ix.1.queue5.tx_packets: 302592
dev.ix.1.queue5.rxd_head: 956
dev.ix.1.queue5.rxd_tail: 955
dev.ix.1.queue5.rx_packets: 474044
dev.ix.1.queue5.rx_bytes: 31319840
dev.ix.1.queue5.lro_queued: 0
dev.ix.1.queue5.lro_flushed: 0
dev.ix.1.queue6.interrupt_rate: 20
dev.ix.1.queue6.txd_head: 1902
dev.ix.1.queue6.txd_tail: 1902
dev.ix.1.queue6.no_desc_avail: 0
dev.ix.1.queue6.tx_packets: 184922
dev.ix.1.queue6.rxd_head: 1410
dev.ix.1.queue6.rxd_tail: 1409
dev.ix.1.queue6.rx_packets: 402818
dev.ix.1.queue6.rx_bytes: 27759640
dev.ix.1.queue6.lro_queued: 0
dev.ix.1.queue6.lro_flushed: 0
dev.ix.1.queue7.interrupt_rate: 20
dev.ix.1.queue7.txd_head: 660
dev.ix.1.queue7.txd_tail: 660
dev.ix.1.queue7.no_desc_avail: 0
dev.ix.1.queue7.tx_packets: 378078
dev.ix.1.queue7.rxd_head: 885
dev.ix.1.queue7.rxd_tail: 884
dev.ix.1.queue7.rx_packets: 705397
dev.ix.1.queue7.rx_bytes: 46572290
dev.ix.1.queue7.lro_queued: 0
dev.ix.1.queue7.lro_flushed: 0
dev.ix.1.mac_stats.crc_errs: 0
dev.ix.1.mac_stats.ill_errs: 0
dev.ix.1.mac_stats.byte_errs: 0

Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

Some tests with updated FreeBSD to 8-stable as of today, compared with 
the previous run



On 06.12.11 13:18, Daniel Kalchev wrote:


FreeBSD 8.2-STABLE #0: Wed Sep 28 11:23:59 EEST 2011
CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2403.58-MHz 
K8-class CPU)

real memory  = 51539607552 (49152 MB)
blade 1:

# nuttcp -S
# nuttcp -t -T 5 -w 128 -v localhost
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.044 ms
nuttcp-t: send window size = 143360, receive window size = 71680
nuttcp-t: 8959.8750 MB in 5.02 real seconds = 1827635.67 KB/sec = 
14971.9914 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 143358 I/O calls, msec/call = 0.04, calls/sec = 28556.81
nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 602maxrss 0+5pf 16+46csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 127.0.0.1
nuttcp-r: send window size = 43008, receive window size = 143360
nuttcp-r: 8959.8750 MB in 5.17 real seconds = 1773171.07 KB/sec = 
14525.8174 Mbps

nuttcp-r: 219708 I/O calls, msec/call = 0.02, calls/sec = 42461.43
nuttcp-r: 0.0user 3.8sys 0:05real 76% 105i+1407d 614maxrss 1+17pf 
95059+22csw


New results:

FreeBSD 8.2-STABLE #1: Tue Dec  6 13:51:01 EET 2011


# nuttcp -t -T 5 -w 128 -v localhost
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.030 ms
nuttcp-t: send window size = 143360, receive window size = 71680
nuttcp-t: 12748.0625 MB in 5.02 real seconds = 2599947.38 KB/sec = 
21298.7689 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 203969 I/O calls, msec/call = 0.03, calls/sec = 40624.18
nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+2pf 1+82csw

nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 127.0.0.1
nuttcp-r: send window size = 43008, receive window size = 143360
nuttcp-r: 12748.0625 MB in 5.15 real seconds = 2536511.81 KB/sec = 
20779.1048 Mbps

nuttcp-r: 297000 I/O calls, msec/call = 0.02, calls/sec = 57709.75
nuttcp-r: 0.1user 4.0sys 0:05real 81% 109i+1469d 626maxrss 0+15pf 
121136+34csw


Noticeable improvement.




blade 2:

# nuttcp -t -T 5 -w 128 -v 10.2.101.12
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.12
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.12 with mss=1448, RTT=0.059 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1340.6469 MB in 5.02 real seconds = 273449.90 KB/sec = 
2240.1016 Mbps

nuttcp-t: host-retrans = 171
nuttcp-t: 21451 I/O calls, msec/call = 0.24, calls/sec = 4272.78
nuttcp-t: 0.0user 1.9sys 0:05real 39% 120i+1610d 600maxrss 2+3pf 
75658+0csw


nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.11
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1340.6469 MB in 5.17 real seconds = 265292.92 KB/sec = 
2173.2796 Mbps

nuttcp-r: 408764 I/O calls, msec/call = 0.01, calls/sec = 78992.15
nuttcp-r: 0.0user 3.3sys 0:05real 64% 105i+1413d 620maxrss 0+15pf 
105104+102csw


# nuttcp -t -T 5 -w 128 -v 10.2.101.11
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.2.101.11
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.055 ms
nuttcp-t: send window size = 131768, receive window size = 66608
nuttcp-t: 1964.8640 MB in 5.02 real seconds = 400757.59 KB/sec = 
3283.0062 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 31438 I/O calls, msec/call = 0.16, calls/sec = 6261.87
nuttcp-t: 0.0user 2.7sys 0:05real 55% 112i+1501d 1124maxrss 1+2pf 
65+112csw


nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=65536, nstream=1, port=5001 tcp
nuttcp-r: accept from 10.2.101.12
nuttcp-r: send window size = 33304, receive window size = 131768
nuttcp-r: 1964.8640 MB in 5.15 real seconds = 390972.20 KB/sec = 
3202.8442 Mbps

nuttcp-r: 560718 I/O calls, msec/call = 0.01, calls/sec = 108957.70
nuttcp-r: 0.1user 4.2sys 0:05real 84% 111i+1494d 626maxrss 0+15pf 
151930+16csw


Again, improvement.





Another pari of blades:

FreeBSD 8.2-STABLE #0: Tue Aug  9 12:37:55 EEST 2011
CPU: AMD Opteron(tm) Processor 6134 (2300.04-MHz K8-class CPU)
real memory  = 68719476736 (65536 MB)

first blade:

# nuttcp -S
# nuttcp -t -T 5 -w 128 -v localhost
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost
nuttcp-t: time limit = 5.00 seconds
nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.090 ms
nuttcp-t: send window size = 143360, receive window size = 71680
nuttcp-t: 2695.0625 MB in 5.00 real seconds = 551756.90 KB/sec = 
4519.9925 Mbps

nuttcp-t: host-retrans = 0
nuttcp-t: 43121 I/O calls, msec/call = 0.12, calls/sec = 8621.20
nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+4pf 2+71csw

nuttcp-r: v6.1.2

Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

I see significant difference between number of interrupts on the Intel and the 
AMD blades. When performing a test between the Intel and AMD blades, the Intel 
blade generates 20,000-35,000 interrupts, while the AMD blade generates under 
1,000 interrupts.

There is no longer throttling, but the performance does not improve.. 

I set it via 

sysctl hw.intr_storm_threshold=0

Should this go to /boot/loader.conf instead.

Daniel

On Dec 6, 2011, at 7:21 PM, Jack Vogel wrote:

 Set the storm threshold to 0, that will disable it, its going to throttle 
 your performance
 when it happens.
 
 Jack
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: datapoints on 10G throughput with TCP ?

[Daniel Kalchev]

On Dec 5, 2011, at 9:27 PM, Luigi Rizzo wrote:

 - have two machines connected by a 10G link
 - on one run nuttcp -S
 - on the other one run nuttcp -t -T 5 -w 128 -v the.other.ip
 

Any particular tuning of FreeBSD?

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gptzfsboot error using HP Smart Array P410i Controller

[Daniel Kalchev]

On 13.10.11 00:33, Christoph Hoffmann wrote:

I am inclined to think that this is related to the way how we compile this code,
especially when run on the following particular processor:

1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled
Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz
QPI Speed: 5.8 GT/s.


For me, this happens on

CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2400.10-MHz 
K8-class CPU)


On HP DL360 G7

I try to boot -stable.

Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gptzfsboot error using HP Smart Array P410i Controller

[Daniel Kalchev]

Has this issue been resolved somehow? Sane method to build gptzfsboot 
that will run on HP's P410i?


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: RFC: Project geom-events

[Daniel Kalchev]

On Oct 8, 2011, at 12:05 , Lev Serebryakov wrote:

 Hello, Ivan.
 You wrote 8 октября 2011 г., 0:23:14:
 
 If you think this should be explicitely handled, please file a PR
 which requests the modification of gpart so that it detects that a GPT
 is being created in anything other than a raw drive, and warns the
 user.
  It should be mentioned in documentation, at least.
  But how people will create bootable gmirror installation in such
 case? Make (many) mirrors from parts? I don't like this idea...

Good example of what I would call laziness -- other would call it hacking I 
guess. Either way, the solution we have now is permitting some exotic setups, 
but is fragile and is not consistent. Most of the useful features are actually 
side effects of the hack.

If it should remain this way, a warning in the documentation and at runtime is 
very helpful.

Daniel___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: RFC: Project geom-events

[Daniel Kalchev]

On 07.10.11 22:44, Lev Serebryakov wrote:

Hello, Perryh.
You wrote 7 октября 2011 г., 18:06:38:


   GPT (and MBR) metadata placement is dictated from outside world,
where is no GEOM and geom_label. They INTENDED to be used on DISKS.
BIOSes should be able to find it :)

Certainly GPT and MBR must place an instance of the partition table
where the BIOS expects it, but there's no immediately obvious reason
why they must regard that instance as their GEOM metadata.  GPT puts
a second copy in the provider's last block, and AFAICT it could just
as well use _that_ instance -- or even a differently-formatted block
that included the same data -- as the primary.  MBR could do likewise.

   I have deja-vu, that I answered this. Please, read standard. GPT
  _must_ be placed twice -- at first and last sectors (really, more
  than one sectors). By standard. Secondary copy must be at end of
  disk. Period.



Then, by standard GPT cannot coexist with GLABEL. Such setup should be 
disallowed, or at least big nasty message that you have just shoot 
yourself in the leg should be output. (period)


Daniel

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: RFC: Project geom-events

[Daniel Kalchev]

On 06.10.11 14:07, Ivan Voras wrote:


Um, you do realize this is a physical problem with metadata location
and cannot be solved in any meaningful way? Geom_label stores its label
in the last sector of the device, and GPT stores the secondary /
backup table also at the end of the device. The two can NEVER work
together. The same goes for any other GEOM class which stores metadata
and GPT.


The proper way for this is to have these things store their metadata in 
the first/last sector of the provider, not the underlying device.


This means that, if you have GPT within GLABEL, for example -- you will 
only see the GPT label if you first see the GLABEL.


I guess the present situation was created out of laziness ;)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: RFC: Project geom-events

[Daniel Kalchev]

On 06.10.11 15:36, Ivan Voras wrote:

On 06/10/2011 13:29, Daniel Kalchev wrote:


On 06.10.11 14:07, Ivan Voras wrote:

Um, you do realize this is a physical problem with metadata location
and cannot be solved in any meaningful way? Geom_label stores its label
in the last sector of the device, and GPT stores the secondary /
backup table also at the end of the device. The two can NEVER work
together. The same goes for any other GEOM class which stores metadata
and GPT.

The proper way for this is to have these things store their metadata in
the first/last sector of the provider, not the underlying device.

This means that, if you have GPT within GLABEL, for example -- you will
only see the GPT label if you first see the GLABEL.

I guess the present situation was created out of laziness ;)

No, I don't think you understand.

The layering *is* correct and you *can* create a GPT inside a glabel
label, but then

1) you get device names like /dev/label/somethingp1,
/dev/label/somethingp2, etc.


.. and, you overwrite the last sector of the device, not of the 
provider. This is incorrect layering -- GPT should see only the provider 
it was given and nothing at different layers.




2) this makes the device unbootable as the GPT partition is per
definition not valid. It still stores the primary partition table on the
first sector (and the following sectors...), but its secondary table is
stored at one sector short of device's last sector (which is used by
glabel). Any utilities and BIOSes which test for GPT will find the first
table but not the last and depending on how sensitive / broken they are,
they will either recognize a broken GPT (and/or try to fix it,
destroying the glabel label), or not work at all.


This is why I said, lazy. If you use proper layering, the GPT within 
another GEOM provider should be unbootable. No BIOS should ever see 
it. The rationale of using GPT within another GEOM is questionable, but 
apparently has applications.



You could argue that the GPT design is broken, but it was always, per
design, only made to work on whole drives. There is no way to use it
with any other scheme which uses either the first or the last sectors of
a drive.


I am not arguing this.

But suppose you use GPT on HAST providers. These cannot boot so whether 
GPT is bootable in that case is irelevant.



Luckily, GPT also provides its own labels (per design) and instead of
labeling the provider, you could just as easily label the individual
partitions and skip glabel in this case.



That is another option, yes. But this does not mean we do not have a issue.

Probably, it should be simply disallowed to use GPT within GLABEL. Or, 
in cases where this might be beneficial, use sort of 'boot-less' GPT.


Probably, the problem here is with GLABEL, that does not use the first 
sector as well.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: RFC: Project geom-events

[Daniel Kalchev]

On 06.10.11 17:04, Pieter de Goeje wrote:

The layering *is* correct and you *can* create a GPT inside a glabel
label, but then

1) you get device names like /dev/label/somethingp1,
/dev/label/somethingp2, etc.

.. and, you overwrite the last sector of the device, not of the
provider. This is incorrect layering -- GPT should see only the provider
it was given and nothing at different layers.

If you stack GPT on top of glabel, then your statement is not true. GPT will
overwrite the last sector of the (glabel) provider, not the underlying device.
There is no layering violation.


I stand corrected. Sorry for creating confusion with this statement.

Most of the time I was blaming GPT, I was actually blaming GLABEL (see 
below)



Because physically the first sector of the device is still GPT data the BIOS
will still try to boot from it, hence it would probably be wise to disallow
GPT on anything other then raw devices.
Yes, but.. what is a raw device? Probably disallow GPT on devices that 
are not bootable, but how this can be indicated? GPT is very useful for 
it's ability to create labeled partitions.



This problem wouldn't exist if geom classes would write their metadata to the
first sector, but then you could no longer boot from for example
gmirrored/glabeled devices with a MBR.


We seem to blame GPT here, but it is really GLABEL the culprit here.

If GLABEL writes to the first sector of the provider and that makes the 
disk non-bootable, then there is little chance that somebody will try to 
use first GLABEL, then GPT etc and create the current situation.


Unfortunately, the GLABEL + GMIRROR setup is so common..
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Weird issue with hastd(8)

[Daniel Kalchev]

On 03.06.11 11:26, Maxim Sobolev wrote:

On 5/29/2011 4:11 AM, Mikolaj Golub wrote:

This might be MSG_WAITALL issue I described on net@ (look for the thread
recv() with MSG_WAITALL might stuck when receiving more than 
rcvbuf, and

also kern/154504).

Could you please try the patch?

http://people.freebsd.org/~trociny/uipc_socket.c.patch


Yes, installing this patch on both client and server has solved this 
issue. Synchronization now goes much faster.


This patch also apparently resolved the issue I had with HAST over 
10Gbit Ethernet. It should probably be committed.


Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS install from -CURRENT snapshot

[Daniel Kalchev]

On 29.05.11 16:10, Daniel Staal wrote:
--As of May 29, 2011 12:06:30 PM +0300, George Kontostanos is alleged 
to have said:

http://www.aisecure.net/?p=132;


Thanks, that's about what I expected the install procedure to be at 
this point.  Nice to have the reminder about the zpool.cache.   (Do I 
have to use the Live CD mode?  Can I use shell mode instead?)


Actually, you don't need to go via the trouble to make /boot writable. 
You can obtain zpool.cache by using


zpool import -c /tmp/zpool.cache zroot

Then copy that file to the mounted root filesystem of the zpool.

Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org