From owner-freebsd-performance@FreeBSD.ORG Sun Dec 21 00:51:46 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF981065670 for ; Sun, 21 Dec 2008 00:51:46 +0000 (UTC) (envelope-from michelle_li_001@yahoo.com) Received: from web65412.mail.ac4.yahoo.com (web65412.mail.ac4.yahoo.com [76.13.9.32]) by mx1.freebsd.org (Postfix) with SMTP id 105B78FC08 for ; Sun, 21 Dec 2008 00:51:45 +0000 (UTC) (envelope-from michelle_li_001@yahoo.com) Received: (qmail 11644 invoked by uid 60001); 21 Dec 2008 00:25:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=FG8FoZFHeNF1NWVakgfozhtcsar7kxTYKukh/pWEkeP7dapLKhvrJSJdWCvQhkN8FqMxV0gdnsogSODIFILJl3dufBrvyHcvwoesejbGrAYPntmttaQ9j5j0ORktZhSrJuFgq51vWcpRtDN21l7kSKXTS1TrG3JYbwxfX7svFR8=; X-YMail-OSG: c_44L78VM1kMF2OSdZFRQHlNOhWp4_dKNlCmIGYUZdLUYdiD1l4HWYSbfxtLKYBM9dqkVOVjoWSKTsW3oSUTUjbqwN.e6QbPc8KO8AZom0g_y4Z_HwVoREGFMstzagQiviTnHwQUEpR3gnblH4ZipsKfCX9pznpEospGnxyBAJgrylG7RfCG4Ei3GOFdBchbtYHHlb0OzxxkkzzHO61cwrBYKXDSPT8bCQ-- Received: from [68.110.123.27] by web65412.mail.ac4.yahoo.com via HTTP; Sat, 20 Dec 2008 16:25:02 PST Date: Sat, 20 Dec 2008 16:25:02 -0800 (PST) From: Michelle Li To: freebsd-performance@freebsd.org In-Reply-To: <20081220120019.BC51510656F4@hub.freebsd.org> MIME-Version: 1.0 Message-ID: <722609.11236.qm@web65412.mail.ac4.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS, NFS and Network tuning (Paul Patterson) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 00:51:46 -0000 ...and the dmesg? please post freebsd-performance-request@freebsd.org wrote: Send freebsd-performance mailing list submissions to freebsd-performance@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-performance or, via email, send a message with subject or body 'help' to freebsd-performance-request@freebsd.org You can reach the person managing the list at freebsd-performance-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-performance digest..." Today's Topics: 1. Re: ZFS, NFS and Network tuning (Paul Patterson) 2. Re: ZFS, NFS and Network tuning (Paul Patterson) 3. Re: ZFS, NFS and Network tuning (Paul Patterson) 4. intel i7 and Hyperthreading (Mike Tancsa) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Dec 2008 06:47:59 -0800 (PST) From: Paul Patterson Subject: Re: ZFS, NFS and Network tuning To: Paul Patterson , freebsd-performance@freebsd.org Message-ID: <15723.22980.qm@web110511.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" ------------------------------ Message: 2 Date: Fri, 19 Dec 2008 10:03:14 -0800 (PST) From: Paul Patterson Subject: Re: ZFS, NFS and Network tuning To: Paul Patterson , freebsd-performance@freebsd.org Message-ID: <400826.77992.qm@web110510.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii Hello all, I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. P. ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 9:47:59 AM Subject: Re: ZFS, NFS and Network tuning Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" ------------------------------ Message: 3 Date: Fri, 19 Dec 2008 10:59:54 -0800 (PST) From: Paul Patterson Subject: Re: ZFS, NFS and Network tuning To: Paul Patterson , freebsd-performance@freebsd.org Message-ID: <309927.87042.qm@web110514.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii Hi, Well, I got some input on things: kern.ipc.somaxconn=32768 net.inet.tcp.mssdflt=1460 And for fstab rw,tcp,intr,noatime,nfsv3,-w=65536,-r=65536 I tried turning on polling with ifconfig bce0 polling, however, I didn't see it in ifconfig bce0 so I don't believe it to be active or the card doesn't support it. aI also removed async from the mounts. These had a detrimental affect on the FreeBSD server. I now get 64K per transfer (system -vm) but I'm still only getting about 4MB/sec on the disks and their utilization has dropped to about 5%. Throughput from both clients is ~8.5MB/sec. The tests were run separately. The NetAPP on each host was over 48.5 MB/sec. The FreeBSD host still has about 2 GB free. Paul ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 1:03:14 PM Subject: Re: ZFS, NFS and Network tuning Hello all, I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. P. ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 9:47:59 AM Subject: Re: ZFS, NFS and Network tuning Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" ------------------------------ Message: 4 Date: Fri, 19 Dec 2008 17:01:46 -0500 From: Mike Tancsa Subject: intel i7 and Hyperthreading To: freebsd-performance@freebsd.org Message-ID: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Content-Type: text/plain; charset="us-ascii"; format=flowed Just got our first board to play around with and unlike in the past, having hyperthreading enabled seems to help performance.... At least in buildworld tests. doing a make -j4 vs -j6 make -j8 vs -j10 gives -j buildworld time % improvement over -j4 4 13:57 6 12:11 13% 8 11:32 18% 10 11:43 17% dmesg below of the hardware... The CPU seems to run fairly cool, but the board has a lot of nasty hot heatsinks eg. running 8 burnP6 procs 0[ns3c]# sysctl -a | grep temperature dev.cpu.0.temperature: 67 dev.cpu.1.temperature: 67 dev.cpu.2.temperature: 65 dev.cpu.3.temperature: 65 dev.cpu.4.temperature: 66 dev.cpu.5.temperature: 66 dev.cpu.6.temperature: 64 dev.cpu.7.temperature: 64 0[ns3c]# vs idle dev.cpu.0.temperature: 46 dev.cpu.1.temperature: 46 dev.cpu.2.temperature: 42 dev.cpu.3.temperature: 42 dev.cpu.4.temperature: 44 dev.cpu.5.temperature: 44 dev.cpu.6.temperature: 40 dev.cpu.7.temperature: 40 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Fri Dec 19 19:48:15 EST 2008 mdtancsa@ns3c.recycle.net:/usr/obj/usr/src/sys/recycle Timecounter "i8254" frequency 1193182 Hz quality 0 === message truncated === From owner-freebsd-performance@FreeBSD.ORG Sun Dec 21 14:58:15 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23FE71065673 for ; Sun, 21 Dec 2008 14:58:15 +0000 (UTC) (envelope-from james.technew@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id E94938FC0C for ; Sun, 21 Dec 2008 14:58:14 +0000 (UTC) (envelope-from james.technew@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3029624rvf.43 for ; Sun, 21 Dec 2008 06:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=f0E1fdFmMCxAeqJ3tHVH+rndbBajATjzycmTi/RkWw4=; b=dM7rv2BgZz46dg+S1FVm7gHJ7B/PLhdE5Gz8Gvvc/DxNjWAPbSEjo/+zIbStkr5zSE iPjoWbmqp/P/D1rSCsFYLlTjHkBmA62mqy0Fhw7B4RgNDMKOuHfoHHHI6FKiMPtC/zZF SqtfmV5tpokxdTzT/Gn6EUygglHOhV11YiSSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FiJMEE42+A+ciGKECkIkCsLeDG/3+ndf/FT4JFOzPeAUFEpBlLxWUi/+o9uZA8esuK 0fuQPV6XJzdC5UiuvsxwtNA3sSjDa+nykTOliAcXjTPIAq9wTjcQnfpBuCZoJ6xaEjBV 2t/oH3kYuCKDWE8EfNaLqQbvoT4sMmGNPsQ2s= Received: by 10.114.53.18 with SMTP id b18mr3340589waa.6.1229869676944; Sun, 21 Dec 2008 06:27:56 -0800 (PST) Received: by 10.114.183.4 with HTTP; Sun, 21 Dec 2008 06:27:56 -0800 (PST) Message-ID: Date: Sun, 21 Dec 2008 22:27:56 +0800 From: "James Chang" To: freebsd-performance@freebsd.org In-Reply-To: <20081221120020.BB89F10657A2@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081221120020.BB89F10657A2@hub.freebsd.org> Subject: Re: freebsd-performance Digest, Vol 70, Issue 7 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 14:58:15 -0000 Hi, Did you have plan to try another NIC (i.e. INTEL em?) and turn on polling mode? I think you can the following thing 1.use asynchronous I/O on Your FreeBSD 7.1 box 2.enable options ZERO_COPY_SOCKETS Best Regards! James Chang 2008/12/21 : > Send freebsd-performance mailing list submissions to > freebsd-performance@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > or, via email, send a message with subject or body 'help' to > freebsd-performance-request@freebsd.org > > You can reach the person managing the list at > freebsd-performance-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-performance digest..." > > > Today's Topics: > > 1. Re: ZFS, NFS and Network tuning (Paul Patterson) (Michelle Li) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 20 Dec 2008 16:25:02 -0800 (PST) > From: Michelle Li > Subject: Re: ZFS, NFS and Network tuning (Paul Patterson) > To: freebsd-performance@freebsd.org > Message-ID: <722609.11236.qm@web65412.mail.ac4.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > ...and the dmesg? > > please post > > freebsd-performance-request@freebsd.org wrote: Send freebsd-performance mailing list submissions to > freebsd-performance@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > or, via email, send a message with subject or body 'help' to > freebsd-performance-request@freebsd.org > > You can reach the person managing the list at > freebsd-performance-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-performance digest..." > > > Today's Topics: > > 1. Re: ZFS, NFS and Network tuning (Paul Patterson) > 2. Re: ZFS, NFS and Network tuning (Paul Patterson) > 3. Re: ZFS, NFS and Network tuning (Paul Patterson) > 4. intel i7 and Hyperthreading (Mike Tancsa) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 19 Dec 2008 06:47:59 -0800 (PST) > From: Paul Patterson > > Subject: Re: ZFS, NFS and Network tuning > To: Paul Patterson > , > freebsd-performance@freebsd.org > Message-ID: <15723.22980.qm@web110511.mail.gq1.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > as promised, the parameter tuning I have on the box (does anyone see anything wrong?) > > /boot/loader.conf > > kern.hz="100" > vm.kmem_size_max="1536M" > vm.kmem_size="1536M" > vfs.zfs.prefetch_disble=1 > > /etc/sysctl.conf > > kern.ipc.maxsockbuf=16777216 > kern.ipc.nmbclusters=32768 > kern.ipc.somaxconn=8192 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > kern.mxvnodes=600000 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.recvbuf_auto=1 > net.inet.tcp.recvbuf_inc=16384 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=65536 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendbuf_auto=1 > net.inet.tcpsendbuf_inc=8192 > net.inet.tcp.sendspace=65536 > net.inet.udp.maxdgram=57344 > net.inet.udp.recvspace=65536 > net.local.stream.recvspace=65536 > net.inet.tcp.sendbuf_max=16777216 > > > > > > ________________________________ > From: Paul Patterson > > To: freebsd-performance@freebsd.org > Sent: Thursday, December 18, 2008 8:04:37 PM > Subject: ZFS, NFS and Network tuning > > Hi, > > I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) > > Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. > > I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. > > Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. > > The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. > > Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) > > Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) > > I'll post the NetAPP finding tomorrow as I forgot it for now. > > As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime > > I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. > > Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. > > That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) > > Thank you for reading, > > Paul > > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 19 Dec 2008 10:03:14 -0800 (PST) > From: Paul Patterson > > Subject: Re: ZFS, NFS and Network tuning > To: Paul Patterson > , > freebsd-performance@freebsd.org > Message-ID: <400826.77992.qm@web110510.mail.gq1.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > Hello all, > > I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: > > Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent > Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. > > I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) > > I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. > > P. > > > > > ________________________________ > From: Paul Patterson > > To: Paul Patterson > ; freebsd-performance@freebsd.org > Sent: Friday, December 19, 2008 9:47:59 AM > Subject: Re: ZFS, NFS and Network tuning > > > Hi, > > as promised, the parameter tuning I have on the box (does anyone see anything wrong?) > > /boot/loader.conf > > kern.hz="100" > vm.kmem_size_max="1536M" > vm.kmem_size="1536M" > vfs.zfs.prefetch_disble=1 > > /etc/sysctl.conf > > kern.ipc.maxsockbuf=16777216 > kern.ipc.nmbclusters=32768 > kern.ipc.somaxconn=8192 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > kern.mxvnodes=600000 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.recvbuf_auto=1 > net.inet.tcp.recvbuf_inc=16384 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=65536 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendbuf_auto=1 > net.inet.tcpsendbuf_inc=8192 > net.inet.tcp.sendspace=65536 > net.inet.udp.maxdgram=57344 > net.inet.udp.recvspace=65536 > net.local.stream.recvspace=65536 > net.inet.tcp.sendbuf_max=16777216 > > > > > > ________________________________ > From: Paul Patterson > > To: freebsd-performance@freebsd.org > Sent: Thursday, December 18, 2008 8:04:37 PM > Subject: ZFS, NFS and Network tuning > > Hi, > > I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) > > Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. > > I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. > > Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. > > The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. > > Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) > > Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) > > I'll post the NetAPP finding tomorrow as I forgot it for now. > > As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime > > I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. > > Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. > > That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) > > Thank you for reading, > > Paul > > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > > > > > > ------------------------------ > > Message: 3 > Date: Fri, 19 Dec 2008 10:59:54 -0800 (PST) > From: Paul Patterson > > Subject: Re: ZFS, NFS and Network tuning > To: Paul Patterson > , > freebsd-performance@freebsd.org > Message-ID: <309927.87042.qm@web110514.mail.gq1.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > Well, I got some input on things: > > kern.ipc.somaxconn=32768 > net.inet.tcp.mssdflt=1460 > > And for fstab > > rw,tcp,intr,noatime,nfsv3,-w=65536,-r=65536 > > I tried turning on polling with ifconfig bce0 polling, however, I didn't see it in ifconfig bce0 so I don't believe it to be active or the card doesn't support it. > > aI also removed async from the mounts. These had a detrimental affect on the FreeBSD server. I now get 64K per transfer (system -vm) but I'm still only getting about 4MB/sec on the disks and their utilization has dropped to about 5%. Throughput from both clients is ~8.5MB/sec. The tests were run separately. The NetAPP on each host was over 48.5 MB/sec. > > The FreeBSD host still has about 2 GB free. > > Paul > > > > > ________________________________ > From: Paul Patterson > > To: Paul Patterson > ; freebsd-performance@freebsd.org > Sent: Friday, December 19, 2008 1:03:14 PM > Subject: Re: ZFS, NFS and Network tuning > > Hello all, > > I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: > > Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent > Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. > > I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) > > I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. > > P. > > > > > ________________________________ > From: Paul Patterson > > To: Paul Patterson > ; freebsd-performance@freebsd.org > Sent: Friday, December 19, 2008 9:47:59 AM > Subject: Re: ZFS, NFS and Network tuning > > > Hi, > > as promised, the parameter tuning I have on the box (does anyone see anything wrong?) > > /boot/loader.conf > > kern.hz="100" > vm.kmem_size_max="1536M" > vm.kmem_size="1536M" > vfs.zfs.prefetch_disble=1 > > /etc/sysctl.conf > > kern.ipc.maxsockbuf=16777216 > kern.ipc.nmbclusters=32768 > kern.ipc.somaxconn=8192 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > kern.mxvnodes=600000 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.recvbuf_auto=1 > net.inet.tcp.recvbuf_inc=16384 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=65536 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendbuf_auto=1 > net.inet.tcpsendbuf_inc=8192 > net.inet.tcp.sendspace=65536 > net.inet.udp.maxdgram=57344 > net.inet.udp.recvspace=65536 > net.local.stream.recvspace=65536 > net.inet.tcp.sendbuf_max=16777216 > > > > > > ________________________________ > From: Paul Patterson > > To: freebsd-performance@freebsd.org > Sent: Thursday, December 18, 2008 8:04:37 PM > Subject: ZFS, NFS and Network tuning > > Hi, > > I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) > > Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. > > I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. > > Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. > > The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. > > Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) > > Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) > > I'll post the NetAPP finding tomorrow as I forgot it for now. > > As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime > > I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. > > Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. > > That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) > > Thank you for reading, > > Paul > > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 19 Dec 2008 17:01:46 -0500 > From: Mike Tancsa > Subject: intel i7 and Hyperthreading > To: freebsd-performance@freebsd.org > Message-ID: <200812192214.mBJMEj2Q009511@lava.sentex.ca> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Just got our first board to play around with and unlike in the past, > having hyperthreading enabled seems to help performance.... At least > in buildworld tests. > > doing a make -j4 vs -j6 make -j8 vs -j10 gives > > -j buildworld time % improvement over -j4 > 4 13:57 > 6 12:11 13% > 8 11:32 18% > 10 11:43 17% > > > dmesg below of the hardware... The CPU seems to run fairly cool, but > the board has a lot of nasty hot heatsinks > > eg. running 8 burnP6 procs > > 0[ns3c]# sysctl -a | grep temperature > dev.cpu.0.temperature: 67 > dev.cpu.1.temperature: 67 > dev.cpu.2.temperature: 65 > dev.cpu.3.temperature: 65 > dev.cpu.4.temperature: 66 > dev.cpu.5.temperature: 66 > dev.cpu.6.temperature: 64 > dev.cpu.7.temperature: 64 > 0[ns3c]# > > vs idle > > dev.cpu.0.temperature: 46 > dev.cpu.1.temperature: 46 > dev.cpu.2.temperature: 42 > dev.cpu.3.temperature: 42 > dev.cpu.4.temperature: 44 > dev.cpu.5.temperature: 44 > dev.cpu.6.temperature: 40 > dev.cpu.7.temperature: 40 > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #0: Fri Dec 19 19:48:15 EST 2008 > mdtancsa@ns3c.recycle.net:/usr/obj/usr/src/sys/recycle > Timecounter "i8254" frequency 1193182 Hz quality 0 > > === message truncated === > > > > > > > > > > > > > > > > > > > ------------------------------ > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > > End of freebsd-performance Digest, Vol 70, Issue 7 > ************************************************** > From owner-freebsd-performance@FreeBSD.ORG Sun Dec 21 16:17:09 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 545651065670 for ; Sun, 21 Dec 2008 16:17:09 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110511.mail.gq1.yahoo.com (web110511.mail.gq1.yahoo.com [67.195.8.116]) by mx1.freebsd.org (Postfix) with SMTP id 260818FC12 for ; Sun, 21 Dec 2008 16:17:09 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: (qmail 20372 invoked by uid 60001); 21 Dec 2008 16:17:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MICHvp9+WHFqKTnmtKobbLekQdn9CMcMiPKjGrKTVcUVdbsV5HxhhmMsqTi5hbZNVGuh8gYZPEd8OsVCLFdCfxQwZ5bZUbLnbCs+xtFppEAyH6dU1e14Nan3Kei+yuC22nDwy7OZf0iN/3stKN8179kqiIDbAvcE+BzqfqZSXVg=; X-YMail-OSG: FL6XWf0VM1l_tmTmCtAV6jsRevRhtvtZ.w5D1Kj5C62Pg3BTK9bUgQPwwlFlx_cDNzq.PZgVtgL2LPkK6dkr7Y6Q99lvHLfeLfXf1s_VfDfME1GWht93Ld3kfiiEX9vporqwa13DuGCdFt4flsivRCA4YaruZeHbdhPSyoIHUCBmss.kgenPtEnhkMLovKkO3Oft6FShQejvISdzObs- Received: from [71.10.225.232] by web110511.mail.gq1.yahoo.com via HTTP; Sun, 21 Dec 2008 08:17:08 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <553453.43874.qm@web110514.mail.gq1.yahoo.com> <15723.22980.qm@web110511.mail.gq1.yahoo.com> <400826.77992.qm@web110510.mail.gq1.yahoo.com> <309927.87042.qm@web110514.mail.gq1.yahoo.com> Date: Sun, 21 Dec 2008 08:17:08 -0800 (PST) From: Paul Patterson To: Paul Patterson , freebsd-performance@freebsd.org MIME-Version: 1.0 Message-ID: <732531.19977.qm@web110511.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ZFS, NFS and Network tuning X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 16:17:09 -0000 Hi, well, after tweaking several things and trying several suggestions, things remain the same. There is an interesting thing occurring is that the steady throughput that I'm experiencing is rock solid. There are no longer any serious deviations on throughput. It's constant at 6.5-9.0 MB/sec (this sucks). However, that's at the write and delete speed. There's very little difference. The NetAPP drops dramatically on a random delete. So, someone suggested going with an em (aka Intel card). I'd really like to try that but the machine is off in a data center but I might just take one of my re based cards if I can't get the corporation to buy one and ship it down there. (I'm just of the opinion that if I could go polling the bce might not show the occasional input error. netstat -w 5 -I bce0 ) The last thing that has been suggested is to go with the Intel card, use polling, and enable "options ZERO_COPY_SOCKETS" in the kernel. That's for Monday. (Thank you, James Chang) As for the reasons many people didn't see the suggestions, a lot of people went off the thread and mailed directly. Please don't. It makes it real hard for the thread have integrity. (Heck, many of you are interested in the results. :-) ) P. ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 1:59:54 PM Subject: Re: ZFS, NFS and Network tuning Hi, Well, I got some input on things: kern.ipc.somaxconn=32768 net.inet.tcp.mssdflt=1460 And for fstab rw,tcp,intr,noatime,nfsv3,-w=65536,-r=65536 I tried turning on polling with ifconfig bce0 polling, however, I didn't see it in ifconfig bce0 so I don't believe it to be active or the card doesn't support it. aI also removed async from the mounts. These had a detrimental affect on the FreeBSD server. I now get 64K per transfer (system -vm) but I'm still only getting about 4MB/sec on the disks and their utilization has dropped to about 5%. Throughput from both clients is ~8.5MB/sec. The tests were run separately. The NetAPP on each host was over 48.5 MB/sec. The FreeBSD host still has about 2 GB free. Paul ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 1:03:14 PM Subject: Re: ZFS, NFS and Network tuning Hello all, I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. P. ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 9:47:59 AM Subject: Re: ZFS, NFS and Network tuning Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-performance@FreeBSD.ORG Sun Dec 21 16:50:51 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 603321065673 for ; Sun, 21 Dec 2008 16:50:51 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110508.mail.gq1.yahoo.com (web110508.mail.gq1.yahoo.com [67.195.8.113]) by mx1.freebsd.org (Postfix) with SMTP id 336968FC13 for ; Sun, 21 Dec 2008 16:50:51 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: (qmail 82027 invoked by uid 60001); 21 Dec 2008 16:50:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=HNC4G0gfSxsji5vUhaLyizR0hrZ3I6FTOuuIVhfC5mNptQxgMWRWHI+uX4nwpJPSYwetF/TYsEuiGd7DPQYRnkdSGBhLuZ9fRRRCA2LREZJxTOCEOxBI1dXvDzhRApUZrETa24fh/qML4MMivqsfQc1DvMqTrMsxzhhTCw7UCC8=; X-YMail-OSG: sSzsbp0VM1kz2nIVdGMnSVfM3u7_bUSqW7aoEXpYIoiKYACm8P7.UhKSc_3_SGw_uF1rSyBwOWltNW6Z2OafsIiFwT23fmK35KmIkZCG5DLfl5ghlgoOBg14X3dlvmy5K62w2W6vpK0t5Y7pJ9KSVKp6xZBPSGubE3T4n9ixcWONSUygysKbT07NIDfDoQ-- Received: from [71.10.225.232] by web110508.mail.gq1.yahoo.com via HTTP; Sun, 21 Dec 2008 08:50:50 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <722609.11236.qm@web65412.mail.ac4.yahoo.com> Date: Sun, 21 Dec 2008 08:50:50 -0800 (PST) From: Paul Patterson To: Michelle Li , freebsd-performance@freebsd.org MIME-Version: 1.0 Message-ID: <726963.81983.qm@web110508.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ZFS, NFS and Network tuning (Paul Patterson) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 16:50:51 -0000 Michelle, just found this in the mail. However, it looks like the VPN to work is down. I can't get to the machine right now. I'll mail on Monday. P. ________________________________ From: Michelle Li To: freebsd-performance@freebsd.org Sent: Saturday, December 20, 2008 7:25:02 PM Subject: Re: ZFS, NFS and Network tuning (Paul Patterson) ...and the dmesg? please post freebsd-performance-request@freebsd.org wrote: Send freebsd-performance mailing list submissions to freebsd-performance@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-performance or, via email, send a message with subject or body 'help' to freebsd-performance-request@freebsd.org You can reach the person managing the list at freebsd-performance-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-performance digest..." Today's Topics: 1. Re: ZFS, NFS and Network tuning (Paul Patterson) 2. Re: ZFS, NFS and Network tuning (Paul Patterson) 3. Re: ZFS, NFS and Network tuning (Paul Patterson) 4. intel i7 and Hyperthreading (Mike Tancsa) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Dec 2008 06:47:59 -0800 (PST) From: Paul Patterson Subject: Re: ZFS, NFS and Network tuning To: Paul Patterson , freebsd-performance@freebsd.org Message-ID: <15723.22980.qm@web110511.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" ------------------------------ Message: 2 Date: Fri, 19 Dec 2008 10:03:14 -0800 (PST) From: Paul Patterson Subject: Re: ZFS, NFS and Network tuning To: Paul Patterson , freebsd-performance@freebsd.org Message-ID: <400826.77992.qm@web110510.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii Hello all, I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. P. ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 9:47:59 AM Subject: Re: ZFS, NFS and Network tuning Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" ------------------------------ Message: 3 Date: Fri, 19 Dec 2008 10:59:54 -0800 (PST) From: Paul Patterson Subject: Re: ZFS, NFS and Network tuning To: Paul Patterson , freebsd-performance@freebsd.org Message-ID: <309927.87042.qm@web110514.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii Hi, Well, I got some input on things: kern.ipc.somaxconn=32768 net.inet.tcp.mssdflt=1460 And for fstab rw,tcp,intr,noatime,nfsv3,-w=65536,-r=65536 I tried turning on polling with ifconfig bce0 polling, however, I didn't see it in ifconfig bce0 so I don't believe it to be active or the card doesn't support it. aI also removed async from the mounts. These had a detrimental affect on the FreeBSD server. I now get 64K per transfer (system -vm) but I'm still only getting about 4MB/sec on the disks and their utilization has dropped to about 5%. Throughput from both clients is ~8.5MB/sec. The tests were run separately. The NetAPP on each host was over 48.5 MB/sec. The FreeBSD host still has about 2 GB free. Paul ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 1:03:14 PM Subject: Re: ZFS, NFS and Network tuning Hello all, I guess I've got to send this as I've already had about 5 responses claiming the same thing. This is not a disk bottleneck. The ZFS partition is capable of performing at the theoretical max of the drives. The machine is performing at less than 5 MB combined. I'm assuming that this is a problem with the NFSv3 throughput. I just 'dd' 1000 1MB records (about 1GB) from the clients to their respective servers: Client 1 to NetAPP: 3 tests for 45.9, 45.1, 46.1 Pretty consistent Client 2 to FreeBSD/ZFS: 3 test for 29.7, 12.5, 19.1 NOT consistent (also, the drives were lucky to hit 12% busy. I'm about to mount these servers to each client and see if there's a variation (although they are hw configured the same and bought the same time.) I'll write after this. However, if more people could review the configurations below and see if there's anything glaring.... However, the lack of consistency shows something is wrong network wise. P. ________________________________ From: Paul Patterson To: Paul Patterson ; freebsd-performance@freebsd.org Sent: Friday, December 19, 2008 9:47:59 AM Subject: Re: ZFS, NFS and Network tuning Hi, as promised, the parameter tuning I have on the box (does anyone see anything wrong?) /boot/loader.conf kern.hz="100" vm.kmem_size_max="1536M" vm.kmem_size="1536M" vfs.zfs.prefetch_disble=1 /etc/sysctl.conf kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.mxvnodes=600000 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcpsendbuf_inc=8192 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 ________________________________ From: Paul Patterson To: freebsd-performance@freebsd.org Sent: Thursday, December 18, 2008 8:04:37 PM Subject: ZFS, NFS and Network tuning Hi, I just set up my first machine with ZFS. (First, ZFS is nothing short of amazing) I'm running FreeBSD 7.1-RC1 as an NFS server with ZFS striped across two volumes (just testing throughput for now.) Anyhow, I was benching this box, 4GB or RAM, the volume is on 2x146 GB SAS 10K rpm drives and it's an HP Proliant DL360 with dual Gb interfaces. (device bce) Now, I believe that I have tuned this box to the hilt with all the parameters that I can think of (it's at work right now so I'll cut and paste all the sysctls and loader.conf parameters for ZFS and networking) and it still seems to have some type of bottleneck. I have two Debian Linux clients that I use to bench with. I run a script that makes calls that writes to the NFS device and, after about 30 minutes, starts to delete the initial data and follow behind writing and deleting. Here's what's happening: The "other" machine is a NetAPP. It's got 1GB of RAM and it's running RAID DP with 2 parity drives and 6 data drives, all SATA 750 GB 7200 RPM drives with dual Gb interfaces. The benchmark script manages to write lots of little (all less than 30KB) files at a rate of 11,000 per minute, however, after 30 minutes, when it starts deleting, the throughput on write goes to 9500 and deletion is 6000 per minute. If I turn on the second node, I get 17,000 writing combined with about 11,000 deletions combined. One way or another, this will overflow in time. Not good. Now, on to my pet project. :-) The FreeBSD/ZFS server is only able to maintain about 3500 writes per minute but also deletes at the same rate! (I would expect deletion to be at least as fast as writing) The drives are running at only 20-35% while this is going on and only putting down about 4-5 MB/sec each. So, at 1Gb or ~92MB/sec theoretical max (is that about right?) There's something wrong somewhere. I'm assuming it's the network. (I'll post all the tunings tomorrow.) Thinking something wrong, I mounted only one client to each server (they are identical clients and the same configuration as the FreeBSD box). I did a simple stream of: dd if=/dev/zero of=/mnt/nfs bs=1m count=1000. The FreeBSD box wins?! It cranked up the drives to 45-50 MB/sec each and balanced them perfectly on transactions/sec KB/sec, etc from systat -vm. (Woohoo!) The NetAPPs CPU was at over 35-40% constantly, (it does that while benching, too) I'll post the NetAPP finding tomorrow as I forgot it for now. As for the client mounting, it was with the options: nfsvers=3,rsize=32768,wsize=32768,hard,intr,async,noatime I'm trying to figure out why, when running this benchmark, can the NetAPP with WAFL nearly triple the FreeBSD/ZFS box. Also, I'm having something strange happen when I try to mount the disk from the FreeBSD server versus the NetAPP. The FreeBSD server will sometimes RPC timeout. Mounting the NetAPP is instantaneous. That's the beginning. If I have a list of things to check tomorrow, I will. I'd like to see the little machine that could kick the NetAPPs butt. (No offense to NetAPP. :-) ) Thank you for reading, Paul _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" ------------------------------ Message: 4 Date: Fri, 19 Dec 2008 17:01:46 -0500 From: Mike Tancsa Subject: intel i7 and Hyperthreading To: freebsd-performance@freebsd.org Message-ID: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Content-Type: text/plain; charset="us-ascii"; format=flowed Just got our first board to play around with and unlike in the past, having hyperthreading enabled seems to help performance.... At least in buildworld tests. doing a make -j4 vs -j6 make -j8 vs -j10 gives -j buildworld time % improvement over -j4 4 13:57 6 12:11 13% 8 11:32 18% 10 11:43 17% dmesg below of the hardware... The CPU seems to run fairly cool, but the board has a lot of nasty hot heatsinks eg. running 8 burnP6 procs 0[ns3c]# sysctl -a | grep temperature dev.cpu.0.temperature: 67 dev.cpu.1.temperature: 67 dev.cpu.2.temperature: 65 dev.cpu.3.temperature: 65 dev.cpu.4.temperature: 66 dev.cpu.5.temperature: 66 dev.cpu.6.temperature: 64 dev.cpu.7.temperature: 64 0[ns3c]# vs idle dev.cpu.0.temperature: 46 dev.cpu.1.temperature: 46 dev.cpu.2.temperature: 42 dev.cpu.3.temperature: 42 dev.cpu.4.temperature: 44 dev.cpu.5.temperature: 44 dev.cpu.6.temperature: 40 dev.cpu.7.temperature: 40 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Fri Dec 19 19:48:15 EST 2008 mdtancsa@ns3c.recycle.net:/usr/obj/usr/src/sys/recycle Timecounter "i8254" frequency 1193182 Hz quality 0 === message truncated === _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-performance@FreeBSD.ORG Tue Dec 23 09:53:23 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65BE11065670 for ; Tue, 23 Dec 2008 09:53:23 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 18C858FC1C for ; Tue, 23 Dec 2008 09:53:22 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LF3x1-0000sk-Sk for freebsd-performance@freebsd.org; Tue, 23 Dec 2008 09:53:19 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Dec 2008 09:53:19 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Dec 2008 09:53:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 23 Dec 2008 10:53:03 +0100 Lines: 37 Message-ID: References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB8C92D0589D84C46B9EE433" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.18 (X11/20081125) In-Reply-To: <200812192214.mBJMEj2Q009511@lava.sentex.ca> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 09:53:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB8C92D0589D84C46B9EE433 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike Tancsa wrote: > Just got our first board to play around with and unlike in the past, > having hyperthreading enabled seems to help performance.... At least in= > buildworld tests. >=20 > doing a make -j4 vs -j6 make -j8 vs -j10 gives >=20 > -j buildworld time % improvement over -j4 > 4 13:57 > 6 12:11 13% > 8 11:32 18% > 10 11:43 17% Thanks for posting this! --------------enigCB8C92D0589D84C46B9EE433 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJULUHldnAQVacBcgRAmmCAKDUnab1wHt0J6ZYfxgWTjUBTm1tRACgqrA7 OJMicwDoQPG8tYkRrkXzbWk= =3xSD -----END PGP SIGNATURE----- --------------enigCB8C92D0589D84C46B9EE433-- From owner-freebsd-performance@FreeBSD.ORG Tue Dec 23 11:06:53 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00AC11065693; Tue, 23 Dec 2008 11:06:53 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 783958FC49; Tue, 23 Dec 2008 11:06:51 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id mBNAM3Eo014116; Tue, 23 Dec 2008 11:22:03 +0100 From: Pieter de Goeje To: freebsd-performance@freebsd.org Date: Tue, 23 Dec 2008 11:22:02 +0100 User-Agent: KMail/1.9.10 References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812231122.02892.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Ivan Voras Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 11:06:53 -0000 On Tuesday 23 December 2008, Ivan Voras wrote: > Mike Tancsa wrote: > > Just got our first board to play around with and unlike in the past, > > having hyperthreading enabled seems to help performance.... At least in > > buildworld tests. > > > > doing a make -j4 vs -j6 make -j8 vs -j10 gives > > > > -j buildworld time % improvement over -j4 > > 4 13:57 > > 6 12:11 13% > > 8 11:32 18% > > 10 11:43 17% > > Thanks for posting this! What's missing is build times with hyperthreading disabled. make buildworld -j10 could easily be faster than -j4 even when hyperthreading is disabled, because of increased disk I/O concurrency. 11:43 to build world is very fast indeed :-) -- Pieter de Goeje From owner-freebsd-performance@FreeBSD.ORG Tue Dec 23 15:05:06 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00A97106564A for ; Tue, 23 Dec 2008 15:05:06 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BCAF18FC14 for ; Tue, 23 Dec 2008 15:05:05 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBNF514T047668; Tue, 23 Dec 2008 10:05:01 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBNF50Bu030894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 10:05:00 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812231505.mBNF50Bu030894@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Dec 2008 10:05:08 -0500 To: Pieter de Goeje , freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: <200812231122.02892.pieter@degoeje.nl> References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> <200812231122.02892.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Ivan Voras Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 15:05:06 -0000 At 05:22 AM 12/23/2008, Pieter de Goeje wrote: >On Tuesday 23 December 2008, Ivan Voras wrote: > > Mike Tancsa wrote: > > > Just got our first board to play around with and unlike in the past, > > > having hyperthreading enabled seems to help performance.... At least in > > > buildworld tests. > > > > > > doing a make -j4 vs -j6 make -j8 vs -j10 gives > > > > > > -j buildworld time % improvement over -j4 > > > 4 13:57 > > > 6 12:11 13% > > > 8 11:32 18% > > > 10 11:43 17% > > > > Thanks for posting this! > >What's missing is build times with hyperthreading disabled. >make buildworld -j10 could easily be faster than -j4 even when hyperthreading >is disabled, because of increased disk I/O concurrency. > >11:43 to build world is very fast indeed :-) With HT disabled in the BIOS make -j4, 13:48 make -j8, 12:35 so -j4 is about the same, but -j8 does show a bit of an improvement with HT enabled ( ~9%) ... ---Mike From owner-freebsd-performance@FreeBSD.ORG Tue Dec 23 16:21:00 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BA1106564A for ; Tue, 23 Dec 2008 16:21:00 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E00F88FC18 for ; Tue, 23 Dec 2008 16:20:59 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LFA05-0006Gr-5O for freebsd-performance@freebsd.org; Tue, 23 Dec 2008 16:20:53 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Dec 2008 16:20:53 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Dec 2008 16:20:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 23 Dec 2008 17:20:45 +0100 Lines: 34 Message-ID: References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Sender: news Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 16:21:00 -0000 Mike Tancsa wrote: > FreeBSD 7.1-PRERELEASE #0: Fri Dec 19 19:48:15 EST 2008 > mdtancsa@ns3c.recycle.net:/usr/obj/usr/src/sys/recycle > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2666.78-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 > > Features=0xbfebfbff > > > Features2=0x98e3bd > > AMD Features=0x28100000 > AMD Features2=0x1 > Cores per package: 8 > Logical CPUs per core: 2 > real memory = 2138992640 (2039 MB) > avail memory = 2084880384 (1988 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 I just thought of another thing - can you boot an 8-CURRENT kernel on the machine and report the value of kern.sched.topology_spec sysctl? This is to verify how the ULE sees the HTT topology of the CPUs. From owner-freebsd-performance@FreeBSD.ORG Tue Dec 23 16:47:53 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FFFD1065670; Tue, 23 Dec 2008 16:47:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 488298FC12; Tue, 23 Dec 2008 16:47:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBNGlq6J065014; Tue, 23 Dec 2008 11:47:52 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBNGlqkh031338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 11:47:52 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812231647.mBNGlqkh031338@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Dec 2008 11:48:00 -0500 To: Ivan Voras , freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 16:47:53 -0000 At 11:20 AM 12/23/2008, Ivan Voras wrote: >I just thought of another thing - can you boot an 8-CURRENT kernel >on the machine and report the value of kern.sched.topology_spec >sysctl? This is to verify how the ULE sees the HTT topology of the CPUs. It will have to wait for the next board as this is going out to a customer today. ---Mike >_______________________________________________ >freebsd-performance@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-performance >To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-performance@FreeBSD.ORG Tue Dec 23 21:00:22 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25FB5106564A; Tue, 23 Dec 2008 21:00:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A0AB08FC17; Tue, 23 Dec 2008 21:00:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBNL0KZk089413; Tue, 23 Dec 2008 16:00:20 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBNL0KPP032432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 16:00:20 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812232100.mBNL0KPP032432@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Dec 2008 16:00:18 -0500 To: Ivan Voras , freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_493074562==_" X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 21:00:22 -0000 --=====================_493074562==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:20 AM 12/23/2008, Ivan Voras wrote: >Mike Tancsa wrote: > >>FreeBSD 7.1-PRERELEASE #0: Fri Dec 19 19:48:15 EST 2008 >> mdtancsa@ns3c.recycle.net:/usr/obj/usr/src/sys/recycle >>Timecounter "i8254" frequency 1193182 Hz quality 0 >>CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2666.78-MHz >>686-class CPU) >> Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 >> >>Features=0xbfebfbff >> >> >>Features2=0x98e3bd >> >> AMD Features=0x28100000 >> AMD Features2=0x1 >> Cores per package: 8 >> Logical CPUs per core: 2 >>real memory = 2138992640 (2039 MB) >>avail memory = 2084880384 (1988 MB) >>ACPI APIC Table: >>FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 >> cpu4 (AP): APIC ID: 4 >> cpu5 (AP): APIC ID: 5 >> cpu6 (AP): APIC ID: 6 >> cpu7 (AP): APIC ID: 7 > >I just thought of another thing - can you boot an 8-CURRENT kernel >on the machine and report the value of kern.sched.topology_spec >sysctl? This is to verify how the ULE sees the HTT topology of the CPUs. I have a bit of delay, so I can run it with another disk for a day. 0[current]# sysctl -A kern.sched kern.sched.preemption: 1 kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 kern.sched.steal_thresh: 3 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 4 kern.sched.idlespins: 10000 kern.sched.static_boost: 160 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE 0[current]# I tried to boot off the eSata drive, but HEAD does not understand the controller properly as it never sees the disk. From the BIOS, it says its a marvel thingy and pciconf sees it that way too...Also, the ichwd doesnt seem to work. Its possible its disabled on the motherboard. dmesg and pciconf attached atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab rev=0xb2 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '6121 SATA2 Controller' class = mass storage subclass = ATA cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message cap 10[e0] = PCI-Express 1 legacy endpoint ---Mike --=====================_493074562==_ Content-Type: application/octet-stream; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQ1VSUkVOVCAjNTogVHVlIERlYyAyMyAxNTox MjoxNiBFU1QgMjAwOAogICAgbWR0YW5jc2FAY3VycmVudC5zZW50ZXguY2E6L3Vzci9vYmovdXNy L3NyYy9zeXMvc2VydmVyCldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCBy ZWR1Y2VkIHBlcmZvcm1hbmNlLgpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tl cm5lbCIgYXQgMHhjMGViYzAwMC4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDI2NjY3 ODE1NjggSHoKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKSBpNyBDUFUgICAgICAgICA5MjAgIEAgMi42 N0dIeiAoMjY2Ni43OC1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVs IiAgSWQgPSAweDEwNmE0ICBTdGVwcGluZyA9IDQKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxW TUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1Ys UEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBC RT4KICBGZWF0dXJlczI9MHg5OGUzYmQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxWTVgsRVNULFRN MixTU1NFMyxDWDE2LHhUUFIsUERDTSxTU0U0LjEsU1NFNC4yLFBPUENOVD4KICBBTUQgRmVhdHVy ZXM9MHgyODEwMDAwMDxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBU U0M6IFAtc3RhdGUgaW52YXJpYW50CiAgQ29yZXMgcGVyIHBhY2thZ2U6IDgKICBMb2dpY2FsIENQ VXMgcGVyIGNvcmU6IDIKCkRhdGEgVExCOiA0IEtCIHBhZ2VzLCA0LXdheSBzZXQgYXNzb2NpYXRp dmUsIDY0IGVudHJpZXMKMXN0LWxldmVsIGRhdGEgY2FjaGU6IDMyIEtCLCA4LXdheSBzZXQgYXNz b2NpYXRpdmUsIDY0IGJ5dGUgbGluZSBzaXplCkwyIGNhY2hlOiAyNTYga2J5dGVzLCA4LXdheSBh c3NvY2lhdGl2ZSwgNjQgYnl0ZXMvbGluZQpyZWFsIG1lbW9yeSAgPSAyMTM4OTkyNjQwICgyMDM5 IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAw MDAwMDAwMDA5ZGZmZiwgNjQzMDcyIGJ5dGVzICgxNTcgcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAw MCAtIDB4MDAwMDAwMDAwMDNmZmZmZiwgMzE0NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAw MDAwMDEwMjUwMDAgLSAweDAwMDAwMDAwN2IyM2JmZmYsIDIwNDkwMTE3MTIgYnl0ZXMgKDUwMDI0 NyBwYWdlcykKMHgwMDAwMDAwMDdkNjc3MDAwIC0gMHgwMDAwMDAwMDdmNmJjZmZmLCAzMzg0MTE1 MiBieXRlcyAoODI2MiBwYWdlcykKMHgwMDAwMDAwMDdmNmJmMDAwIC0gMHgwMDAwMDAwMDdmNzE4 ZmZmLCAzNjg2NDAgYnl0ZXMgKDkwIHBhZ2VzKQoweDAwMDAwMDAwN2Y3YmYwMDAgLSAweDAwMDAw MDAwN2Y3ZDZmZmYsIDk4MzA0IGJ5dGVzICgyNCBwYWdlcykKYXZhaWwgbWVtb3J5ID0gMjA4MjAw OTA4OCAoMTk4NSBNQikKVGFibGUgJ0ZBQ1AnIGF0IDB4N2Y3ZmQwMDAKVGFibGUgJ0FQSUMnIGF0 IDB4N2Y3ZjcwMDAKTUFEVDogRm91bmQgdGFibGUgYXQgMHg3ZjdmNzAwMApNUCBDb25maWd1cmF0 aW9uIFRhYmxlIHZlcnNpb24gMS40IGZvdW5kIGF0IDB4YzAwZmY0ZDAKQVBJQzogVXNpbmcgdGhl IE1BRFQgZW51bWVyYXRvci4KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDA6IGVu YWJsZWQKU01QOiBBZGRlZCBDUFUgMCAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDIgQUNQ SSBJRCAxOiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDIgKEFQKQpNQURUOiBGb3VuZCBDUFUgQVBJ QyBJRCA0IEFDUEkgSUQgMjogZW5hYmxlZApTTVA6IEFkZGVkIENQVSA0IChBUCkKTUFEVDogRm91 bmQgQ1BVIEFQSUMgSUQgNiBBQ1BJIElEIDM6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgNiAoQVAp Ck1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDEgQUNQSSBJRCA0OiBlbmFibGVkClNNUDogQWRkZWQg Q1BVIDEgKEFQKQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAzIEFDUEkgSUQgNTogZW5hYmxlZApT TVA6IEFkZGVkIENQVSAzIChBUCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgNSBBQ1BJIElEIDY6 IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgNSAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDcg QUNQSSBJRCA3OiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDcgKEFQKQpNQURUOiBGb3VuZCBDUFUg QVBJQyBJRCAxNiBBQ1BJIElEIDE6IGRpc2FibGVkCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDE4 IEFDUEkgSUQgMzogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMjAgQUNQSSBJRCA1 OiBkaXNhYmxlZApNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAyMiBBQ1BJIElEIDc6IGRpc2FibGVk Ck1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDE3IEFDUEkgSUQgOTogZGlzYWJsZWQKTUFEVDogRm91 bmQgQ1BVIEFQSUMgSUQgMTkgQUNQSSBJRCAxMTogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BVIEFQ SUMgSUQgMjEgQUNQSSBJRCAxMzogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMjMg QUNQSSBJRCAxNTogZGlzYWJsZWQKQUNQSSBBUElDIFRhYmxlOiA8SU5URUwgIERYNThTTyAgPgpJ TlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAyIGFzIGEgdGFyZ2V0CklOVFI6IEFkZGluZyBsb2NhbCBB UElDIDQgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgNiBhcyBhIHRhcmdldApG cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA4IENQVXMKIGNwdTAg KEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCiBjcHUyIChBUCk6IEFQ SUMgSUQ6ICAyCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICAzCiBjcHU0IChBUCk6IEFQSUMgSUQ6ICA0 CiBjcHU1IChBUCk6IEFQSUMgSUQ6ICA1CiBjcHU2IChBUCk6IEFQSUMgSUQ6ICA2CiBjcHU3IChB UCk6IEFQSUMgSUQ6ICA3CkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDAKQVBJQzogQ1BVIDEgaGFz IEFDUEkgSUQgNApBUElDOiBDUFUgMiBoYXMgQUNQSSBJRCAxCkFQSUM6IENQVSAzIGhhcyBBQ1BJ IElEIDUKQVBJQzogQ1BVIDQgaGFzIEFDUEkgSUQgMgpBUElDOiBDUFUgNSBoYXMgQUNQSSBJRCA2 CkFQSUM6IENQVSA2IGhhcyBBQ1BJIElEIDMKQVBJQzogQ1BVIDcgaGFzIEFDUEkgSUQgNwpwbnBi aW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmUwZTAKcG5wYmlvczogRW50cnkgPSBm MDAwMDphZWY5ICBSZXYgPSAxLjAKcG5wYmlvczogT0VNIElEIDgyMjQ3NDRlCk90aGVyIEJJT1Mg c2lnbmF0dXJlcyBmb3VuZDoKV0FSTklORzogTm9uLXVuaWZvcm0gcHJvY2Vzc29ycy4KV0FSTklO RzogVXNpbmcgc3Vib3B0aW1hbCB0b3BvbG9neS4KVUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVw IGNwdSAxClVMRTogc2V0dXAgY3B1IDIKVUxFOiBzZXR1cCBjcHUgMwpVTEU6IHNldHVwIGNwdSA0 ClVMRTogc2V0dXAgY3B1IDUKVUxFOiBzZXR1cCBjcHUgNgpVTEU6IHNldHVwIGNwdSA3CkFDUEk6 IFJTRFAgQCAweDB4ZmUwMjAvMHgwMDI0ICh2ICAyIElOVEVMICkKQUNQSTogWFNEVCBAIDB4MHg3 ZjdmZTEyMC8weDAwNkMgKHYgIDEgSU5URUwgIERYNThTTyAgIDB4MDAwMDA4NEYgICAgICAweDAx MDAwMDEzKQpBQ1BJOiBGQUNQIEAgMHgweDdmN2ZkMDAwLzB4MDBGNCAodiAgMyBJTlRFTCAgRFg1 OFNPICAgMHgwMDAwMDg0RiBNU0ZUIDB4MDEwMDAwMEQpCkFDUEkgV2FybmluZyAodGJmYWR0LTA1 MDUpOiBPcHRpb25hbCBmaWVsZCAiUG0yQ29udHJvbEJsb2NrIiBoYXMgemVybyBhZGRyZXNzIG9y IGxlbmd0aDogICAgICAgIDAgICAgIDQ1MC8wIFsyMDA3MDMyMF0KQUNQSTogRFNEVCBAIDB4MHg3 ZjdmODAwMC8weDQzQ0UgKHYgIDIgSU5URUwgIERYNThTTyAgIDB4MDAwMDA4NEYgTVNGVCAweDAx MDAwMDBEKQpBQ1BJOiBGQUNTIEAgMHgweDdmNzJiMDAwLzB4MDA0MApBQ1BJOiBBUElDIEAgMHgw eDdmN2Y3MDAwLzB4MDEzOCAodiAgMiBJTlRFTCAgRFg1OFNPICAgMHgwMDAwMDg0RiBNU0ZUIDB4 MDEwMDAwMEQpCkFDUEk6IFdERFQgQCAweDB4N2Y3ZjYwMDAvMHgwMDQwICh2ICAxIElOVEVMICBE WDU4U08gICAweDAwMDAwODRGIE1TRlQgMHgwMTAwMDAwRCkKQUNQSTogTUNGRyBAIDB4MHg3Zjdm NTAwMC8weDAwM0MgKHYgIDEgSU5URUwgIERYNThTTyAgIDB4MDAwMDA4NEYgTVNGVCAweDAxMDAw MDBEKQpBQ1BJOiBBU0YhIEAgMHgweDdmN2Y0MDAwLzB4MDBBQyAodiAzMiBJTlRFTCAgRFg1OFNP ICAgMHgwMDAwMDg0RiBNU0ZUIDB4MDEwMDAwMEQpCkFDUEk6IFNTRFQgQCAweDB4N2Y3ZWEwMDAv MHg3MEFDICh2ICAxIElOVEVMICBTU0RUICBQTSAweDAwMDAwODRGIE1TRlQgMHgwMTAwMDAwRCkK QUNQSTogRE1BUiBAIDB4MHg3ZjdlNzAwMC8weDAxNDAgKHYgIDEgSU5URUwgIERYNThTTyAgIDB4 MDAwMDA4NEYgTVNGVCAweDAxMDAwMDBEKQpBQ1BJOiBXRFRUIEAgMHgweDdmN2YyMDAwLzB4MDIw QyAodiAgMSBJTlRFTCAgRFg1OFNPICAgMHgwMDAwMDg0RiBNU0ZUIDB4MDEwMDAwMEQpCkFDUEk6 IEFTUFQgQCAweDB4N2Y3ZjMwMDAvMHgwMDM0ICh2ICA0IElOVEVMICBQZXJmVHVuZSAweDAwMDAw ODRGIE1TRlQgMHgwMTAwMDAwRCkKTUFEVDogRm91bmQgSU8gQVBJQyBJRCA4LCBJbnRlcnJ1cHQg MCBhdCAweGZlYzAwMDAwCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBpbnRw aW4gMApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAwLCBpcnEgMgppb2FwaWMwOiBS b3V0aW5nIElSUSAwIC0+IGludHBpbiAyCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNl IDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsCmxhcGljMDogUm91dGlu ZyBOTUkgLT4gTElOVDEKbGFwaWMwOiBMSU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBpYzA6IExJTlQx IHBvbGFyaXR5OiBoaWdoCmxhcGljMjogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWMyOiBMSU5U MSB0cmlnZ2VyOiBsZXZlbApsYXBpYzI6IExJTlQxIHBvbGFyaXR5OiBoaWdoCmxhcGljNDogUm91 dGluZyBOTUkgLT4gTElOVDEKbGFwaWM0OiBMSU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBpYzQ6IExJ TlQxIHBvbGFyaXR5OiBoaWdoCmxhcGljNjogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWM2OiBM SU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBpYzY6IExJTlQxIHBvbGFyaXR5OiBoaWdoCmxhcGljMTog Um91dGluZyBOTUkgLT4gTElOVDEKbGFwaWMxOiBMSU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBpYzE6 IExJTlQxIHBvbGFyaXR5OiBoaWdoCmxhcGljMzogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWMz OiBMSU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBpYzM6IExJTlQxIHBvbGFyaXR5OiBoaWdoCmxhcGlj NTogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWM1OiBMSU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBp YzU6IExJTlQxIHBvbGFyaXR5OiBoaWdoCmxhcGljNzogUm91dGluZyBOTUkgLT4gTElOVDEKbGFw aWM3OiBMSU5UMSB0cmlnZ2VyOiBsZXZlbApsYXBpYzc6IExJTlQxIHBvbGFyaXR5OiBoaWdoCk1B RFQ6IElnbm9yaW5nIGxvY2FsIE5NSSByb3V0ZWQgdG8gQUNQSSBDUFUgOApNQURUOiBJZ25vcmlu ZyBsb2NhbCBOTUkgcm91dGVkIHRvIEFDUEkgQ1BVIDkKTUFEVDogSWdub3JpbmcgbG9jYWwgTk1J IHJvdXRlZCB0byBBQ1BJIENQVSAxMApNQURUOiBJZ25vcmluZyBsb2NhbCBOTUkgcm91dGVkIHRv IEFDUEkgQ1BVIDExCk1BRFQ6IElnbm9yaW5nIGxvY2FsIE5NSSByb3V0ZWQgdG8gQUNQSSBDUFUg MTIKTUFEVDogSWdub3JpbmcgbG9jYWwgTk1JIHJvdXRlZCB0byBBQ1BJIENQVSAxMwpNQURUOiBJ Z25vcmluZyBsb2NhbCBOTUkgcm91dGVkIHRvIEFDUEkgQ1BVIDE0Ck1BRFQ6IElnbm9yaW5nIGxv Y2FsIE5NSSByb3V0ZWQgdG8gQUNQSSBDUFUgMTUKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZApsYXBpYzA6IEZvcmNpbmcgTElOVDEgdG8gZWRnZSB0cmlnZ2Vy CmNwdTAgQlNQOgogICAgIElEOiAweDAwMDAwMDAwICAgVkVSOiAweDAwMDYwMDE1IExEUjogMHgw MDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAw ODQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYg dGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAwMDQwMApyYW5kb206 IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KbmZzbG9jazogcHNldWRvLWRldmlj ZQprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgwCm1lbTogPG1lbW9yeT4KUGVu dGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKaW86IDxJL08+Cm51bGw6IDxudWxsIGRldmlj ZSwgemVybyBkZXZpY2U+CmhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNvbnRyb2xs ZXIgZHJpdmVyIHYxLjIgKERlYyAyMyAyMDA4IDE1OjExOjU2KQpucHgwOiBJTlQgMTYgaW50ZXJm YWNlCmFjcGkwOiA8SU5URUwgRFg1OFNPPiBvbiBtb3RoZXJib2FyZApQQ0llOiBNZW1vcnkgTWFw cGVkIGNvbmZpZ3VyYXRpb24gYmFzZSBAIDB4ZjgwMDAwMDAKcGNpYmlvczogTm8gY2FsbCBlbnRy eSBwb2ludAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIHZlY3RvciA0 OAphY3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChm aXhlZCkKYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4YzRlOWUwMDAgcGEgMHgxMDAwCmFjcGlfYnVz X251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNp SWQ6IFxcX1NCXy5QQ0kwLlBBTVggLT4gYnVzIDAgZGV2IDAgZnVuYyAwCmFjcGlfYnVzX251bWJl cjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxc X1NCXy5QQ0kwLkxQQ18uUFJSMCAtPiBidXMgMCBkZXYgMzEgZnVuYyAwCmFjcGlfYnVzX251bWJl cjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxc X1NCXy5QQ0kwLkxQQ18uUFJSMSAtPiBidXMgMCBkZXYgMzEgZnVuYyAwCmFjcGlfYnVzX251bWJl cjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxc X1NCXy5QQ0kwLkxQQ18uSUVMSy5FTFIwIC0+IGJ1cyAwIGRldiAwIGZ1bmMgMApBQ1BJIHRpbWVy OiAxLzIgMS8yIDEvMiAxLzEgMS8wIDEvMCAxLzEgMS8yIDEvMCAxLzIgLT4gMTAKVGltZWNvdW50 ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGlt ZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFj cGkwCnBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAx NQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg MTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2 IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMjogICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAg ICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1 CnBjaV9saW5rMzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEg MTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDUgICBOICAgICAwICAzIDQgNSA2IDcg OSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA1ICAgTiAgICAgMCAg MyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNTogICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBj aV9saW5rNjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAgIDUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIg MTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0 IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1 dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0w eGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kwOiBkb21haW49 MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDA1LCByZXZp ZD0weDEyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2Fj aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMC5JTlRBCnBjaWIwOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2 CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwOCwgcmV2aWQ9MHgxMgoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZk ZXY9MAoJY21kcmVnPTB4MDE0MCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3IgbWFza3MKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBCnBjaWIwOiBzbG90IDEgSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwYSwgcmV2aWQ9MHgxMgoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTMsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MAoJY21kcmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3IgbWFza3MKcGNp YjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRBCnBjaWIwOiBzbG90IDMgSU5UQSBoYXJkd2ly ZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwZSwgcmV2aWQ9MHgx MgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTcsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5 cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDE0MCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMyAgc3VwcG9y dHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3IgbWFz a3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlRBCnBjaWIwOiBzbG90IDcgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQyNSwgcmV2 aWQ9MHgxMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE2LCBmdW5jPTAKCWNsYXNzPTA4LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0 MjYsIHJldmlkPTB4MTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNiwgZnVuYz0xCgljbGFzcz0w OC0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4 MDAwMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzNDJlLCByZXZpZD0weDEyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MAoJ Y2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4MzQyMiwgcmV2aWQ9MHgxMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBm dW5jPTEKCWNsYXNzPTA4LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAw MDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDM0MjMsIHJldmlkPTB4MTIKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0yMCwgZnVuYz0yCgljbGFzcz0wOC0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRy ZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDM4LCByZXZpZD0weDEyCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjAsIGZ1bmM9MwoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTBjYywgcmV2aWQ9MHgwMAoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTI1LCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBl IE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlNDQwMDAwMCwgc2l6ZSAxNywgZW5hYmxlZAoJbWFw WzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZTQ0MjIwMDAsIHNpemUgMTIsIGVu YWJsZWQKCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NDBlMCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNS5JTlRBCnBjaWIwOiBz bG90IDI1IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDNhMzcsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0wCglj bGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0 cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJ bWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg0MGMwLCBzaXplICA1LCBl bmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEKcGNpYjA6IHNsb3QgMjYg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2Ez OCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5jPTEKCWNsYXNzPTBj LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgw MjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTExCgltYXBbMjBd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDQwYTAsIHNpemUgIDUsIGVuYWJsZWQK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQgpwY2liMDogc2xvdCAyNiBJTlRCIGhh cmR3aXJlZCB0byBJUlEgMjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTM5LCByZXZp ZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjYsIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTAKCW1hcFsyMF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NDA4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRECnBjaWIwOiBzbG90IDI2IElOVEQgaGFyZHdpcmVk IHRvIElSUSAxOQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhM2MsIHJldmlkPTB4MDAK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2Ug MHhlNDQyMTAwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y Ni5JTlRDCnBjaWIwOiBzbG90IDI2IElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDNhM2UsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0yNywgZnVuYz0wCgljbGFzcz0wNC0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWlu dHBpbj1hLCBpcnE9NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5n ZSA2NCwgYmFzZSAweGY2MDAwMDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVu dHJ5IGZvciAwLjI3LklOVEEKcGNpYjA6IHNsb3QgMjcgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIy CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2E0MCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTI4LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1m ZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjI4LklOVEEKcGNpYjA6IHNsb3QgMjggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5k LT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2E0MiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTI4LCBmdW5jPTEKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEK CWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50 IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI4 LklOVEIKcGNpYjA6IHNsb3QgMjggSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4M2E0OCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTI4LCBmdW5jPTQKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50 cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI4LklOVEEK cGNpYjA6IHNsb3QgMjggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4M2EzNCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBm dW5jPTAKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAw MDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwg aXJxPTEwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDQwNjAsIHNp emUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpwY2liMDog c2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjMKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzYTM1LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJ Y2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3Rh dHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTAK CW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NDA0MCwgc2l6ZSAgNSwg ZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCCnBjaWIwOiBzbG90IDI5 IElOVEIgaGFyZHdpcmVkIHRvIElSUSAxOQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNh MzYsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0yCgljbGFzcz0w Yy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4 MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0xMQoJbWFwWzIw XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg0MDIwLCBzaXplICA1LCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEMKcGNpYjA6IHNsb3QgMjkgSU5UQyBo YXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EzYSwgcmV2 aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTcKCWNsYXNzPTBjLTAzLTIw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjkwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAweGU0NDIwMDAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5 IGZvciAwLjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIzCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQ0ZSwgcmV2aWQ9MHg5MAoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1mZGV2 PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDE4ICg2MDAwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2ExNiwgcmV2aWQ9MHgwMAoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTAKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EyMCwgcmV2aWQ9MHgw MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTIKCWNsYXNzPTAxLTAxLThmLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMyAgc3VwcG9y dHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4NDE1OCwgc2l6ZSAgMywgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHg0MTZjLCBzaXplICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweDQxNTAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxY106IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NDE2OCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFw WzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg0MTMwLCBzaXplICA0LCBlbmFi bGVkCgltYXBbMjRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDQxMjAsIHNpemUg IDQsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQQpwY2liMDogc2xv dCAzMSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgzYTMwLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MwoJY2xh c3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMywgc3RhdHJl Zz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTEKCW1h cFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY2MDA0MDAwLCBzaXplICA4LCBl bmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDQwMDAsIHNp emUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQgpwY2liMDog c2xvdCAzMSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTgKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzYTI2LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9NQoJ Y2xhc3M9MDEtMDEtODUsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3Rh dHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTEK CXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg0MTQ4LCBzaXplICAzLCBlbmFibGVkCgltYXBbMTRd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDQxNjQsIHNpemUgIDIsIGVuYWJsZWQK CW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NDE0MCwgc2l6ZSAgMywg ZW5hYmxlZAoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg0MTYwLCBz aXplICAyLCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eDQxMTAsIHNpemUgIDQsIGVuYWJsZWQKCW1hcFsyNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4NDEwMCwgc2l6ZSAgNCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4zMS5JTlRCCnBjaWIwOiBzbG90IDMxIElOVEIgaGFyZHdpcmVkIHRvIElSUSAxOApwY2liMTog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6 ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIx OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4 MApwY2liMTogICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMQpwY2kxOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaWIyOiAgIGRvbWFpbiAgICAg ICAgICAgIDAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0 ZSBidXMgICAyCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MzAwMC0weDNmZmYKcGNpYjI6 ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlNDMwMDAwMC0weGU0M2ZmZmZmCnBjaWIyOiAgIHByZWZl dGNoZWQgZGVjb2RlIDB4ZjQwMDAwMDAtMHhmNWZmZmZmZgpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMgpwY2kyOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgx M2MxLCBkZXY9MHgxMDA0LCByZXZpZD0weDAxCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVu Yz0wCgljbGFzcz0wMS0wNC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3 LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBp cnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJ IHN1cHBvcnRzIDMyIG1lc3NhZ2VzLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgUHJlZmV0Y2hhYmxl IE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDAwMDAwMCwgc2l6ZSAyNSwgZW5hYmxlZApwY2li MjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY0MDAwMDAwLTB4ZjVmZmZmZmY6IGdvb2QKCW1h cFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGU0MzAwMDAwLCBzaXplIDEyLCBl bmFibGVkCnBjaWIyOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZTQzMDAwMDAtMHhlNDMwMGZm ZjogZ29vZAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgzMDAwLCBz aXplICA4LCBlbmFibGVkCnBjaWIyOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MzAwMC0weDMwZmY6 IGluIHJhbmdlCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjAuSU5UQQpwY2liMjogc2xvdCAw IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgozd2FyZSBkZXZpY2UgZHJpdmVyIGZvciA5MDAwIHNl cmllcyBzdG9yYWdlIGNvbnRyb2xsZXJzLCB2ZXJzaW9uOiAzLjcwLjA1LjAwMQp0d2EwOiA8M3dh cmUgOTAwMCBzZXJpZXMgU3RvcmFnZSBDb250cm9sbGVyPiBwb3J0IDB4MzAwMC0weDMwZmYgbWVt IDB4ZjQwMDAwMDAtMHhmNWZmZmZmZiwweGU0MzAwMDAwLTB4ZTQzMDBmZmYgaXJxIDE2IGF0IGRl dmljZSAwLjAgb24gcGNpMgp0d2EwOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDE4 IHR5cGUgMyBhdCAweGU0MzAwMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJR IDE2KSB0byB2ZWN0b3IgNDkKdHdhMDogW01QU0FGRV0KdHdhMDogW0lUSFJFQURdCnR3YTA6IElO Rk86ICgweDE1OiAweDEzMDApOiBDb250cm9sbGVyIGRldGFpbHM6OiBNb2RlbCA5NjUwU0UtMkxQ LCAyIHBvcnRzLCBGaXJtd2FyZSBGRTlYIDQuMDYuMDAuMDA0LCBCSU9TIEJFOVggNC4wNS4wMC4w MTUKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDcuMCBvbiBw Y2kwCnBjaWIzOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAg ICAgMwpwY2liMzogICBzdWJvcmRpbmF0ZSBidXMgICAzCnBjaWIzOiAgIEkvTyBkZWNvZGUgICAg ICAgIDB4MC0weDAKcGNpYjM6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMzogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjMKcGNpMzogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCnBjaTA6IDxiYXNl IHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTYuMCAobm8gZHJp dmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxl cj4gYXQgZGV2aWNlIDE2LjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBo ZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0 YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBk ZXZpY2UgMjAuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBp bnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkK cGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAy MC4zIChubyBkcml2ZXIgYXR0YWNoZWQpCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsg Q29ubmVjdGlvbiA2LjkuNj4gcG9ydCAweDQwZTAtMHg0MGZmIG1lbSAweGU0NDAwMDAwLTB4ZTQ0 MWZmZmYsMHhlNDQyMjAwMC0weGU0NDIyZmZmIGlycSAyMCBhdCBkZXZpY2UgMjUuMCBvbiBwY2kw CmVtMDogUmVzZXJ2ZWQgMHgyMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTQ0 MDAwMDAKZW0wOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9y dGVkKQptc2k6IHJvdXRpbmcgTVNJIElSUSAyNTYgdG8gdmVjdG9yIDUwCmVtMDogdXNpbmcgSVJR IDI1NiBmb3IgTVNJCmVtMDogVXNpbmcgTVNJIGludGVycnVwdAplbTA6IFJlc2VydmVkIDB4MTAw MCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSAzIGF0IDB4ZTQ0MjIwMDAKZW0wOiBbRklMVEVSXQpl bTA6IGJwZiBhdHRhY2hlZAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjFjOmMwOjkyOmQ1Ojgz CnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyNi4wIChubyBkcml2ZXIgYXR0YWNo ZWQpCnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyNi4xIChubyBkcml2ZXIgYXR0 YWNoZWQpCnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyNi4yIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyNi43IChubyBkcml2 ZXIgYXR0YWNoZWQpCnBjaTA6IDxtdWx0aW1lZGlhLCBIREE+IGF0IGRldmljZSAyNy4wIChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRl dmljZSAyOC4wIG9uIHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNDogICBz ZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjQ6ICAg SS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liNDogICBubyBwcmVmZXRjaGVkIGRlY29kZQpw Y2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2k0OiBkb21haW49MCwgcGh5c2ljYWwgYnVz PTQKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjEgb24g cGNpMApwY2liNTogICBkb21haW4gICAgICAgICAgICAwCnBjaWI1OiAgIHNlY29uZGFyeSBidXMg ICAgIDUKcGNpYjU6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQpwY2liNTogICBJL08gZGVjb2RlICAg ICAgICAweGYwMDAtMHhmZmYKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlNDIwMDAwMC0w eGU0MmZmZmZmCnBjaWI1OiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaTU6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI1CnBjaTU6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NQpmb3VuZC0+CXZlbmRv cj0weDE0ZTQsIGRldj0weDE2NzcsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9NSwgc2xvdD0w LCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0w eDAwMDYsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu PWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kg c3VwcG9ydHMgOCBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2Ug NjQsIGJhc2UgMHhlNDIwMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liNTogcmVxdWVzdGVkIG1l bW9yeSByYW5nZSAweGU0MjAwMDAwLTB4ZTQyMGZmZmY6IGdvb2QKcGNpYjU6IG1hdGNoZWQgZW50 cnkgZm9yIDUuMC5JTlRBCnBjaWI1OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CnBj aTA6NTowOjA6IGJhZCBWUEQgY2tzdW0sIHJlbWFpbiA5CmJnZTA6IDxIUFEgMTAvMTAwLzEwMDAg Q29wcGVyIEJhc2VkIEdpZ2FiaXQgQWRhcHRlciwgQVNJQyByZXYuIDB4NDAwMT4gbWVtIDB4ZTQy MDAwMDAtMHhlNDIwZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k1CmJnZTA6IFJlc2Vy dmVkIDB4MTAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGU0MjAwMDAwCm1paWJ1 czA6IDxNSUkgYnVzPiBvbiBiZ2UwCmJyZ3BoeTA6IDxCQ001NzUwIDEwLzEwMC8xMDAwYmFzZVRY IFBIWT4gUEhZIDEgb24gbWlpYnVzMApicmdwaHkwOiBPVUkgMHgwMDA4MTgsIG1vZGVsIDB4MDAx OCwgcmV2LiAwCmJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBi YXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KYmdlMDogYnBmIGF0dGFj aGVkCmJnZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOjE4OjE0OjE1OjEyCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE3IChQQ0kgSVJRIDE3KSB0byB2ZWN0b3IgNTEKYmdlMDogW01QU0FGRV0K YmdlMDogW0lUSFJFQURdCnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRl dmljZSAyOC40IG9uIHBjaTAKcGNpYjY6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNjogICBz ZWNvbmRhcnkgYnVzICAgICA2CnBjaWI2OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDYKcGNpYjY6ICAg SS9PIGRlY29kZSAgICAgICAgMHgyMDAwLTB4MmZmZgpwY2liNjogICBtZW1vcnkgZGVjb2RlICAg ICAweGU0MTAwMDAwLTB4ZTQxZmZmZmYKcGNpYjY6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNp NjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjYKcGNpNjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz02 CmZvdW5kLT4JdmVuZG9yPTB4MTFhYiwgZGV2PTB4NjEyMSwgcmV2aWQ9MHhiMgoJZG9tYWluPTAs IGJ1cz02LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDEtMDEtOGYsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDMg IGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4MjAxOCwgc2l6ZSAgMywgZW5hYmxlZApwY2liNjogcmVxdWVz dGVkIEkvTyByYW5nZSAweDIwMTgtMHgyMDFmOiBpbiByYW5nZQoJbWFwWzE0XTogdHlwZSBJL08g UG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyMDI0LCBzaXplICAyLCBlbmFibGVkCnBjaWI2OiByZXF1 ZXN0ZWQgSS9PIHJhbmdlIDB4MjAyNC0weDIwMjc6IGluIHJhbmdlCgltYXBbMThdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIwMTAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjY6IHJl cXVlc3RlZCBJL08gcmFuZ2UgMHgyMDEwLTB4MjAxNzogaW4gcmFuZ2UKCW1hcFsxY106IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjAyMCwgc2l6ZSAgMiwgZW5hYmxlZApwY2liNjog cmVxdWVzdGVkIEkvTyByYW5nZSAweDIwMjAtMHgyMDIzOiBpbiByYW5nZQoJbWFwWzIwXTogdHlw ZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyMDAwLCBzaXplICA0LCBlbmFibGVkCnBjaWI2 OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MjAwMC0weDIwMGY6IGluIHJhbmdlCgltYXBbMjRdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlNDEwMDAwMCwgc2l6ZSAxMCwgZW5hYmxlZApw Y2liNjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGU0MTAwMDAwLTB4ZTQxMDAzZmY6IGdvb2QK cGNpYjY6IG1hdGNoZWQgZW50cnkgZm9yIDYuMC5JTlRBCnBjaWI2OiBzbG90IDAgSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDE2CmF0YXBjaTA6IDxNYXJ2ZWxsIDg4U1g2MTIxIFVETUExMzMgY29udHJv bGxlcj4gcG9ydCAweDIwMTgtMHgyMDFmLDB4MjAyNC0weDIwMjcsMHgyMDEwLTB4MjAxNywweDIw MjAtMHgyMDIzLDB4MjAwMC0weDIwMGYgbWVtIDB4ZTQxMDAwMDAtMHhlNDEwMDNmZiBpcnEgMTYg YXQgZGV2aWNlIDAuMCBvbiBwY2k2CmF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJp ZCAweDIwIHR5cGUgNCBhdCAweDIwMDAKYXRhcGNpMDogW01QU0FGRV0KYXRhcGNpMDogW0lUSFJF QURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4 OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MjAxOAphdGFwY2kwOiBSZXNlcnZlZCAw eDQgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDIwMjQKYXRhMjogcmVzZXQgdHAxIG1h c2s9MDMgb3N0YXQwPTYwIG9zdGF0MT03MAphdGEyOiBzdGF0MD0weDIwIGVycj0weDIwIGxzYj0w eDIwIG1zYj0weDIwCmF0YTI6IHN0YXQxPTB4MzAgZXJyPTB4MzAgbHNiPTB4MzAgbXNiPTB4MzAK YXRhMjogcmVzZXQgdHAyIHN0YXQwPTIwIHN0YXQxPTMwIGRldmljZXM9MHgwCmF0YTI6IFtNUFNB RkVdCmF0YTI6IFtJVEhSRUFEXQpwY2kwOiA8c2VyaWFsIGJ1cywgVVNCPiBhdCBkZXZpY2UgMjku MCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2VyaWFsIGJ1cywgVVNCPiBhdCBkZXZpY2Ug MjkuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2VyaWFsIGJ1cywgVVNCPiBhdCBkZXZp Y2UgMjkuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2VyaWFsIGJ1cywgVVNCPiBhdCBk ZXZpY2UgMjkuNyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liNzogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpYjc6ICAgZG9tYWluICAgICAgICAgICAgMApw Y2liNzogICBzZWNvbmRhcnkgYnVzICAgICA3CnBjaWI3OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDcK cGNpYjc6ICAgSS9PIGRlY29kZSAgICAgICAgMHgxMDAwLTB4MWZmZgpwY2liNzogICBtZW1vcnkg ZGVjb2RlICAgICAweGUyMDAwMDAwLTB4ZTQwZmZmZmYKcGNpYjc6ICAgcHJlZmV0Y2hlZCBkZWNv ZGUgMHhlMDAwMDAwMC0weGUxZmZmZmZmCnBjaWI3OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBi cmlkZ2UuCnBjaTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3CnBjaTc6IGRvbWFpbj0wLCBwaHlz aWNhbCBidXM9Nwpmb3VuZC0+CXZlbmRvcj0weDEyMWEsIGRldj0weDAwMDUsIHJldmlkPTB4MDEK CWRvbWFpbj0wLCBidXM9Nywgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHg4MDkwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMSAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAw eGUyMDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWI3OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdl IDB4ZTIwMDAwMDAtMHhlM2ZmZmZmZjogZ29vZAoJbWFwWzE0XTogdHlwZSBQcmVmZXRjaGFibGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGUwMDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWI3 OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZTAwMDAwMDAtMHhlMWZmZmZmZjogZ29vZAoJbWFw WzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxMDAwLCBzaXplICA4LCBlbmFi bGVkCnBjaWI3OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MTAwMC0weDEwZmY6IGluIHJhbmdlCnBj aWI3OiBtYXRjaGVkIGVudHJ5IGZvciA3LjIuSU5UQQpwY2liNzogc2xvdCAyIElOVEEgaGFyZHdp cmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDEwNGMsIGRldj0weDgwMjMsIHJldmlkPTB4 MDAKCWRvbWFpbj0wLCBidXM9Nywgc2xvdD0zLCBmdW5jPTAKCWNsYXNzPTBjLTAwLTEwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMTYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAyICg1MDAg bnMpLCBtYXhsYXQ9MHgwNCAoMTAwMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnks IHJhbmdlIDMyLCBiYXNlIDB4ZTQwMDQwMDAsIHNpemUgMTEsIGVuYWJsZWQKcGNpYjc6IHJlcXVl c3RlZCBtZW1vcnkgcmFuZ2UgMHhlNDAwNDAwMC0weGU0MDA0N2ZmOiBnb29kCgltYXBbMTRdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlNDAwMDAwMCwgc2l6ZSAxNCwgZW5hYmxlZApw Y2liNzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGU0MDAwMDAwLTB4ZTQwMDNmZmY6IGdvb2QK cGNpYjc6IG1hdGNoZWQgZW50cnkgZm9yIDcuMy5JTlRBCnBjaWI3OiBzbG90IDMgSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDE5CnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4 MTAwMC0weDEwZmYgbWVtIDB4ZTIwMDAwMDAtMHhlM2ZmZmZmZiwweGUwMDAwMDAwLTB4ZTFmZmZm ZmYgaXJxIDE4IGF0IGRldmljZSAyLjAgb24gcGNpNwpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVu dHMgVFNCNDNBQjIyL0E+IG1lbSAweGU0MDA0MDAwLTB4ZTQwMDQ3ZmYsMHhlNDAwMDAwMC0weGU0 MDAzZmZmIGlycSAxOSBhdCBkZXZpY2UgMy4wIG9uIHBjaTcKZndvaGNpMDogUmVzZXJ2ZWQgMHg4 MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGU0MDA0MDAwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDE5IChQQ0kgSVJRIDE5KSB0byB2ZWN0b3IgNTIKZndvaGNpMDogW01QU0FGRV0K ZndvaGNpMDogW0ZJTFRFUl0KZndvaGNpMDogT0hDSSB2ZXJzaW9uIDEuMTAgKFJPTT0wKQpmd29o Y2kwOiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4KZndvaGNpMDogRVVJNjQgMDA6 OTA6Mjc6MDA6MDI6Mzk6NzA6ZTMKZndvaGNpMDogUGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAy IHBvcnRzLgpmd29oY2kwOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4KZmlyZXdpcmUw OiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMApkY29uc19jcm9tMDogPGRjb25z IGNvbmZpZ3VyYXRpb24gUk9NPiBvbiBmaXJld2lyZTAKZGNvbnNfY3JvbTA6IGJ1c19hZGRyIDB4 N2Y2OGMwMDAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6IEJVUyByZXNldApm d29oY2kwOiBub2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2RlCmlzYWIw OiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+ IG9uIGlzYWIwCmF0YXBjaTE6IDxJbnRlbCBJQ0gxMCBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQg MHg0MTU4LTB4NDE1ZiwweDQxNmMtMHg0MTZmLDB4NDE1MC0weDQxNTcsMHg0MTY4LTB4NDE2Yiww eDQxMzAtMHg0MTNmLDB4NDEyMC0weDQxMmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAK YXRhcGNpMTogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4NDEz MAphdGFwY2kxOiBbTVBTQUZFXQphdGFwY2kxOiBbSVRIUkVBRF0KYXRhcGNpMTogUmVzZXJ2ZWQg MHgxMCBieXRlcyBmb3IgcmlkIDB4MjQgdHlwZSA0IGF0IDB4NDEyMAphdGEzOiA8QVRBIGNoYW5u ZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEw IHR5cGUgNCBhdCAweDQxNTgKYXRhcGNpMTogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDQgYXQgMHg0MTZjCmF0YTM6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3Rh dDE9MDAKYXRhMzogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEzOiBz dGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTM6IHJlc2V0IHRwMiBzdGF0 MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQphdGEzOiBbTVBTQUZFXQphdGEzOiBbSVRIUkVBRF0K YXRhNDogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRhcGNpMTogUmVzZXJ2ZWQgMHg4IGJ5 dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHg0MTUwCmF0YXBjaTE6IFJlc2VydmVkIDB4NCBi eXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4NDE2OAphdGE0OiByZXNldCB0cDEgbWFzaz0w MyBvc3RhdDA9N2Ygb3N0YXQxPTdmCmF0YTQ6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYg bXNiPTB4ZmYKYXRhNDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE0 OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTQ6IHN0YXQwPTB4N2Yg ZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9 MHhmZiBtc2I9MHhmZgphdGE0OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZm CmF0YTQ6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNDogc3RhdDA9 MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE0OiBzdGF0MD0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmCmF0YTQ6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNi PTB4ZmYKYXRhNDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE0OiBz dGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTQ6IHN0YXQwPTB4N2YgZXJy PTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZgphdGE0OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0 YTQ6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNDogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE0OiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmCmF0YTQ6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4 ZmYKYXRhNDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE0OiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTQ6IHN0YXQwPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZgphdGE0OiByZXNldCB0cDIgc3RhdDA9ZmYgc3RhdDE9ZmYgZGV2aWNlcz0weDAKYXRh NDogW01QU0FGRV0KYXRhNDogW0lUSFJFQURdCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQg ZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNpMjogPEludGVsIElDSDEwIFNB VEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDQxNDgtMHg0MTRmLDB4NDE2NC0weDQxNjcsMHg0MTQw LTB4NDE0NywweDQxNjAtMHg0MTYzLDB4NDExMC0weDQxMWYsMHg0MTAwLTB4NDEwZiBpcnEgMTgg YXQgZGV2aWNlIDMxLjUgb24gcGNpMAphdGFwY2kyOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciBy aWQgMHgyMCB0eXBlIDQgYXQgMHg0MTEwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kg SVJRIDE4KSB0byB2ZWN0b3IgNTMKYXRhcGNpMjogW01QU0FGRV0KYXRhcGNpMjogW0lUSFJFQURd CmF0YXBjaTI6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgNCBhdCAweDQx MDAKYXRhNTogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTIKYXRhcGNpMjogUmVzZXJ2ZWQgMHg4 IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHg0MTQ4CmF0YXBjaTI6IFJlc2VydmVkIDB4 NCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4NDE2NAphdGE1OiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9N2Ygb3N0YXQxPTdmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4 ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgph dGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4 N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0w eGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3Rh dDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0w eGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYg bXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1 OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2Yg ZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9 MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZm CmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9 MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNi PTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBz dGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJy PTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZgphdGE1OiByZXNldCB0cDIgc3RhdDA9ZmYgc3RhdDE9ZmYgZGV2aWNlcz0weDAK YXRhNTogW01QU0FGRV0KYXRhNTogW0lUSFJFQURdCmF0YTY6IDxBVEEgY2hhbm5lbCAxPiBvbiBh dGFwY2kyCmF0YXBjaTI6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0 IDB4NDE0MAphdGFwY2kyOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBh dCAweDQxNjAKYXRhNjogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0MT03ZgphdGE2 OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2Yg ZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9 MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZm CmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9 MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNi PTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBz dGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJy PTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0 YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4 ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6 IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogcmVzZXQgdHAyIHN0 YXQwPWZmIHN0YXQxPWZmIGRldmljZXM9MHgwCmF0YTY6IFtNUFNBRkVdCmF0YTY6IFtJVEhSRUFE XQphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzEsMHg3NC0weDc3IGly cSA4IG9uIGFjcGkwCmF0cnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChy ZXNvbHV0aW9uIDEwMDAwMDB1cykKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAplc3QwOiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCmVzdDA6IEludmFsaWQg aWQxNiAoc2V0LCBjdXIpID0gKDE5LCAyMCkKZXN0MDogSW52YWxpZCBmcmVxIDI1MjcsIGlnbm9y ZWQuCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE4LCAyMCkKZXN0MDogSW52YWxp ZCBmcmVxIDIzOTQsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE3 LCAyMCkKZXN0MDogSW52YWxpZCBmcmVxIDIyNjEsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQx NiAoc2V0LCBjdXIpID0gKDE2LCAyMCkKZXN0MDogSW52YWxpZCBmcmVxIDIxMjgsIGlnbm9yZWQu CmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1LCAyMCkKZXN0MDogSW52YWxpZCBm cmVxIDE5OTUsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE0LCAy MCkKZXN0MDogSW52YWxpZCBmcmVxIDE4NjIsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQxNiAo c2V0LCBjdXIpID0gKDEzLCAyMCkKZXN0MDogSW52YWxpZCBmcmVxIDE3MjksIGlnbm9yZWQuCmVz dDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEyLCAyMCkKZXN0MDogSW52YWxpZCBmcmVx IDE1OTYsIGlnbm9yZWQuCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBv biBjcHUwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3Rl cCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3Vy KSA9ICgxOSwgMjApCmVzdDE6IEludmFsaWQgZnJlcSAyNTI3LCBpZ25vcmVkLgplc3QxOiBJbnZh bGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOCwgMjApCmVzdDE6IEludmFsaWQgZnJlcSAyMzk0LCBp Z25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNywgMjApCmVzdDE6IElu dmFsaWQgZnJlcSAyMjYxLCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9 ICgxNiwgMjApCmVzdDE6IEludmFsaWQgZnJlcSAyMTI4LCBpZ25vcmVkLgplc3QxOiBJbnZhbGlk IGlkMTYgKHNldCwgY3VyKSA9ICgxNSwgMjApCmVzdDE6IEludmFsaWQgZnJlcSAxOTk1LCBpZ25v cmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNCwgMjApCmVzdDE6IEludmFs aWQgZnJlcSAxODYyLCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgx MywgMjApCmVzdDE6IEludmFsaWQgZnJlcSAxNzI5LCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlk MTYgKHNldCwgY3VyKSA9ICgxMiwgMjApCmVzdDE6IEludmFsaWQgZnJlcSAxNTk2LCBpZ25vcmVk LgpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQpjcHUyOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENv bnRyb2w+IG9uIGNwdTIKZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTksIDIwKQpl c3QyOiBJbnZhbGlkIGZyZXEgMjUyNywgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQs IGN1cikgPSAoMTgsIDIwKQplc3QyOiBJbnZhbGlkIGZyZXEgMjM5NCwgaWdub3JlZC4KZXN0Mjog SW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTcsIDIwKQplc3QyOiBJbnZhbGlkIGZyZXEgMjI2 MSwgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTYsIDIwKQplc3Qy OiBJbnZhbGlkIGZyZXEgMjEyOCwgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1 cikgPSAoMTUsIDIwKQplc3QyOiBJbnZhbGlkIGZyZXEgMTk5NSwgaWdub3JlZC4KZXN0MjogSW52 YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTQsIDIwKQplc3QyOiBJbnZhbGlkIGZyZXEgMTg2Miwg aWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTMsIDIwKQplc3QyOiBJ bnZhbGlkIGZyZXEgMTcyOSwgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikg PSAoMTIsIDIwKQplc3QyOiBJbnZhbGlkIGZyZXEgMTU5NiwgaWdub3JlZC4KcDR0Y2MyOiA8Q1BV IEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTIKY3B1MzogPEFDUEkgQ1BVPiBvbiBh Y3BpMAplc3QzOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUz CmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE5LCAyMCkKZXN0MzogSW52YWxpZCBm cmVxIDI1MjcsIGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE4LCAy MCkKZXN0MzogSW52YWxpZCBmcmVxIDIzOTQsIGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAo c2V0LCBjdXIpID0gKDE3LCAyMCkKZXN0MzogSW52YWxpZCBmcmVxIDIyNjEsIGlnbm9yZWQuCmVz dDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE2LCAyMCkKZXN0MzogSW52YWxpZCBmcmVx IDIxMjgsIGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1LCAyMCkK ZXN0MzogSW52YWxpZCBmcmVxIDE5OTUsIGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0 LCBjdXIpID0gKDE0LCAyMCkKZXN0MzogSW52YWxpZCBmcmVxIDE4NjIsIGlnbm9yZWQuCmVzdDM6 IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEzLCAyMCkKZXN0MzogSW52YWxpZCBmcmVxIDE3 MjksIGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEyLCAyMCkKZXN0 MzogSW52YWxpZCBmcmVxIDE1OTYsIGlnbm9yZWQuCnA0dGNjMzogPENQVSBGcmVxdWVuY3kgVGhl cm1hbCBDb250cm9sPiBvbiBjcHUzCmNwdTQ6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0NDogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1NAplc3Q0OiBJbnZhbGlk IGlkMTYgKHNldCwgY3VyKSA9ICgxOSwgMjApCmVzdDQ6IEludmFsaWQgZnJlcSAyNTI3LCBpZ25v cmVkLgplc3Q0OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOCwgMjApCmVzdDQ6IEludmFs aWQgZnJlcSAyMzk0LCBpZ25vcmVkLgplc3Q0OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgx NywgMjApCmVzdDQ6IEludmFsaWQgZnJlcSAyMjYxLCBpZ25vcmVkLgplc3Q0OiBJbnZhbGlkIGlk MTYgKHNldCwgY3VyKSA9ICgxNiwgMjApCmVzdDQ6IEludmFsaWQgZnJlcSAyMTI4LCBpZ25vcmVk Lgplc3Q0OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNSwgMjApCmVzdDQ6IEludmFsaWQg ZnJlcSAxOTk1LCBpZ25vcmVkLgplc3Q0OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNCwg MjApCmVzdDQ6IEludmFsaWQgZnJlcSAxODYyLCBpZ25vcmVkLgplc3Q0OiBJbnZhbGlkIGlkMTYg KHNldCwgY3VyKSA9ICgxMywgMjApCmVzdDQ6IEludmFsaWQgZnJlcSAxNzI5LCBpZ25vcmVkLgpl c3Q0OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxMiwgMjApCmVzdDQ6IEludmFsaWQgZnJl cSAxNTk2LCBpZ25vcmVkLgpwNHRjYzQ6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4g b24gY3B1NApjcHU1OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmVzdDU6IDxFbmhhbmNlZCBTcGVlZFN0 ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTUKZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1 cikgPSAoMTksIDIwKQplc3Q1OiBJbnZhbGlkIGZyZXEgMjUyNywgaWdub3JlZC4KZXN0NTogSW52 YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTgsIDIwKQplc3Q1OiBJbnZhbGlkIGZyZXEgMjM5NCwg aWdub3JlZC4KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTcsIDIwKQplc3Q1OiBJ bnZhbGlkIGZyZXEgMjI2MSwgaWdub3JlZC4KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikg PSAoMTYsIDIwKQplc3Q1OiBJbnZhbGlkIGZyZXEgMjEyOCwgaWdub3JlZC4KZXN0NTogSW52YWxp ZCBpZDE2IChzZXQsIGN1cikgPSAoMTUsIDIwKQplc3Q1OiBJbnZhbGlkIGZyZXEgMTk5NSwgaWdu b3JlZC4KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTQsIDIwKQplc3Q1OiBJbnZh bGlkIGZyZXEgMTg2MiwgaWdub3JlZC4KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAo MTMsIDIwKQplc3Q1OiBJbnZhbGlkIGZyZXEgMTcyOSwgaWdub3JlZC4KZXN0NTogSW52YWxpZCBp ZDE2IChzZXQsIGN1cikgPSAoMTIsIDIwKQplc3Q1OiBJbnZhbGlkIGZyZXEgMTU5NiwgaWdub3Jl ZC4KcDR0Y2M1OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTUKY3B1Njog PEFDUEkgQ1BVPiBvbiBhY3BpMAplc3Q2OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBD b250cm9sPiBvbiBjcHU2CmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE5LCAyMCkK ZXN0NjogSW52YWxpZCBmcmVxIDI1MjcsIGlnbm9yZWQuCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0 LCBjdXIpID0gKDE4LCAyMCkKZXN0NjogSW52YWxpZCBmcmVxIDIzOTQsIGlnbm9yZWQuCmVzdDY6 IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE3LCAyMCkKZXN0NjogSW52YWxpZCBmcmVxIDIy NjEsIGlnbm9yZWQuCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE2LCAyMCkKZXN0 NjogSW52YWxpZCBmcmVxIDIxMjgsIGlnbm9yZWQuCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBj dXIpID0gKDE1LCAyMCkKZXN0NjogSW52YWxpZCBmcmVxIDE5OTUsIGlnbm9yZWQuCmVzdDY6IElu dmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE0LCAyMCkKZXN0NjogSW52YWxpZCBmcmVxIDE4NjIs IGlnbm9yZWQuCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEzLCAyMCkKZXN0Njog SW52YWxpZCBmcmVxIDE3MjksIGlnbm9yZWQuCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIp ID0gKDEyLCAyMCkKZXN0NjogSW52YWxpZCBmcmVxIDE1OTYsIGlnbm9yZWQuCnA0dGNjNjogPENQ VSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHU2CmNwdTc6IDxBQ1BJIENQVT4gb24g YWNwaTAKZXN0NzogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1 Nwplc3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOSwgMjApCmVzdDc6IEludmFsaWQg ZnJlcSAyNTI3LCBpZ25vcmVkLgplc3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOCwg MjApCmVzdDc6IEludmFsaWQgZnJlcSAyMzk0LCBpZ25vcmVkLgplc3Q3OiBJbnZhbGlkIGlkMTYg KHNldCwgY3VyKSA9ICgxNywgMjApCmVzdDc6IEludmFsaWQgZnJlcSAyMjYxLCBpZ25vcmVkLgpl c3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNiwgMjApCmVzdDc6IEludmFsaWQgZnJl cSAyMTI4LCBpZ25vcmVkLgplc3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNSwgMjAp CmVzdDc6IEludmFsaWQgZnJlcSAxOTk1LCBpZ25vcmVkLgplc3Q3OiBJbnZhbGlkIGlkMTYgKHNl dCwgY3VyKSA9ICgxNCwgMjApCmVzdDc6IEludmFsaWQgZnJlcSAxODYyLCBpZ25vcmVkLgplc3Q3 OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxMywgMjApCmVzdDc6IEludmFsaWQgZnJlcSAx NzI5LCBpZ25vcmVkLgplc3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxMiwgMjApCmVz dDc6IEludmFsaWQgZnJlcSAxNTk2LCBpZ25vcmVkLgpwNHRjYzc6IDxDUFUgRnJlcXVlbmN5IFRo ZXJtYWwgQ29udHJvbD4gb24gY3B1Nwp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZm CnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0 ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246 IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxl ZCBmZgpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTog VHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0 IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTog VHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0 IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTog VHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRlCmlzYV9wcm9iZV9j aGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzCnBtdGltZXIwIG9uIGlzYTAKc2M6IHNjMCBh bHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lw cGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6 IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4Yzg3 ZmYsMHhjODgwMC0weGNhN2ZmIHBucGlkIE9STTAwMDAgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29u c29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xl cywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2MgKHN5 c2NvbnMgdGVybWluYWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgz ZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYWR2MDogbm90IHByb2JlZCAoZGlzYWJs ZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3QgcHJvYmVkIChkaXNhYmxl ZCkKYXRhMCBhdCBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2IGlycSAxNCBvbiBpc2EwCmF0YTA6IHJl c2V0IHRwMSBtYXNrPTAwIG9zdGF0MD1mZiBvc3RhdDE9ZmYKaW9hcGljMDogcm91dGluZyBpbnRw aW4gMTQgKElTQSBJUlEgMTQpIHRvIHZlY3RvciA1NAphdGEwOiBbTVBTQUZFXQphdGEwOiBbSVRI UkVBRF0KYXRhMSBhdCBwb3J0IDB4MTcwLTB4MTc3LDB4Mzc2IGlycSAxNSBvbiBpc2EwCmF0YTE6 IHJlc2V0IHRwMSBtYXNrPTAwIG9zdGF0MD1mZiBvc3RhdDE9ZmYKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTUgKElTQSBJUlEgMTUpIHRvIHZlY3RvciA1NQphdGExOiBbTVBTQUZFXQphdGExOiBb SVRIUkVBRF0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAw eDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMApr YmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIGdlbmVyaWMgKDApLCBjb25maWc6MHgwLCBmbGFn czoweDNmMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIHZlY3Rv ciA1NgphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IGN1cnJl bnQgY29tbWFuZCBieXRlOjAwNjcKcHNtMDogZmFpbGVkIHRvIHJlc2V0IHRoZSBhdXggZGV2aWNl LgpidDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpjczA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpl ZDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpmZGMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4 M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKZmUwOiBub3QgcHJvYmVkIChkaXNh YmxlZCkKaWUwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKbGUwOiBub3QgcHJvYmVkIChkaXNhYmxl ZCkKcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBm YWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMApzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxl ZCkKc2lvMzogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNuMDogbm90IHByb2JlZCAoZGlzYWJsZWQp CnVhcnQwOiA8bnM4MjUwPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOC0weDNmZiBpcnEg NCBvbiBpc2EwCnVhcnQxOiA8bnM4MjUwPiBmYWlsZWQgdG8gcHJvYmUgb24gaXNhMAp2dDA6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmlj ZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuClJlZHVjaW5nIGtlcm4ubWF4dm5vZGVz IDEzMzU1MSAtPiAxMDAwMDAKcHJvY2ZzIHJlZ2lzdGVyZWQKbGFwaWM6IERpdmlzb3IgMiwgRnJl cXVlbmN5IDY2NjY5NTM5IGh6ClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyNjY2NzgxNTY4 IEh6IHF1YWxpdHkgLTEwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmxvMDog YnBmIGF0dGFjaGVkCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgphdGEwOiBpZGVudGlm eSBjaC0+ZGV2aWNlcz0wMDAwMDAwMAphdGExOiBpZGVudGlmeSBjaC0+ZGV2aWNlcz0wMDAwMDAw MAphdGEyOiBpZGVudGlmeSBjaC0+ZGV2aWNlcz0wMDAwMDAwMAphdGEzOmZpcmV3aXJlMDogMSBu b2RlcywgbWF4aG9wIDw9IDAsIGNhYmxlIElSTSA9IDAgKG1lKQpmaXJld2lyZTA6IGJ1cyBtYW5h Z2VyIDAgKG1lKQogaWRlbnRpZnkgY2gtPmRldmljZXM9MDAwMDAwMDEKYXRhMy1tYXN0ZXI6IHBp bz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTMzIGNhYmxlPTQwIHdpcmUKYWQ2OiA3NjMxOU1C IDxTZWFnYXRlIFNUMzgwODExMEFTIDJBQUE+IGF0IGF0YTMtbWFzdGVyIFNBVEEzMDAKYWQ2OiAx NTYzMDE0ODggc2VjdG9ycyBbMTU1MDYxQy8xNkgvNjNTXSAxNiBzZWN0b3JzL2ludGVycnVwdCAx IGRlcHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkNgphZDY6IEludGVsIGNoZWNrMSBmYWlsZWQK YWQ2OiBBZGFwdGVjIGNoZWNrMSBmYWlsZWQKYWQ2OiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFk NjogTFNJICh2MikgY2hlY2sxIGZhaWxlZAphZDY6IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAphdGE0 OiBpZGVudGlmeSBjaC0+ZGV2aWNlcz0wMDAwMDAwMAphdGE1OiBpZGVudGlmeSBjaC0+ZGV2aWNl cz0wMDAwMDAwMAphdGE2OiBpZGVudGlmeSBjaC0+ZGV2aWNlcz0wMDAwMDAwMApHRU9NOiBhZDZz MTogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwuCihwcm9iZTA6dHdhMDowOjA6MCk6IGVy cm9yIDIyCihwcm9iZTA6dHdhMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6dHdh MDowOjE6MCk6IGVycm9yIDIyCihwcm9iZTE6dHdhMDowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9y Cihwcm9iZTI6dHdhMDowOjI6MCk6IGVycm9yIDIyCihwcm9iZTI6dHdhMDowOjI6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTM6dHdhMDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6dHdhMDow OjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6dHdhMDowOjQ6MCk6IGVycm9yIDIyCihw cm9iZTQ6dHdhMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTU6dHdhMDowOjU6MCk6 IGVycm9yIDIyCihwcm9iZTU6dHdhMDowOjU6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTY6 dHdhMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6dHdhMDowOjY6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTc6dHdhMDowOjc6MCk6IGVycm9yIDIyCihwcm9iZTc6dHdhMDowOjc6MCk6IFVu cmV0cnlhYmxlIEVycm9yCihwcm9iZTg6dHdhMDowOjg6MCk6IGVycm9yIDIyCihwcm9iZTg6dHdh MDowOjg6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTk6dHdhMDowOjk6MCk6IGVycm9yIDIy Cihwcm9iZTk6dHdhMDowOjk6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTEwOnR3YTA6MDox MDowKTogZXJyb3IgMjIKKHByb2JlMTA6dHdhMDowOjEwOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoo cHJvYmUxMTp0d2EwOjA6MTE6MCk6IGVycm9yIDIyCihwcm9iZTExOnR3YTA6MDoxMTowKTogVW5y ZXRyeWFibGUgRXJyb3IKKHByb2JlMTI6dHdhMDowOjEyOjApOiBlcnJvciAyMgoocHJvYmUxMjp0 d2EwOjA6MTI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTEzOnR3YTA6MDoxMzowKTogZXJy b3IgMjIKKHByb2JlMTM6dHdhMDowOjEzOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxNDp0 d2EwOjA6MTQ6MCk6IGVycm9yIDIyCihwcm9iZTE0OnR3YTA6MDoxNDowKTogVW5yZXRyeWFibGUg RXJyb3IKKHByb2JlMTU6dHdhMDowOjE1OjApOiBlcnJvciAyMgoocHJvYmUxNTp0d2EwOjA6MTU6 MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE2OnR3YTA6MDoxNjowKTogZXJyb3IgMjIKKHBy b2JlMTY6dHdhMDowOjE2OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxNzp0d2EwOjA6MTc6 MCk6IGVycm9yIDIyCihwcm9iZTE3OnR3YTA6MDoxNzowKTogVW5yZXRyeWFibGUgRXJyb3IKKHBy b2JlMTg6dHdhMDowOjE4OjApOiBlcnJvciAyMgoocHJvYmUxODp0d2EwOjA6MTg6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTE5OnR3YTA6MDoxOTowKTogZXJyb3IgMjIKKHByb2JlMTk6dHdh MDowOjE5OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUyMDp0d2EwOjA6MjA6MCk6IGVycm9y IDIyCihwcm9iZTIwOnR3YTA6MDoyMDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjE6dHdh MDowOjIxOjApOiBlcnJvciAyMgoocHJvYmUyMTp0d2EwOjA6MjE6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTIyOnR3YTA6MDoyMjowKTogZXJyb3IgMjIKKHByb2JlMjI6dHdhMDowOjIyOjAp OiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUyMzp0d2EwOjA6MjM6MCk6IGVycm9yIDIyCihwcm9i ZTIzOnR3YTA6MDoyMzowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjQ6dHdhMDowOjI0OjAp OiBlcnJvciAyMgoocHJvYmUyNDp0d2EwOjA6MjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9i ZTI1OnR3YTA6MDoyNTowKTogZXJyb3IgMjIKKHByb2JlMjU6dHdhMDowOjI1OjApOiBVbnJldHJ5 YWJsZSBFcnJvcgoocHJvYmUyNjp0d2EwOjA6MjY6MCk6IGVycm9yIDIyCihwcm9iZTI2OnR3YTA6 MDoyNjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjc6dHdhMDowOjI3OjApOiBlcnJvciAy MgoocHJvYmUyNzp0d2EwOjA6Mjc6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI4OnR3YTA6 MDoyODowKTogZXJyb3IgMjIKKHByb2JlMjg6dHdhMDowOjI4OjApOiBVbnJldHJ5YWJsZSBFcnJv cgoocHJvYmUyOTp0d2EwOjA6Mjk6MCk6IGVycm9yIDIyCihwcm9iZTI5OnR3YTA6MDoyOTowKTog VW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMzA6dHdhMDowOjMwOjApOiBlcnJvciAyMgoocHJvYmUz MDp0d2EwOjA6MzA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTMxOnR3YTA6MDozMTowKTog ZXJyb3IgMjIKKHByb2JlMzE6dHdhMDowOjMxOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUw OnR3YTA6MDowOjApOiBlcnJvciAyMgoocHJvYmUwOnR3YTA6MDowOjApOiBVbnJldHJ5YWJsZSBF cnJvcgoocHJvYmUxOnR3YTA6MDoxOjApOiBlcnJvciAyMgoocHJvYmUxOnR3YTA6MDoxOjApOiBV bnJldHJ5YWJsZSBFcnJvcgoocHJvYmUyOnR3YTA6MDoyOjApOiBlcnJvciAyMgoocHJvYmUyOnR3 YTA6MDoyOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUzOnR3YTA6MDozOjApOiBlcnJvciAy MgoocHJvYmUzOnR3YTA6MDozOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU0OnR3YTA6MDo0 OjApOiBlcnJvciAyMgoocHJvYmU0OnR3YTA6MDo0OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJv YmU1OnR3YTA6MDo1OjApOiBlcnJvciAyMgoocHJvYmU1OnR3YTA6MDo1OjApOiBVbnJldHJ5YWJs ZSBFcnJvcgoocHJvYmU2OnR3YTA6MDo2OjApOiBlcnJvciAyMgoocHJvYmU2OnR3YTA6MDo2OjAp OiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU3OnR3YTA6MDo3OjApOiBlcnJvciAyMgoocHJvYmU3 OnR3YTA6MDo3OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU4OnR3YTA6MDo4OjApOiBlcnJv ciAyMgoocHJvYmU4OnR3YTA6MDo4OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU5OnR3YTA6 MDo5OjApOiBlcnJvciAyMgoocHJvYmU5OnR3YTA6MDo5OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoo cHJvYmUxMDp0d2EwOjA6MTA6MCk6IGVycm9yIDIyCihwcm9iZTEwOnR3YTA6MDoxMDowKTogVW5y ZXRyeWFibGUgRXJyb3IKKHByb2JlMTE6dHdhMDowOjExOjApOiBlcnJvciAyMgoocHJvYmUxMTp0 d2EwOjA6MTE6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTEyOnR3YTA6MDoxMjowKTogZXJy b3IgMjIKKHByb2JlMTI6dHdhMDowOjEyOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxMzp0 d2EwOjA6MTM6MCk6IGVycm9yIDIyCihwcm9iZTEzOnR3YTA6MDoxMzowKTogVW5yZXRyeWFibGUg RXJyb3IKKHByb2JlMTQ6dHdhMDowOjE0OjApOiBlcnJvciAyMgoocHJvYmUxNDp0d2EwOjA6MTQ6 MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE1OnR3YTA6MDoxNTowKTogZXJyb3IgMjIKKHBy b2JlMTU6dHdhMDowOjE1OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxNjp0d2EwOjA6MTY6 MCk6IGVycm9yIDIyCihwcm9iZTE2OnR3YTA6MDoxNjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHBy b2JlMTc6dHdhMDowOjE3OjApOiBlcnJvciAyMgoocHJvYmUxNzp0d2EwOjA6MTc6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTE4OnR3YTA6MDoxODowKTogZXJyb3IgMjIKKHByb2JlMTg6dHdh MDowOjE4OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxOTp0d2EwOjA6MTk6MCk6IGVycm9y IDIyCihwcm9iZTE5OnR3YTA6MDoxOTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjA6dHdh MDowOjIwOjApOiBlcnJvciAyMgoocHJvYmUyMDp0d2EwOjA6MjA6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTIxOnR3YTA6MDoyMTowKTogZXJyb3IgMjIKKHByb2JlMjE6dHdhMDowOjIxOjAp OiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUyMjp0d2EwOjA6MjI6MCk6IGVycm9yIDIyCihwcm9i ZTIyOnR3YTA6MDoyMjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjM6dHdhMDowOjIzOjAp OiBlcnJvciAyMgoocHJvYmUyMzp0d2EwOjA6MjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9i ZTI0OnR3YTA6MDoyNDowKTogZXJyb3IgMjIKKHByb2JlMjQ6dHdhMDowOjI0OjApOiBVbnJldHJ5 YWJsZSBFcnJvcgoocHJvYmUyNTp0d2EwOjA6MjU6MCk6IGVycm9yIDIyCihwcm9iZTI1OnR3YTA6 MDoyNTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjY6dHdhMDowOjI2OjApOiBlcnJvciAy MgoocHJvYmUyNjp0d2EwOjA6MjY6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI3OnR3YTA6 MDoyNzowKTogZXJyb3IgMjIKKHByb2JlMjc6dHdhMDowOjI3OjApOiBVbnJldHJ5YWJsZSBFcnJv cgoocHJvYmUyODp0d2EwOjA6Mjg6MCk6IGVycm9yIDIyCihwcm9iZTI4OnR3YTA6MDoyODowKTog VW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjk6dHdhMDowOjI5OjApOiBlcnJvciAyMgoocHJvYmUy OTp0d2EwOjA6Mjk6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTMwOnR3YTA6MDozMDowKTog ZXJyb3IgMjIKKHByb2JlMzA6dHdhMDowOjMwOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUz MTp0d2EwOjA6MzE6MCk6IGVycm9yIDIyCihwcm9iZTMxOnR3YTA6MDozMTowKTogVW5yZXRyeWFi bGUgRXJyb3IKQVRBIFBzZXVkb1JBSUQgbG9hZGVkCmxhcGljNDogRm9yY2luZyBMSU5UMSB0byBl ZGdlIHRyaWdnZXIKU01QOiBBUCBDUFUgIzQgTGF1bmNoZWQhCmNwdTQgQVA6CiAgICAgSUQ6IDB4 MDQwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZm ZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBT VlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6 IDB4MDAwMTAwMDAgcGNtOiAweDAwMDAwNDAwCmxhcGljMTogRm9yY2luZyBMSU5UMSB0byBlZGdl IHRyaWdnZXIKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCmNwdTEgQVA6CiAgICAgSUQ6IDB4MDEw MDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgog IGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6 IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4 MDAwMTAwMDAgcGNtOiAweDAwMDAwNDAwCmxhcGljNTogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRy aWdnZXIKU01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCmNwdTUgQVA6CiAgICAgSUQ6IDB4MDUwMDAw MDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxp bnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4 MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAw MTAwMDAgcGNtOiAweDAwMDAwNDAwCmxhcGljNzogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRyaWdn ZXIKU01QOiBBUCBDUFUgIzcgTGF1bmNoZWQhCmNwdTcgQVA6CiAgICAgSUQ6IDB4MDcwMDAwMDAg ICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQw OiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAw MDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAw MDAgcGNtOiAweDAwMDAwNDAwCmxhcGljNjogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRyaWdnZXIK U01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhCmNwdTYgQVA6CiAgICAgSUQ6IDB4MDYwMDAwMDAgICBW RVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAw eDAwMDEwNzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAx ZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAg cGNtOiAweDAwMDAwNDAwCmxhcGljMjogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRyaWdnZXIKU01Q OiBBUCBDUFUgIzIgTGF1bmNoZWQhCmNwdTIgQVA6CiAgICAgSUQ6IDB4MDIwMDAwMDAgICBWRVI6 IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAw MDEwNzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYK ICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNt OiAweDAwMDAwNDAwCmxhcGljMzogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRyaWdnZXIKU01QOiBB UCBDUFUgIzMgTGF1bmNoZWQhCmNwdTMgQVA6CiAgICAgSUQ6IDB4MDMwMDAwMDAgICBWRVI6IDB4 MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEw NzAwIGxpbnQxOiAweDAwMDA4NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0 aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAw eDAwMDAwNDAwCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDEgdG8gbG9jYWwgQVBJQyAwCmlv YXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDkgdG8gbG9jYWwgQVBJQyAyCmlvYXBpYzA6IEFzc2ln bmluZyBJU0EgSVJRIDE0IHRvIGxvY2FsIEFQSUMgNAppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElS USAxNSB0byBsb2NhbCBBUElDIDYKaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMTYgdG8gbG9j YWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE3IHRvIGxvY2FsIEFQSUMgMgpp b2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAxOCB0byBsb2NhbCBBUElDIDQKaW9hcGljMDogQXNz aWduaW5nIFBDSSBJUlEgMTkgdG8gbG9jYWwgQVBJQyA2Cm1zaTogQXNzaWduaW5nIE1TSSBJUlEg MjU2IHRvIGxvY2FsIEFQSUMgMApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBl Y3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rl di9hZDZzMWEKY3RfdG9fdHMoWzIwMDgtMTItMjMgMTU6NDg6MzFdKSA9IDEyMzAwNDczMTEuMDAw MDAwMDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0CmxvY2sgb3JkZXIgcmV2ZXJzYWw6 CiAxc3QgMHhjNTE1OTA0NCB1c2VyIG1hcCAodXNlciBtYXApIEAgL3Vzci9zcmMvc3lzL3ZtL3Zt X21hcC5jOjMxMTUKIDJuZCAweGM1NjBhYWQwIHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19zdWJyLmM6MjA3OQpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFw cGVyKGMwYWM3YTQ4LGM0ZWI0OTBjLGMwN2I0Yjk1LDQsYzBhYzJmYTMsLi4uKSBhdCBkYl90cmFj ZV9zZWxmX3dyYXBwZXIrMHgyNgprZGJfYmFja3RyYWNlKDQsYzBhYzJmYTMsYzUxMTA3MjgsYzUx MTUzODgsYzRlYjQ5NjgsLi4uKSBhdCBrZGJfYmFja3RyYWNlKzB4MjkKX3dpdG5lc3NfZGVidWdn ZXIoYzBhY2E3MzIsYzU2MGFhZDAsYzBhYmUwMjYsYzUxMTUzODgsYzBhZDE0NGIsLi4uKSBhdCBf d2l0bmVzc19kZWJ1Z2dlcisweDI1CndpdG5lc3NfY2hlY2tvcmRlcihjNTYwYWFkMCwxLGMwYWQx NDRiLDgxZiwwLC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODM5Cl9fbG9ja21ncl9hcmdz KGM1NjBhYWQwLDIwMDUwMSxjNTYwYWFlYywwLDAsLi4uKSBhdCBfX2xvY2ttZ3JfYXJncysweDIz NwpmZnNfbG9jayhjNGViNGE3OCxjMDdiNDkzYixjMGFlN2Q0NiwyMDA1MDEsYzU2MGFhNzgsLi4u KSBhdCBmZnNfbG9jaysweDhhClZPUF9MT0NLMV9BUFYoYzBiYjM2ZTAsYzRlYjRhNzgsYzUxNTVl MjQsYzBiYzc1NDAsYzU2MGFhNzgsLi4uKSBhdCBWT1BfTE9DSzFfQVBWKzB4YTUKX3ZuX2xvY2so YzU2MGFhNzgsMjAwNTAxLGMwYWQxNDRiLDgxZiw0LC4uLikgYXQgX3ZuX2xvY2srMHg1ZQp2Z2V0 KGM1NjBhYTc4LDIwMDUwMSxjNTE1NWQ4MCw0YjQsMCwuLi4pIGF0IHZnZXQrMHhjOQp2bm9kZV9w YWdlcl9sb2NrKGMxNDc3ZDE0LDAsYzBhZTUzMjcsMTI3LGM0ZWI0YzE4LC4uLikgYXQgdm5vZGVf cGFnZXJfbG9jaysweDFlMAp2bV9mYXVsdChjNTE1OTAwMCw4MGRiMDAwLDIsOCw4MGRiNzgwLC4u LikgYXQgdm1fZmF1bHQrMHgxZGYKdHJhcF9wZmF1bHQoNSwwLGMwYWY0ZDU1LDJlNyxjNTE1M2Qz NCwuLi4pIGF0IHRyYXBfcGZhdWx0KzB4MTE4CnRyYXAoYzRlYjRkMzgpIGF0IHRyYXArMHgyODkK Y2FsbHRyYXAoKSBhdCBjYWxsdHJhcCsweDYKLS0tIHRyYXAgMHhjLCBlaXAgPSAweDgwNDgwZTUs IGVzcCA9IDB4YmZiZmVlZjAsIGVicCA9IDB4YmZiZmVmMTAgLS0tCmVtMDogTGluayBpcyB1cCAx MDAgTWJwcyBGdWxsIER1cGxleApiZ2UwOiBsaW5rIFVQCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAx c3QgMHhkOTEwMjkzMCBidWZ3YWl0IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19i aW8uYzoyNDQzCiAybmQgMHhjNTVmZGMwMCBkaXJoYXNoIChkaXJoYXNoKSBAIC91c3Ivc3JjL3N5 cy91ZnMvdWZzL3Vmc19kaXJoYXNoLmM6MjYzCktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFj ZV9zZWxmX3dyYXBwZXIoYzBhYzdhNDgsZTdhYzM4N2MsYzA3YjRiOTUsNCxjMGFjMmZhMywuLi4p IGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDI2CmtkYl9iYWNrdHJhY2UoNCxjMGFjMmZhMyxj NTExMjZkOCxjNTExNTNmMCxlN2FjMzhkOCwuLi4pIGF0IGtkYl9iYWNrdHJhY2UrMHgyOQpfd2l0 bmVzc19kZWJ1Z2dlcihjMGFjYTczMixjNTVmZGMwMCxjMGFlM2UxMSxjNTExNTNmMCxjMGFlM2Fh YSwuLi4pIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MjUKd2l0bmVzc19jaGVja29yZGVyKGM1NWZk YzAwLDksYzBhZTNhYWEsMTA3LDAsLi4uKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MzkKX3N4 X3hsb2NrKGM1NWZkYzAwLDAsYzBhZTNhYWEsMTA3LGM1N2Y0MjU4LC4uLikgYXQgX3N4X3hsb2Nr KzB4ODUKdWZzZGlyaGFzaF9hY3F1aXJlKGQ5MTAyOGQwLGU3YWMzYTIwLDE1MCxkOThiYmFjOCxl N2FjMzlhOCwuLi4pIGF0IHVmc2Rpcmhhc2hfYWNxdWlyZSsweDM1CnVmc2Rpcmhhc2hfYWRkKGM1 N2Y0MjU4LGU3YWMzYTIwLGFjOCxlN2FjMzk5NCxlN2FjMzk5OCwuLi4pIGF0IHVmc2Rpcmhhc2hf YWRkKzB4MTMKdWZzX2RpcmVudGVyKGM1OTg0YTc4LGM1YjYyMjE4LGU3YWMzYTIwLGU3YWMzYzA0 LGQ5MTAyY2MwLC4uLikgYXQgdWZzX2RpcmVudGVyKzB4NzI5CnVmc19ta2RpcihlN2FjM2MyOCxl N2FjM2MyOCwwLGU3YWMzYzI4LGU3YWMzYmQ4LC4uLikgYXQgdWZzX21rZGlyKzB4OTBlClZPUF9N S0RJUl9BUFYoYzBiYjM2ZTAsZTdhYzNjMjgsZWI2LGViNCwwLC4uLikgYXQgVk9QX01LRElSX0FQ VisweGE1Cmtlcm5fbWtkaXJhdChjNTgwMzZjMCxmZmZmZmY5YyxiZmJmZWY2NiwwLDFmZiwuLi4p IGF0IGtlcm5fbWtkaXJhdCsweDI3OAprZXJuX21rZGlyKGM1ODAzNmMwLGJmYmZlZjY2LDAsMWZm LGU3YWMzZDJjLC4uLikgYXQga2Vybl9ta2RpcisweDJlCm1rZGlyKGM1ODAzNmMwLGU3YWMzY2Y4 LDgsYzBhY2FmZTAsYzBiOTE4MDAsLi4uKSBhdCBta2RpcisweDI5CnN5c2NhbGwoZTdhYzNkMzgp IGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwr MHgyMAotLS0gc3lzY2FsbCAoMTM2LCBGcmVlQlNEIEVMRjMyLCBta2RpciksIGVpcCA9IDB4Mjgx NWI4OTMsIGVzcCA9IDB4YmZiZmVkYWMsIGVicCA9IDB4YmZiZmVlNzggLS0tCgoKMFtjdXJyZW50 XSMgcGNpY29uZiAtbHZjCmhvc3RiMEBwY2kwOjA6MDowOiAgICAgIGNsYXNzPTB4MDYwMDAwIGNh cmQ9MHg0ZjUzODA4NiBjaGlwPTB4MzQwNTgwODYgcmV2PTB4MTIgaGRyPTB4MDAKICAgIHZlbmRv ciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gSE9TVC1QQ0kKICAgIGNhcCAwMFs0MF0gPSB1bmtub3duCnBjaWIxQHBjaTA6 MDoxOjA6ICAgICAgIGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHg0ZjUzODA4NiBjaGlwPTB4MzQwODgw ODYgcmV2PTB4MTIgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n CiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQogICAgY2Fw IDBkWzQwXSA9IFBDSSBCcmlkZ2UgY2FyZD0weDRmNTM4MDg2CiAgICBjYXAgMDVbNjBdID0gTVNJ IHN1cHBvcnRzIDIgbWVzc2FnZXMsIHZlY3RvciBtYXNrcyAKICAgIGNhcCAxMFs5MF0gPSBQQ0kt RXhwcmVzcyAyIHJvb3QgcG9ydAogICAgY2FwIDAxW2UwXSA9IHBvd2Vyc3BlYyAzICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMApwY2liMkBwY2kwOjA6MzowOiAgICAgICBjbGFzcz0weDA2MDQw MCBjYXJkPTB4NGY1MzgwODYgY2hpcD0weDM0MGE4MDg2IHJldj0weDEyIGhkcj0weDAxCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKICAgIGNhcCAwZFs0MF0gPSBQQ0kgQnJpZGdlIGNhcmQ9 MHg0ZjUzODA4NgogICAgY2FwIDA1WzYwXSA9IE1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0 b3IgbWFza3MgCiAgICBjYXAgMTBbOTBdID0gUENJLUV4cHJlc3MgMiByb290IHBvcnQKICAgIGNh cCAwMVtlMF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKcGNpYjNA cGNpMDowOjc6MDogICAgICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHgz NDBlODA4NiByZXY9MHgxMiBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCiAg ICBjYXAgMGRbNDBdID0gUENJIEJyaWRnZSBjYXJkPTB4NGY1MzgwODYKICAgIGNhcCAwNVs2MF0g PSBNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgdmVjdG9yIG1hc2tzIAogICAgY2FwIDEwWzkwXSA9 IFBDSS1FeHByZXNzIDIgcm9vdCBwb3J0CiAgICBjYXAgMDFbZTBdID0gcG93ZXJzcGVjIDMgIHN1 cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCm5vbmUwQHBjaTA6MDoxNjowOiAgICAgIGNsYXNzPTB4 MDgwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MzQyNTgwODYgcmV2PTB4MTIgaGRyPTB4MDAK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gYmFz ZSBwZXJpcGhlcmFsCiAgICBzdWJjbGFzcyAgID0gaW50ZXJydXB0IGNvbnRyb2xsZXIKICAgIGNh cCAwOVs1MF0gPSB2ZW5kb3IgKGxlbmd0aCAyNTUpIEludGVsIGNhcCAxNSB2ZXJzaW9uIDAKbm9u ZTFAcGNpMDowOjE2OjE6ICAgICAgY2xhc3M9MHgwODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgzNDI2ODA4NiByZXY9MHgxMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwKICAgIHN1YmNsYXNzICAg PSBpbnRlcnJ1cHQgY29udHJvbGxlcgpub25lMkBwY2kwOjA6MjA6MDogICAgICBjbGFzcz0weDA4 MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDM0MmU4MDg2IHJldj0weDEyIGhkcj0weDAwCiAg ICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgICA9IGJhc2Ug cGVyaXBoZXJhbAogICAgc3ViY2xhc3MgICA9IGludGVycnVwdCBjb250cm9sbGVyCiAgICBjYXAg MTBbNDBdID0gUENJLUV4cHJlc3MgMiB0eXBlIDAKbm9uZTNAcGNpMDowOjIwOjE6ICAgICAgY2xh c3M9MHgwODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDIyODA4NiByZXY9MHgxMiBoZHI9 MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAg PSBiYXNlIHBlcmlwaGVyYWwKICAgIHN1YmNsYXNzICAgPSBpbnRlcnJ1cHQgY29udHJvbGxlcgog ICAgY2FwIDEwWzQwXSA9IFBDSS1FeHByZXNzIDIgdHlwZSAwCm5vbmU0QHBjaTA6MDoyMDoyOiAg ICAgIGNsYXNzPTB4MDgwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MzQyMzgwODYgcmV2PTB4 MTIgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFz cyAgICAgID0gYmFzZSBwZXJpcGhlcmFsCiAgICBzdWJjbGFzcyAgID0gaW50ZXJydXB0IGNvbnRy b2xsZXIKICAgIGNhcCAxMFs0MF0gPSBQQ0ktRXhwcmVzcyAyIHR5cGUgMApub25lNUBwY2kwOjA6 MjA6MzogICAgICBjbGFzcz0weDA4MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDM0Mzg4MDg2 IHJldj0weDEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwog ICAgY2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAogICAgc3ViY2xhc3MgICA9IGludGVycnVw dCBjb250cm9sbGVyCmVtMEBwY2kwOjA6MjU6MDogICAgICAgIGNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHgwMDAwODA4NiBjaGlwPTB4MTBjYzgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gbmV0d29yawogICAgc3Vi Y2xhc3MgICA9IGV0aGVybmV0CiAgICBjYXAgMDFbYzhdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCiAgICBjYXAgMDVbZDBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2Fn ZSwgNjQgYml0IGVuYWJsZWQgd2l0aCAxIG1lc3NhZ2UKbm9uZTZAcGNpMDowOjI2OjA6ICAgICAg Y2xhc3M9MHgwYzAzMDAgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHgzYTM3ODA4NiByZXY9MHgwMCBo ZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAg ICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCiAgICBjYXAgMTNbNTBdID0gdW5r bm93bgpub25lN0BwY2kwOjA6MjY6MTogICAgICBjbGFzcz0weDBjMDMwMCBjYXJkPTB4NGY1Mzgw ODYgY2hpcD0weDNhMzg4MDg2IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0lu dGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNz ICAgPSBVU0IKICAgIGNhcCAxM1s1MF0gPSB1bmtub3duCm5vbmU4QHBjaTA6MDoyNjoyOiAgICAg IGNsYXNzPTB4MGMwMzAwIGNhcmQ9MHg0ZjUzODA4NiBjaGlwPTB4M2EzOTgwODYgcmV2PTB4MDAg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAg ICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IFVTQgogICAgY2FwIDEzWzUwXSA9IHVu a25vd24Kbm9uZTlAcGNpMDowOjI2Ojc6ICAgICAgY2xhc3M9MHgwYzAzMjAgY2FyZD0weDRmNTM4 MDg2IGNoaXA9MHgzYTNjODA4NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJ bnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFz cyAgID0gVVNCCiAgICBjYXAgMDFbNTBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCiAgICBjYXAgMGFbNThdID0gRUhDSSBEZWJ1ZyBQb3J0IGF0IG9mZnNldCAweGEw IGluIG1hcCAweDE0Cm5vbmUxMEBwY2kwOjA6Mjc6MDogICAgIGNsYXNzPTB4MDQwMzAwIGNhcmQ9 MHgwMDIyODA4NiBjaGlwPTB4M2EzZTgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gbXVsdGltZWRpYQogICAg c3ViY2xhc3MgICA9IEhEQQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMyAgY3VycmVudCBEMAogICAgY2FwIDA1WzYwXSA9IE1TSSBzdXBwb3J0cyAxIG1lc3NhZ2Us IDY0IGJpdCAKICAgIGNhcCAxMFs3MF0gPSBQQ0ktRXhwcmVzcyAxIHR5cGUgMApwY2liNEBwY2kw OjA6Mjg6MDogICAgICBjbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDNhNDA4 MDg2IHJldj0weDAwIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9u JwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKICAgIGNh cCAxMFs0MF0gPSBQQ0ktRXhwcmVzcyAxIHJvb3QgcG9ydAogICAgY2FwIDA1WzgwXSA9IE1TSSBz dXBwb3J0cyAxIG1lc3NhZ2UgCiAgICBjYXAgMGRbOTBdID0gUENJIEJyaWRnZSBjYXJkPTB4MDAw MDAwMDAKICAgIGNhcCAwMVthMF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDAKcGNpYjVAcGNpMDowOjI4OjE6ICAgICAgY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAw MDAwIGNoaXA9MHgzYTQyODA4NiByZXY9MHgwMCBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdJ bnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAg PSBQQ0ktUENJCiAgICBjYXAgMTBbNDBdID0gUENJLUV4cHJlc3MgMSByb290IHBvcnQKICAgIGNh cCAwNVs4MF0gPSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdlIAogICAgY2FwIDBkWzkwXSA9IFBDSSBC cmlkZ2UgY2FyZD0weDAwMDAwMDAwCiAgICBjYXAgMDFbYTBdID0gcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwCnBjaWI2QHBjaTA6MDoyODo0OiAgICAgIGNsYXNzPTB4MDYw NDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4M2E0ODgwODYgcmV2PTB4MDAgaGRyPTB4MDEKICAg IHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gYnJpZGdl CiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQogICAgY2FwIDEwWzQwXSA9IFBDSS1FeHByZXNzIDEg cm9vdCBwb3J0CiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSAKICAgIGNh cCAwZFs5MF0gPSBQQ0kgQnJpZGdlIGNhcmQ9MHgwMDAwMDAwMAogICAgY2FwIDAxW2EwXSA9IHBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApub25lMTFAcGNpMDowOjI5OjA6 ICAgICBjbGFzcz0weDBjMDMwMCBjYXJkPTB4NGY1MzgwODYgY2hpcD0weDNhMzQ4MDg2IHJldj0w eDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xh c3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKICAgIGNhcCAxM1s1MF0g PSB1bmtub3duCm5vbmUxMkBwY2kwOjA6Mjk6MTogICAgIGNsYXNzPTB4MGMwMzAwIGNhcmQ9MHg0 ZjUzODA4NiBjaGlwPTB4M2EzNTgwODYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAg PSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgogICAgY2FwIDEzWzUwXSA9IHVua25vd24Kbm9uZTEzQHBjaTA6MDoyOToy OiAgICAgY2xhc3M9MHgwYzAzMDAgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHgzYTM2ODA4NiByZXY9 MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNs YXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCiAgICBjYXAgMTNbNTBd ID0gdW5rbm93bgpub25lMTRAcGNpMDowOjI5Ojc6ICAgICBjbGFzcz0weDBjMDMyMCBjYXJkPTB4 NGY1MzgwODYgY2hpcD0weDNhM2E4MDg2IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAg ID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1 YmNsYXNzICAgPSBVU0IKICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKICAgIGNhcCAwYVs1OF0gPSBFSENJIERlYnVnIFBvcnQgYXQgb2Zmc2V0 IDB4YTAgaW4gbWFwIDB4MTQKcGNpYjdAcGNpMDowOjMwOjA6ICAgICAgY2xhc3M9MHgwNjA0MDEg Y2FyZD0weDRmNTM4MDg2IGNoaXA9MHgyNDRlODA4NiByZXY9MHg5MCBoZHI9MHgwMQogICAgdmVu ZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDEgRmFt aWx5IChJQ0gyLzMvNC80LzUvNS82LzcvOC85LDYzeHhFU0IpIEh1YiBJbnRlcmZhY2UgdG8gUENJ IEJyaWRnZScKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJ CiAgICBjYXAgMGRbNTBdID0gUENJIEJyaWRnZSBjYXJkPTB4NGY1MzgwODYKaXNhYjBAcGNpMDow OjMxOjA6ICAgICAgY2xhc3M9MHgwNjAxMDAgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHgzYTE2ODA4 NiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCiAgICBjYXAg MDlbZTBdID0gdmVuZG9yIChsZW5ndGggMTIpIEludGVsIGNhcCAxIHZlcnNpb24gMAogICAgICAg ICAgICAgICAgIGZlYXR1cmVzOiBTQVRBIFJBSUQtNSwgNCBQQ0ktZSB4MSBzbG90cwphdGFwY2kx QHBjaTA6MDozMToyOiAgICBjbGFzcz0weDAxMDE4ZiBjYXJkPTB4NGY1MzgwODYgY2hpcD0weDNh MjA4MDg2IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0 aW9uJwogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IEFUQQog ICAgY2FwIDAxWzcwXSA9IHBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAog ICAgY2FwIDEzW2IwXSA9IHVua25vd24Kbm9uZTE1QHBjaTA6MDozMTozOiAgICAgY2xhc3M9MHgw YzA1MDAgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHgzYTMwODA4NiByZXY9MHgwMCBoZHI9MHgwMAog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyAgID0gU01CdXMKYXRhcGNpMkBwY2kwOjA6MzE6NTogICAgY2xh c3M9MHgwMTAxODUgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHgzYTI2ODA4NiByZXY9MHgwMCBoZHI9 MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAg PSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzICAgPSBBVEEKICAgIGNhcCAwMVs3MF0gPSBwb3dl cnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKICAgIGNhcCAxM1tiMF0gPSB1bmtu b3duCnR3YTBAcGNpMDoyOjA6MDogICAgICAgIGNsYXNzPTB4MDEwNDAwIGNhcmQ9MHgxMDA0MTNj MSBjaGlwPTB4MTAwNDEzYzEgcmV2PTB4MDEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnM3dh cmUgSW5jLicKICAgIGRldmljZSAgICAgPSAnOTY1MFNFIFNlcmllcyBQQ0ktRXhwcmVzcyBTQVRB MiBSYWlkIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJj bGFzcyAgID0gUkFJRAogICAgY2FwIDAxWzQwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMAogICAgY2FwIDA1WzUwXSA9IE1TSSBzdXBwb3J0cyAzMiBtZXNz YWdlcywgNjQgYml0IAogICAgY2FwIDEwWzcwXSA9IFBDSS1FeHByZXNzIDEgbGVnYWN5IGVuZHBv aW50CmJnZTBAcGNpMDo1OjA6MDogICAgICAgIGNsYXNzPTB4MDIwMDAwIGNhcmQ9MHgxNjc3MTRl NCBjaGlwPTB4MTY3NzE0ZTQgcmV2PTB4MDEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQnJv YWRjb20gQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ0JDTTU3NTBBMSBOZXRYdHJlbWUg R2lnYWJpdCBFdGhlcm5ldCBQQ0kgRXhwcmVzcycKICAgIGNsYXNzICAgICAgPSBuZXR3b3JrCiAg ICBzdWJjbGFzcyAgID0gZXRoZXJuZXQKICAgIGNhcCAwMVs0OF0gPSBwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKICAgIGNhcCAwM1s1MF0gPSBWUEQKICAgIGNhcCAwNVs1 OF0gPSBNU0kgc3VwcG9ydHMgOCBtZXNzYWdlcywgNjQgYml0IAogICAgY2FwIDEwW2QwXSA9IFBD SS1FeHByZXNzIDEgZW5kcG9pbnQKYXRhcGNpMEBwY2kwOjY6MDowOiAgICAgY2xhc3M9MHgwMTAx OGYgY2FyZD0weDRmNTM4MDg2IGNoaXA9MHg2MTIxMTFhYiByZXY9MHhiMiBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdNYXJ2ZWxsIFNlbWljb25kdWN0b3IgKFdhczogR2FsaWxlbyBUZWNobm9s b2d5IEx0ZCknCiAgICBkZXZpY2UgICAgID0gJzYxMjEgU0FUQTIgQ29udHJvbGxlcicKICAgIGNs YXNzICAgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzICAgPSBBVEEKICAgIGNhcCAwMVs0 OF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDMgIGN1cnJlbnQgRDAKICAgIGNhcCAw NVs1MF0gPSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdlIAogICAgY2FwIDEwW2UwXSA9IFBDSS1FeHBy ZXNzIDEgbGVnYWN5IGVuZHBvaW50CnZnYXBjaTBAcGNpMDo3OjI6MDogICAgIGNsYXNzPTB4MDMw MDAwIGNhcmQ9MHgwMDM2MTIxYSBjaGlwPTB4MDAwNTEyMWEgcmV2PTB4MDEgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnM2RmeCBJbnRlcmFjdGl2ZSBJbmMnCiAgICBkZXZpY2UgICAgID0gJ1Zv b2RvbzMgQWxsIFZvb2RvbzMgY2hpcHMsIDMwMDAnCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQog ICAgc3ViY2xhc3MgICA9IFZHQQogICAgY2FwIDAxWzYwXSA9IHBvd2Vyc3BlYyAxICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMApmd29oY2kwQHBjaTA6NzozOjA6ICAgICBjbGFzcz0weDBjMDAx MCBjYXJkPTB4NGY1MzgwODYgY2hpcD0weDgwMjMxMDRjIHJldj0weDAwIGhkcj0weDAwCiAgICB2 ZW5kb3IgICAgID0gJ1RleGFzIEluc3RydW1lbnRzIChUSSknCiAgICBkZXZpY2UgICAgID0gJ1RT QjQzQUIyMS9BIElFRUUxMzk0YS0yMDAwIE9IQ0kgUEhZL0xpbmstTGF5ZXIgQ3RybHInCiAgICBj bGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IEZpcmVXaXJlCiAgICBjYXAg MDFbNDRdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCjBb Y3VycmVudF0jIAo= --=====================_493074562==_-- From owner-freebsd-performance@FreeBSD.ORG Wed Dec 24 03:20:51 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D6B61065674; Wed, 24 Dec 2008 03:20:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 466498FC19; Wed, 24 Dec 2008 03:20:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBO3KoQ8011712; Tue, 23 Dec 2008 22:20:50 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBO3KoEi033856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 22:20:50 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812240320.mBO3KoEi033856@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Dec 2008 22:20:49 -0500 To: Ivan Voras , freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 03:20:51 -0000 At 11:20 AM 12/23/2008, Ivan Voras wrote: >I just thought of another thing - can you boot an 8-CURRENT kernel >on the machine and report the value of kern.sched.topology_spec >sysctl? This is to verify how the ULE sees the HTT topology of the CPUs. And buildworld from current 4,8 and 10 3287.727u 973.504s 21:18.88 333.1% -4100+2075k 28490+5472io 10433pf+0w 3511.547u 1473.695s 15:30.77 535.6% -2668+2067k 1604+5381io 8741pf+0w 3576.281u 1546.722s 15:38.02 546.1% -2431+2068k 1570+5448io 8711pf+0w ---Mike From owner-freebsd-performance@FreeBSD.ORG Wed Dec 24 15:02:45 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546761065676 for ; Wed, 24 Dec 2008 15:02:45 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id B6F078FC18 for ; Wed, 24 Dec 2008 15:02:44 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by bwz12 with SMTP id 12so8703395bwz.19 for ; Wed, 24 Dec 2008 07:02:43 -0800 (PST) Received: by 10.181.30.10 with SMTP id h10mr3167709bkj.200.1230130963357; Wed, 24 Dec 2008 07:02:43 -0800 (PST) Received: by 10.181.20.7 with HTTP; Wed, 24 Dec 2008 07:02:39 -0800 (PST) Message-ID: <9bbcef730812240702t6fd2f9f8wcdda075f70517102@mail.gmail.com> Date: Wed, 24 Dec 2008 16:02:39 +0100 From: ivoras@freebsd.org To: "Mike Tancsa" In-Reply-To: <200812240320.mBO3KoEi033856@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> <200812240320.mBO3KoEi033856@lava.sentex.ca> Cc: freebsd-performance@freebsd.org Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 15:02:45 -0000 On 24/12/2008, Mike Tancsa wrote: > At 11:20 AM 12/23/2008, Ivan Voras wrote: > >>I just thought of another thing - can you boot an 8-CURRENT kernel >>on the machine and report the value of kern.sched.topology_spec >>sysctl? This is to verify how the ULE sees the HTT topology of the CPUs. > > > And buildworld from current > > 4,8 and 10 > > 3287.727u 973.504s 21:18.88 333.1% -4100+2075k 28490+5472io 10433pf+0w > 3511.547u 1473.695s 15:30.77 535.6% -2668+2067k 1604+5381io 8741pf+0w > 3576.281u 1546.722s 15:38.02 546.1% -2431+2068k 1570+5448io 8711pf+0w > Comparing to your original numbers, it looks like you might have some debugging enabled there: the original 7.x results went from 13:57 to 11:32, this goes from 21:18 to 15:30. I don't think the world is that much larger in -CURRENT. From owner-freebsd-performance@FreeBSD.ORG Wed Dec 24 15:07:37 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F501065677; Wed, 24 Dec 2008 15:07:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EFC928FC1D; Wed, 24 Dec 2008 15:07:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBOF7aga044226; Wed, 24 Dec 2008 10:07:36 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBOF7ZaG036966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2008 10:07:35 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812241507.mBOF7ZaG036966@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Dec 2008 10:07:35 -0500 To: ivoras@freebsd.org From: Mike Tancsa In-Reply-To: <9bbcef730812240702t6fd2f9f8wcdda075f70517102@mail.gmail.co m> References: <200812192214.mBJMEj2Q009511@lava.sentex.ca> <200812240320.mBO3KoEi033856@lava.sentex.ca> <9bbcef730812240702t6fd2f9f8wcdda075f70517102@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-performance@freebsd.org Subject: Re: intel i7 and Hyperthreading X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 15:07:37 -0000 At 10:02 AM 12/24/2008, ivoras@freebsd.org wrote: >Comparing to your original numbers, it looks like you might have some >debugging enabled there: the original 7.x results went from 13:57 to Yes, its a regular kernel and things like malloc are the default and from the dmesg WARNING: WITNESS option enabled, expect reduced performance. The buildworld times were more to compare -j4 vs -j8 on HEAD to see if there are similar differences. ---Mike