Re: OpenSSH HPN
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: "libssl.so.8" not found
> 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: CVE-2015-7547: critical bug in libc
> 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: Dropping some locales/encodings?
> 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: [CFT] packaging the base system with pkg(8)
> 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: GOST in OPENSSL_BASE
> 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: GOST in OPENSSL_BASE
> On 12.07.2016 г., at 13:26, Franco Fichtner wrote: > > >> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev 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: IPFW on CURRENT: NAT forwarding exposes internal IP!
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: ISO image: where is the CLANG compiler?
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: Opteron 6100-series "Magny-Cours"
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: RFC: Project geom-events
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
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
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: RFC: Project geom-events
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
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: gptzfsboot error using HP Smart Array P410i Controller
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: gptzfsboot error using HP Smart Array P410i Controller
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: datapoints on 10G throughput with TCP ?
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: datapoints on 10G throughput with TCP ?
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: 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: 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: 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: 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, calls/sec = 8383.94 nuttcp-r: 0.0user 3.1sys 0:05real 61% 94i+1264d 624maxrss 1+16pf 43019+0csw 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
Re: datapoints on 10G throughput with TCP ?
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.
Re: datapoints on 10G throughput with TCP ?
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+
Re: datapoints on 10G throughput with TCP ?
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: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?
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: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ?
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=8843 metric 0 mtu 1500 options=4bb ether 00:25:90:35:22:f1 inet 10.2.101.11 netmask 0xff00 broadcast 10.2.101.255 media: Ethernet autoselect (autoselect ) 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 from RXCSUM/TXCSUM? Still I get nowhere near what you get on my hardware... Here is what pciconf -vlbc has to
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
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
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
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
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
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
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
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
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
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
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 AT&T 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" (AT&T) 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
On 22.12.11 11:56, Igor Mozolevsky wrote: On 22 December 2011 05:54, Daniel Kalchev 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
On 22.12.11 12:50, Igor Mozolevsky wrote: On 22 December 2011 10:12, Daniel Kalchev 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
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
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
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
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 AT&T 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: 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
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: ZFS/RAIDZ and SAMBA: abyssimal performance
On Jan 4, 2013, at 4:06 PM, Fleuriot Damien 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: FreeBSD Testing Facility
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: Response of *.freebsd.org websites are very slow
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
On 27.02.13 15:13, Fbsd8 wrote: Mark Felder wrote: On Wed, 27 Feb 2013 06:52:29 -0600, 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: Why Are You NOT Using FreeBSD?
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: Why Are You NOT Using FreeBSD?
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?
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?
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= 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?
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?
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?
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: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
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. 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: What happened to nslookup?
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: Import of DragonFly Mail Agent
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: Import of DragonFly Mail Agent
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: Leaving the Desktop Market
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: Leaving the Desktop Market
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
On 02.04.14 15:52, David Chisnall wrote: On 2 Apr 2014, at 13:40, Daniel Kalchev 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
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: ipfilter(4) needs maintainer
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: Light humour
On Apr 29, 2013, at 2:37 AM, Diane Bruce 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
On 29.04.13 12:40, Julian H. Stacey wrote: Daniel Kalchev wrote: On Apr 29, 2013, at 2:37 AM, Diane Bruce 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: svn error during 'make buildkernel'?
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: GCC withdraw
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: ZFS install from -CURRENT snapshot
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"
Re: Weird issue with hastd(8)
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: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error
> 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: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error
> 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: /usr/src and /usr/ports not git directories ?
> На 23.01.2025 г., в 5:38, Florian Walpen написа: > > The remedy is clearly to build kernel module packages for every minor release, > and there has been an attempt to do this recently, through a separate pkg repo > I think. Either that, or do the kernel module compilation locally. For this you need the matching kernel source, which is there for binary updated systems (via freebsd-update). You only need the matching ports three or to ship the ports sources as part of the package itself, which might get ugly if there are lots of dependencies. But in any case, a source tree matching the kernel is required. > My take is that > installing the src tree is optional, giving a hint in the installer should be > enough. There will be secondary steps anyway in this scenario, like installing > the git executable and updating the src tree. As stated, we could simplify the > post-install repo cloning through a Makefile. I would say FreeBSD should always ship with its source code - this has been a major feature. It can be life saver if you get offline as all the necessary tools to rebuild are already there. We should not “over-git” stuff, especially as the git tool is not part of the build! Whether the shipped tree should be git ready… I can’t make my mind yet. Maybe it will be useful. For example, when things get messed up with binary updates, I usually pull a “fresh” releng arc tree, recompile and reinstall and I am in a good “binary” state to continue using the binary updates on that host. If the src tree already has git attributes, it would be just a matter of selecting the branch. Less time waiting and less load on servers. > > What is more questionable in my POV is to provide a by then outdated ports > tree. It needs network access anyway, and is an invitation to security issues. > Better simplify repo cloning through a Makefile, post-install, no dependency > on > git in the installer. Or am I missing some critical use case? I agree the ports tree is not extremely useful as shipped, except… you get an outdated system lying around that for some reason you can’t update and you need to install specific software in it.. for example, git - so that … you can update. Happened to me few times. Precompiled packages are not available anymore for those… new ports tree won’t work for multitude of reasons. There should be a snapshot of the ports tree for the release so you know anything you build from there will be compilable/compatible with that base. It may have other issues, but that’s different topic. We used to have the very useful portsnap tool, which did just that. A very simplified interface to updating the ports tree. Instead of junking it, it should have been updated to manage git base clones. Anyway, in today’s git clone of the ports “make update” works as expected. Daniel
