From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0091.outbound.protection.outlook.com [157.56.112.91]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 074C821F5B1 for ; Mon, 7 Dec 2015 04:24:43 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=kevin@darbyshire-bryant.me.uk; Received: from [IPv6:2001:470:183f:da2b::632f:a7da] (2001:470:183f:da2b::632f:a7da) by DB5PR07MB0936.eurprd07.prod.outlook.com (10.161.200.143) with Microsoft SMTP Server (TLS) id 15.1.337.19; Mon, 7 Dec 2015 12:24:38 +0000 To: References: <6F86FBB0-AA69-44F3-82D0-31465906974D@gmx.de> From: Kevin Darbyshire-Bryant X-Enigmail-Draft-Status: N1110 Message-ID: <56657A82.2080601@darbyshire-bryant.me.uk> Date: Mon, 7 Dec 2015 12:24:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <6F86FBB0-AA69-44F3-82D0-31465906974D@gmx.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060004010601080201040209" X-Originating-IP: [2001:470:183f:da2b::632f:a7da] X-ClientProxiedBy: DB4PR04CA0027.eurprd04.prod.outlook.com (25.160.41.37) To DB5PR07MB0936.eurprd07.prod.outlook.com (25.161.200.143) X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0936; 2:drSQ3JKkjwGOepz1IYknx0Y4u2n8t75pGP9IQcTnJnyscRQqkL2TnkOmhGaqG1RIHdYoWWf1CUqmmZkbLNTGZCjTMjQ9xPhvd7xctkbY21l7OXwTL6VOi+1kVUTomIEJKlcWUfLqpachU57xI0TgGw==; 3:UAyQ/8XTaMRLTAgJtPgNKT6/MWwZHQLzGJIxcdMTLOKwjVNexbuRuSF8RFFo2lX4sd98Ar0jKIdG0MpBb5IRH69AHpQd2RkhHYQRVnT5CuhoX1/PvHdUeqCx25ONvWUQ; 25:A3JgU0LoZSbiKHZmzBZMUklUdVAULjRqpYj9c1SThb/FsLobKKtg/mrwm+Iq98B6aFP3qUKRoh5mC23qZuZeQUOkCYGNVisruD8borD+n1QdQeac7in1SonrzjnOgjfTRmeRz1DvcnLf6lih6JEULYKAusj6dvk1Ti7GHyeZi3OOHVNPSU3wnEU2c/mIJ+nl1WOS7w9WH3ndUotp1eW9YLgxQMYn9q4rL2iN6nDnvYKi1L6+mn8WHqJmvZCO+PNPkzswnE6fRlAoccyjc77Z+w==; 4:1lm/cS64m1kKlh3LhmzePxpQ2GcXS8SbxI4BuEcxyHXuUYgmWt5QDAbKW+bEmDCnsgwNjua2V0AQLxtzcEYztNRfHJfvVAmAI6pdN7UdWvq3YW4MEAh4UJ/CKaHhZ+P5RGN4jAMdCsb+8VeRY81TJ+3zbP6GmTnvfX+GoU6vm3KqKdp67GvnTyTCJHAWb7NI1EDacXWvG83drMmm6TCeerKD06qroBWqdKxjFw8RgZe57O8O5pXUZ2GiXnGgq3HARqmKVZE7IeN12UHx0OeNCACt3ChE68JCtXSOhox1lgscTPg3GGs1DJaQAXfTjU9QlDcEbUbjIUVIxVUcipAju1kTBZVGbmew5mdiUET/0oLJszu2v9uCDeiCftrzaKL9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB0936; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DB5PR07MB0936; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB0936; X-Forefront-PRVS: 078310077C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(24454002)(479174004)(199003)(43234003)(99136001)(92566002)(105586002)(450100001)(65816999)(33656002)(87266999)(59896002)(74482002)(80316001)(2351001)(76176999)(65956001)(19580395003)(36756003)(19580405001)(65806001)(122386002)(5890100001)(50986999)(106356001)(54356999)(40100003)(5004730100002)(5001960100002)(83506001)(110136002)(107886002)(77096005)(86362001)(568964002)(586003)(1096002)(1706002)(6116002)(189998001)(64126003)(81156007)(101416001)(42186005)(512944002)(84326002)(2950100001)(4001350100001)(5008740100001)(87976001)(15975445007)(97736004)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0936; H:[IPv6:2001:470:183f:da2b::632f:a7da]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: darbyshire-bryant.me.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR07MB0936; 23:S6iYx50TqPeNsOD87EX3Dc3KpgHhItfPEb7tAhin2?= =?us-ascii?Q?25K+9+GEuRc/ZM+wPL91fDtvZ5T/LP0PFTos5CQtms5zVkzO+PCZu+hDhPRt?= =?us-ascii?Q?tRbA+3UXOWI4H+lt5rqMr/E6nO4hZwmxf2SCo8t57ez0rnoOWG8hJSXdFwCa?= =?us-ascii?Q?f8TCP3c1nz+vV1Iqll8o9aGuVDnpezUIt7QCU5lGNzFMIykqRw7tL1VkOJkq?= =?us-ascii?Q?O+nWbOV+H/G781/x10HPldEd8H9Z1QpGsNM3GbMqxM+DbV5lWkSQxh9HW0X7?= =?us-ascii?Q?r5tqg/CPeBQ7HuE8oK+8IdSvflZX1sLv2Y6u4vWoLFISOjXL54rUw0PM8MLg?= =?us-ascii?Q?coI55oeQT/oR7egEzvcDArLk+CKHHxgEE7UFIHeADyAnRm5kpuSI9G8fwKd+?= =?us-ascii?Q?wNLzZ7qIow+871vM0xWsqvsdgemOMB1ziDfNhRDkh9pzt4PYFYTGKkMdbF1d?= =?us-ascii?Q?A4BhDEOaNHY5pCC1ruWBG2IIKG1M7amaY3vLglOcw3G/9TxVb7vQPHl8XcPp?= =?us-ascii?Q?NpkiEyZ4qHdpaRq6S4Il/vaxMYnEwjT8lwCuYfpF6mr3CfJtI/MRpKwkeCuY?= =?us-ascii?Q?BT70AHone1y9YepXJHoInVedHpwQ0QXjaxhDTlORfSXunJJajv9pIAL6JOUx?= =?us-ascii?Q?oYo8qzuahx9UgdSpMEFgXvYxRtp9FKk5aBOHhAiosML28KcD0i0zSItcFO/M?= =?us-ascii?Q?qi219DsQAgC68MpdZUWvANVfWCPwbBFQ3bapKXZ9ReluJeltzh5IutbsPERL?= =?us-ascii?Q?bLb3+k35sxCjjKae/aRabZnYTnXPlXFsNrR5xMrU8bfPVbW8n5fz1wZWb7mr?= =?us-ascii?Q?C1f3n9CIPRjKUvY93xjRT9bbH/4makvCDc34sa+tRtH8biK44rI0FnKmBkcp?= =?us-ascii?Q?8qOUSLfWB6y4B8SqyRNic2vTcZP0cwDawZGH78QcD8n1loJniZApDOWK5W3g?= =?us-ascii?Q?d1gIBAZD2NIxEnfEpzkStLRR2YFrP0AQJcnUmRUDfPngeSaLVOmQqPZuQpXM?= =?us-ascii?Q?98FXaZrEhykuPDk8VY+Yg5R68s8Keu+53vaIw3Iax7lJnEtbhxutgHYqSd96?= =?us-ascii?Q?VP3IBmHqvS0sMv+eJUy03z0WCBl8AVdZpCjiZNNaBokZicJde3s9rjBH62tS?= =?us-ascii?Q?SzfwQpK+68BD7aafZFNY8/5HC9vOGEZlyvlNtePdK3WvQ1O5wr9nctraBTjk?= =?us-ascii?Q?q+wAbGISgW0W0G38Gtbua4mqTsUEFzYJ9NitFBr+zIK/tLJ0bbMKAMR0+m0c?= =?us-ascii?Q?wpiR4ePjXl3i+bipIQ2TPqe1wr3y2CKe4iatis8Sc5kb1t5GbJhP5wNJPExs?= =?us-ascii?Q?in4VSnC0GTqGwsjMIyN2OrLJKbfR8BFPJDw3FCRVd0V+H7mr4lA/xqLUyvBX?= =?us-ascii?Q?ddI/idq9BrPOnl2CB5ZUOaQ+9FwhUJ9M6W1UyuUM0K6SPuB?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0936; 5:LXi70qu82wMsgKf3V9I1qN2UpNlxVozKWaeHHXiCC5v5Jerf8FTkf/gwN/7VYIjQWJMeUW2alBSSUYD+nawDQpQO0OXp63+A97AtjhP2gvaKpxc0/wRHTFhbB0DJdAr89fbMLuNSnnXJA+F4Z8IxPA==; 24:3kZFJdj0QKEV6aMEI8DtgDdHzwrY7WyicCWYZpf+ARSiqGWAWExTeALfoYfXD2pYQ2JAqWJMqr6TwxsoBglIdJjJsgHMgS5en5cfovKW0Jw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2015 12:24:38.1530 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0936 Subject: Re: [Cake] second system syndrome X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 12:25:06 -0000 --------------ms060004010601080201040209 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Here are some further thoughts, intermingled with Sebastian's comments as well. This is more of a brain dump/thinking out loud so is in complete disorder and blunt. On 06/12/15 16:08, Sebastian Moeller wrote: > Hi Dave, > > since I am not really involved in cake development make out of my comme= nts what you will=85 > > Even though I added comments below, IMHO, the way to proceed is discuss= the statistics to pass back to tc, and define a set we agree to stick to= (sat least as a base set, potentially copied from the best of fq_codel a= nd HTB) and then ask the kernel and iproute2 folks to merge what we have.= Changes that improve performance will most likely be possible in the fut= ure even if upstreamed already=85=20 I'm going to get shouted at for this, but I don't care. There is one more feature (ok 2 more features) I'd like to see. 1) Extend DSCP washing to include a 'washed DSCP value' per tin. It's a simple extension and allows washing from the default 'best effort' to something else we can choose. I've written about 25% of this, what I'm struggling with is a reasonable way of passing 8 bytes (the DSCP code for each tin) from userspace to kernel land. The tc interface would be simple (and horrible) in the sense of it'll be a hex string of the required dscp codes for each tin. Unless someone wishes to write a better interface of course. There will of course be additional cpu cost - picking up the 'washed to' from memory. 2) dual flow isolation. > > > On Dec 6, 2015, at 15:53 , Dave Taht wrote: > >> I find myself torn by 3 things. >> >> 1) The number of huge wins in fixing wifi far outweigh what we have >> thus far achieved, or not achieved, in cake. The distractions of crappy wifi and then the FCC d=E9b=E2cle haven't help= ed the focus on Cake one bit. Personally speaking, there's a lack of clear project 'lead' - I persist in my assertion that I'm not a coder, certainly not a confident one.=20 I've been reluctant to push commits to the repo with ideas/lunacy quite frankly because I don't want to piss either you or Jonathan off by messing with what I perceive to be 'his' code. On the other hand, some things have happened (and stuck!) because I just blew a raspberry in the general direction, said 'stuff it' and pushed - anything that went into a feature branch got ignored, anything in 'master' got at least compiled and possibly even reviewed. We should make better use of git & (mis)feature branches. But there's need for a 'Linus' here. And a lot more collaboration. > As we say at home =93der Spatz in der Hand ist besser als die Taube au= f dem Dach=94; so given that cake is almost baked and wifi needs a lot mo= re than simple go-faster-stripes maybe finishing cake while getting wifi = improved is achievable? > >> 2) Science - Cake is like wet paint! There knobs to fiddle, endless >> tests to run, new ideas to try... measurements to take! papers to >> write! >> >> 3) Engineering - I just want it to be *done*. It's been too long. It >> was demonstrably faster than htb + fq_codel on weak hardware last >> june, and handled GRO peeling, which were the two biggest "bugs" in >> sqm I viewed we had. > Two questions: > 1) was it really faster for long enough tests (and has anybody accident= ally looked at cpu temperatures once cake starts throttling)? > 2) Bugs in sqm? I thought that cake=92s reason d=92=EAtre was not to im= prove sqm-scripts=92 performance, but to make it simple for my mom to set= up up a decent latency conserving internet access. So performance gains a= re sugar on top, but lack there of is not necessarily a merge stopper? 1) I suspect but don't *know* that the glitchy performance issue was a manifestation of the incorrectly sized buffer bug (now well & truly squished) There were other odd symptoms associated with that bug too: apparent changes in ECN marking, now behaving better. I've run 40/10 rrul tests (wired) for 10 minutes and not seen any evidence of nasties.=20 WiFi on the other hand......yes, let's leave that. 2) 'Apparent simplicity' is the phrase used on the bufferbloat cake page and I like it! Yes cake is 'complicated', but it's darn sight easier than a myriad of iptables rules & other carp that I don't understand. I also wonder if the focus on cpu usage is losing sight of offsets by not having all those rules around. > >> In wearing these 3 hats, I would >> >> 3A) like to drop cake, personally, from something I needed to care abo= ut. >> 3B) But, can't, because the profusion of features need to be fully eva= luated. >> In this test series: http://snapon.cs.kau.se/~d/bcake_tests/ neither >> cake or bcake were "better" than the existing codel in any measurable >> way, and in most cases, worse. bcake did mildly better at a short >> (10ms) RTT... which was interesting. > But since codel/fq_cdel are hard to set up, especially in combination = with a shaper; rough performance parity with HTB+fq_codel might be suffic= ient justification for a merge. Agreed > >> If you want to take apart this batch with "flent", looking for >> enlightenment, also, please go ahead. >> >> Were I to short circuit the science here, I'd rip out the sqrt cache >> and fold back in mainline codel into cake. This would also have the >> added benefit of also moving us back to 32bitland for various values >> (tho "now" becomes a bit trickier) and hopefully improving cpu >> efficiency a bit further (but this has to get done carefully unless >> your head is good at 32 bit overflow math) >> >> Next up, a series testing the fq portions... >> >> If someone (else) would like to fork cake again and do the two things >> above, I'd appreciate it. Feature branch. Beyond my cut'n'paste C I'm afraid. >> >> 3C) Most of the new statistics are pretty useless IMHO. Interesting, >> but in the end I mostly care about drops and marks only. > I do care about packet size (and max packet size). The kernel=92s comp= licated rules when and which overhead to add or not to add are so under-d= ocumented that one needs a way to figure out what information reaches the= qdiscs/shapers otherwise meaningful per-paket-overhead accounting is not= going to work. Max_packet size I see as the only way to check wether Met= a-packets hit the qdiscs or not. Even if cake does not peel or always pee= l this is informative in my opinion. I put 'last packet' there simply because it was available nearby in the code :-) I agree with Sebastian that max_packet has been extremely useful in *KNOWING* what overheads the kernel is passing into the qdisc. Compromise: Drop 'last packet', maintain 'max_packet'. > >> 3D) Don't have a use for the rate estimator either, and so far the >> dual queue idea has not materialized. I understand how it might be >> done now - using the 8 way set associative thing per DEST hash, but I >> don't really see the benefit of that vs just using a DEST hash in the >> first place. >> >> 3E) Want cake to run as fast as possible on cheap hardware and be a >> demonstrable win over htb + fq_codel - and upstream it and be done >> with it. > Being able to set up a decent shaper/codel combination in one line of = tc is already a win (but I repeat myself) You do. And I agree for a 2nd (or is it 3rd) time. > >> 3F) At the moment I'm favoring peeling at the current quantum rather >> than anything more elaborate. > Why quantum, why not simply at MTU boundaries? I seem to recall that a= ggregates already carry information how many MTU segments they consist ou= t of which could be re-used? > >> 3G) really want the thing to work correctly down to 64k and up to at >> least a gbit. >> which needs testing... but probably after we pick a codel.... >> >> 2A) As a science vehicle, there are many other things we could be >> trying in cake, and I happen to like the idea of the (currently sort) >> cache in for example, trying a faster curve at startup - or, as in the= >> ns2 code - a harder curve at say count + 128 or even earlier, as the >> speed up in drops gets pretty tiny even at count + 16. (see attached) >> >> (it doesn't make much sense to calculate the sqrt at run time - you >> can just calculate the constants elsewhere and plug them in, btw. >> attached is a teeny proggie that does that an also explores a harder >> initial curve (you'd jump count up to where it matched the curve when >> you reverted to the invsqrt calculation) - and no, I haven't tried >> plugging this in either... DANGER! Wet Paint! >> >> I also like keeping all the core values 64 bits, from a science perspe= ctive. >> >> There are also things like reducing the number of flows, and >> exercising the 8 way associative cache more - to say 256, 128, or even= >> 32? Or relative to the bandwidth... or target setting... >> >> and I do keep wishing we could at the very least resolve the target > >> mtu issue. std codel turns off with a single mtu outstanding. That >> arguably should have been all that was needed... >> >> and then there's ecn... >> >> 1A) Boy do we have major problems with wifi, and major gains to be had= >> 1B) All the new platforms have bugs eveyerhwer, including in the >> ethernet drivers >> >> 0) >> >> So I guess it does come down to - what are the "musts" for cake before= >> it goes upstream? > Get the feature set defined (potentially strip contentious features fo= r the time being and merge them piecewise into the kernel proper) as well= as a statistics set so the communication with tc is future proof enough = for the near future. Then try to get it merged... > >> How much more work is required, by everybody, on >> every topic, til that happens? Can we just fork off what is known to >> work reasonably well, and let the rest evolve separately in a cake2? > I was under the impression, that you and Toke are currently measuring = the performance costs of the additional features so decisions which featu= res to include could be made based on their cost? It is difficult for the rest of us to help with the measuring if we don't know how & what you're measuring. Judging from recent comments I'd say some code profiling is going on too. I've no idea how to do that...let alone on my router...but if there were some instruction I'm willing to try on a non X86_64 platform. I'd also like to see a lot more algorithm documentation. I can read (some) code but there are quite a few places in cake that are opaque to m= e: 1) The DRR soft shaper algorithm, how it relates to 'now' 2) Interaction with bandwidth thresholds 3) Difference between tin_quantum_band & tin_quantum_prio. The code even contains the comment 'this is the priority soft-shaper magi= c'! Kevin --------------ms060004010601080201040209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DYEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB0UwggYtoAMCAQICAw5ySjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE1MDYyMDIw MzA1MloXDTE2MDYyMDE0MjY0N1owVjEmMCQGA1UEAwwda2V2aW5AZGFyYnlzaGlyZS1icnlh bnQubWUudWsxLDAqBgkqhkiG9w0BCQEWHWtldmluQGRhcmJ5c2hpcmUtYnJ5YW50Lm1lLnVr MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAugCNtDhytCJ9HOfenUHr/vUGUECv PL1IJXgHMl4cIJmwgLOkXhIcTMxHnX+kFweqvT+eDWv1hzA9yMWhvjLFC4eLoFaV0xiAat8O XQ7t3MwKY5DW0mB1dOnjiFIcc/XMwyYI4KfEGnFMJQkzon0rDVpkl/Q1f/hu1sELO7Zc6TFL wuuDuiP7S73zrz50TRoq0+Ob3x0uOMW2uVwVzf6NLwHgBE2LFleMXblyUMx0IlIcLan2nWiI Vsa3XYd+C6KAGGwlmO4VAZ25KuX7hkj8f82lSapvtKTtvrSoDghXlHH2JXiIQX+Sn0UgOmbX 1KyOe9vN7WzQ+tpPRzpFRffnnnp1VQye3wVRPBumjDxQSFTOhUtslnvbefUQSPw6p5w9ZiXI GJICLkX/MkYN/TwGCvuUG2PxBybSR1A2I5ap+VI/zGSG3XGVEA69SOZQyD+8YjJZfaY2nCu+ DuM64JrJUi2CvX6fwcdHNschJNrrfetpnrx3JrGnG9o+pWuUG1phBg+KKN2bhrdzY79qm7ha 86EMKSUOn5nBdGY3YxdXq/naoUQeOCUV2JMFGOulu7sKpiWcz7HVFacXjd9ebisVLv+jOwll z14BWRb87s1+LBEJn/Ybn3ekhtgyEAhB4kgj0scl4hI8xCU6zrZyDnbXmxSvDXbClZA0PACt f/jhGvUCAwEAAaOCAuMwggLfMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQULkW2CpDiQpRNumQ7wdspjFfgX+AwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKAYDVR0RBCEwH4Eda2V2aW5AZGFyYnlz aGlyZS1icnlhbnQubWUudWswggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIB KjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYI KwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVs aWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0 aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDov L2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2Nh MEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3Mx LmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0G CSqGSIb3DQEBCwUAA4IBAQBicQWe98eF/o09TXFsExc+WSyYjt3oSnXyocLzXQp82CQhIg21 5RqNZ1e+hsO7tq8S6hdItUDbKpecpIV59+57ke1zVl2slTRIT19fhYINHH78rVVRPzuHoiDt MXnGrp9hbq3Cz8P4mm8INKDiYK46kyplRAQ3ZMouPG1lsnDzgQAvbCj74H8yAp7fK8if6cxs 28BCUmdP8D3c6M1ffdNNaqNT+4Z3mtOujXXg7zOfmXN0Zg/mEtZ0NrWE2uICGdWjTv9KZiI7 fi4hk2CRpCL63qzmu6BwtcgtwhgYYtuAk2N43+SiyDkyLKGAcjEor3t5f9HivN29E0F0MXTH 1OdgMYIFDTCCBQkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQID DnJKMA0GCWCGSAFlAwQCAwUAoIICSTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTEyMDcxMjI0MzRaME8GCSqGSIb3DQEJBDFCBEDklN/OttstrqMACIb3 RSOFRSkTKxoRk5ssR0BcORWMWUmVpOy90n/45fWRnObQoHNuDENIv0maPsxUSY33lBj7MGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMOckowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAw5ySjANBgkqhkiG9w0BAQEFAASCAgBRJ0dX677GDDBs704Wm+/R8L4OHHU8 OHIvIL2/x/UWppNPliO+Gs3joN27z1bTU5+e1wPZGLZA6dZEOifeJWIrBeFMpfZl/ZF2ZAOG mPi7sLNDcAGOUqxroMSRlX91Io5OimmrGzUO++nzkY7ZiKIl7pheVfJhAR710XTPoD/iThOu GbiEWVUP3kKpri2m3PHrdsSrydSvx1xvZYtVk0HU1V99//WRaapDReQQuxX3ZHF5CP+/c5Ey 2jfKJm5YQRmCb5npTpTEjlAL3y22e2tEsWrcrGQsy6dOTxQ2wbUTjhOR0ujt7xq69HamB5Ww 8TACjWWEgTP0+SJL+MO4T2lba/fzla4m45Mkt/8gcS5pT3LVNdQayiWgzwdR1hSEKVqA/X9m yMM7jOuVZY/r9RqZ1oxLrdMLll3EooVtCyOome+6ROBs1NU2tQbfL99iL/f/GnJZ1xJn8McW lxSAs5b45X7hn2Ee+FLbUDY0rwusaFxtvar0OBwn8JuOmt+lRlJKFL5dD6zvWXJ0Z6CBFJap SUWGiprn7p6uixJ47qn82gymW0L+PNEmjScnNMV45e6BaBEjwyzK/zNYjqFTgUmLl5MHadUI 6uXF4mOUbweC7lygn7uMQ7gzMTNfAiIUw4gdTu6j9aRAvAOqRQgLvuUn45IOv5KyJFNs+21w htDUngAAAAAAAA== --------------ms060004010601080201040209--